[syslinux] blocksize and tsize at TFTP transfer

Geert Stappers stappers at stappers.nl
Sat May 30 05:50:26 PDT 2009


Warning: this message contains compliments

Op 20090530 om 08:23 schreef Philippe Auphelle:
   <snip/>
> Finally, the crash happens between the time pxelinux sends an RRQ for
> menu.c32 and the time it receives the answer. At this point, pxelinux
> doesn't deal with the DHCP and/or PXE server anymore, it's just
> talking to the TFTP server that those pointed way earlier.
> Furthermore, that answer is the first data packet rather than a TFTP
> option negotiation packet: So it looks most likely that the problem is
> in the handling of a data packet when an option negotiation packet
> could also be expected.
> 
> For the record, I went back to the last 3.6x version, when pxelinux
> only dealt with tsize-aware TFTP handlers: I then get the error
> message indicating that the TFTP server doesn't handle the tsize parm,

Good information!

> and the message occurs at the exact point where pxelinux crashes
> today.

Please tell more about the TFTP server that is being used.
( name, version, host operating system  and such )

> Ergo, I'd rather think that we just have a bug in the tsize (or
> absence of tsize) handling logic.
> That logic works sometimes though, since the RRQ for the "default"
> file asks for the same optional parms, gets the first data packet
> instead and does not misbehave.

You could be right about that.

I have been analyzing the pcap file PXELinux3_31Pre16Hang again.

The first TFTP Read Request, pxelinux.bin, has option blocksize 1456
The TFTP server acknowledges blocksize 1456
pxelinux is transfered in blocks of 1456 bytes

The TFTP RRQ for pxelinux.cfg/default has option blocksize 1456
and is asking for tsize option.
The TFTP server does NOT acknowledge the options,
it just sends the first (and last) block.
The TFTP client acknowledges recieving that block.

The TFTP RRQ for menu.c32 has option blocksize blocksize 1456
and is asking for tsize option.
The TFTP server does NOT acknowledge the options,
it just sends the first block.
The TFTP client NEVER acknowledges recieving that block ...


Stappers

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://www.zytor.com/pipermail/syslinux/attachments/20090530/75194dd2/attachment.sig>


More information about the Syslinux mailing list