[syslinux] blocksize and tsize at TFTP transfer

[Philippe Auphelle]

Geert,

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

It's a TFTP server that happens to live inside our PXE server software.
But what really matters is whether or not it is TFTP compatible as per
RFC 1350 (TFTP rev 2). I checked that, and judging by the WireShark
trace, it appears it is. I could be argued that even if it were not,
if the client crashes, then the client as an even more serious
problem.

> 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

Yes, because the PXE server sends an RRQ with a blocksize, and that
TFTP server does blocksize (as defined in RFC 2348, "TFTP Blocksize
Option"), but no other option but blocksize, and only providing
blocksize is the first parm in the RRQ or WRQ.

> 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...