After the PXE PROM code downloads and runs the pxelinux.0 image and it tries to download config information the client stops acknowledging the server OACK packets from the server. pxelinux from syslinux 3.11 from Fedora RPM, accessing Solaris 10 in.tftpd The tftp client in pxelinux.0 sends a tftp file read request with extended options tsize \00 0 \00 blksize \00 1440 \00 and then the server responds with opcode 6 (as per RFC 2347) and tsize \00 79 \00 blksize \00 1440 \00 and then the client just retries a few times and tries the next config file. The PXE card is using the blksize extended option with 1456 bytes and it is working fine. Something I notice is that the servers response never comes from port 69 but from an arbitrary higher-numbered port. The PXE PROM just ACKs (opcode 4) back to the port from which it received the OACK and the conversation continues, but I wonder if the tftp client code in pxelinux doesn't go for that. Thoughts? -- Eric Irrgang - UT Austin ITS Unix Systems
Sorry to gum up the list. Despite the fact that the pxelinux sent the client request to the right place, it didn't wasn't happy with the conversation until the boot server DHCP option was explicitly set... On Thu, 8 Mar 2007, Eric Irrgang wrote:> After the PXE PROM code downloads and runs the pxelinux.0 image and it > tries to download config information the client stops acknowledging the > server OACK packets from the server. > > pxelinux from syslinux 3.11 from Fedora RPM, accessing Solaris 10 in.tftpd > > The tftp client in pxelinux.0 sends a tftp file read request with extended > options tsize \00 0 \00 blksize \00 1440 \00 and then the server responds > with opcode 6 (as per RFC 2347) and tsize \00 79 \00 blksize \00 1440 \00 > and then the client just retries a few times and tries the next config > file. > > The PXE card is using the blksize extended option with 1456 bytes and it > is working fine. > > Something I notice is that the servers response never comes from port 69 > but from an arbitrary higher-numbered port. The PXE PROM just ACKs > (opcode 4) back to the port from which it received the OACK and the > conversation continues, but I wonder if the tftp client code in pxelinux > doesn't go for that. > > Thoughts? > > -- > Eric Irrgang - UT Austin ITS Unix Systems > > _______________________________________________ > SYSLINUX mailing list > Submissions to SYSLINUX at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux > Please do not send private replies to mailing list traffic. >-- Eric Irrgang - UT Austin ITS Unix Systems - (512)475-9342
Eric Irrgang wrote:> After the PXE PROM code downloads and runs the pxelinux.0 image and it > tries to download config information the client stops acknowledging the > server OACK packets from the server. > > pxelinux from syslinux 3.11 from Fedora RPM, accessing Solaris 10 in.tftpd > > The tftp client in pxelinux.0 sends a tftp file read request with extended > options tsize \00 0 \00 blksize \00 1440 \00 and then the server responds > with opcode 6 (as per RFC 2347) and tsize \00 79 \00 blksize \00 1440 \00 > and then the client just retries a few times and tries the next config > file. > > The PXE card is using the blksize extended option with 1456 bytes and it > is working fine. > > Something I notice is that the servers response never comes from port 69 > but from an arbitrary higher-numbered port. The PXE PROM just ACKs > (opcode 4) back to the port from which it received the OACK and the > conversation continues, but I wonder if the tftp client code in pxelinux > doesn't go for that.No, that's all consistent with the spec. Could you send me (off list) a wireshark (ethereal) trace file, or if that's not practical, the output of "tcpdump -e -s 2000 -XX -vv" with the appropriate filter options? -hpa