[syslinux] blocksize and tsize at TFTP transfer

[H. Peter Anvin]

Philippe Auphelle wrote:
> 
>> 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,
> 
> Yes, for the reason stated above:
> pxelinux sends tsize followed by blocksize, tsize is not recognized
> and the TFTP server ignores the options and replies with the data
> packet as RFC 2347 "TFTP option Extension" allows: "If a server
> implementation does not support option negotiation, it will likely
> ignore any option appended to the client's request. In this case, the
> server will return a DATA packet for a Read Request transfer (...)
> establishing normal data transfer."
> And the client must be designed to handle this behavior.
> In other words, RFC 2347 "TFTP option Extension" explicitly states
> that the handling of options in TFTP is, well... optional.
> 
> Which gets us back to the initial problem, i.e. pxelinux crashing when
> it received the first TFTP data packet...
> 

For what it's worth, I just tested pxelinux 3.81 with tftp-hpa and all
options disabled.  Wireshark confirms that it sends DATA from the start.
 It works fine.

That code was at all modified between 3.80 and 3.81, so there is
something else fishy.

I looked at your posted trace, and there is something very strange going
on.  At packet 15 you have your TFTP server returning a malformed OACK
blksize packet (one extra zero, from the looks of it.)  However your
TFTP service doesn't honor blksize from pxelinux, which seems very odd.
 You're also sending your ERROR messages with the wrong byte order.
None of this should cause PXELINUX to die, though.

Part of me wonders if pxelinux.0 was correctly downloaded... if not, it
would obviously have disastrous conseqences at any random time.  Perhaps
a selfcheck would be a good idea.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.