[syslinux] SYSLINUX 2.06 released

[Josef Siemes]

Hi,

"H. Peter Anvin" <hpa at zytor.com> schrieb am 26.08.03 16:38:01:
> James Courtier-Dutton wrote:
> > Do you have a network trace of this problem happening. Did you check for 
> > the DF bit being set of not?
> > 
> > Maybe some PXE stacks are doing MTU Path discovery which then means that 
> >  they should not see any fragmented packets.

> It would be the TFTP server not doing so, but it should then get back 
> the ICMP NEED FRAGMENT and allow the packet to be fragmented.  This is 
> UDP, not TCP, so it cannot force smaller IP datagrams to be sent.
> 
> The big problem is that the PXE stack will generally do the wrong thing 
> with the fragmented incoming packet.  Most PXE stacks are buggier than 
> hell, and it doesn't take much tweaking.

Since I have reported this problem some more explanation of what was happening:

The server is set to MTU of 1492. This is a token-ring network with some ethernet
bridges, and these bridges demand 1492, they don't work with 1500. With this
every packet sent from the tftpd with packet size 1500 (this is blksize 1480
in tftp) gets fragmented into two packets, the last one containing the 8 bytes
that didn't fit into the first one. The effect was that any download (even of
pxelinux config file) by pxelinux failed in mysterious ways: Sometimes pxelinux
reported errors in the config file, and the downloaded kernel didn't start at all.

The client is a IBM PCI token ring card, and this doesn't reassemble the packets
correct. I don't know if it set the DF bit. 

The effect of this is that the download once again generated more packets as
were needed, even if the PXE rom was able to reassemble the packets as it
should have done. So the best solution for this would be to make this configurable
and let the user (or the config file) decide which blksize to use.

BTW: Still need to test 2.06 ...

Regards,

Josef
__________________________________________________________________________
Die sicherste Form der Kommunikation: E-Mails verschluesseln, Spam-Filter,
Adressverifizierung, digitale Unterschrift: http://freemail.web.de