[syslinux] pxelinux.bin (3.80) hanging at the beginning of menu.c32 TFTP transfer

Philippe Auphelle pauphelle at gmail.com
Fri May 29 23:23:24 PDT 2009


Geert,

>> I can now confirm that the very same freeze occurs when downloading
>> and executing pxelinux.0

> For what it is worth, I'm interrested to have original problem solved.
> Right now is the status that pxelinux.0 chokes when it has to download menu.c32
> But pxelinux.0 should be able to download menu.c32
>    .... thinking ....
> Right now _is assumed_ that the two DHCP servers are not causing trouble.
> My advice is to reconfigure the network to 1 DHCP server.

That's not an option.
First, if your DHCP server is of the minimal kind (think of a regular
$50 commodity router), then you just  don't have any way to config any
PXE options in. But the PXE spec has had forever provision to handle
this, by using a separate PXE server to handle the PXE part.

Second, that two-phase discovery / offer is handled (very well) by the
PXE firmware. At the time when pxelinux crashes, the handling of the
dual DHCP / PXE servers is over, and the firmware has collected,
processed, used and stored all the information it needed from both.
The information might still be in RAM and available from the PXE API
if pxelinux didn't remove it, but that's about all.
pxelinux has full control of the machine at this point, and it doesn't
care whether the information it uses came from one or two places.

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,
and the message occurs at the exact point where pxelinux crashes
today.
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.




More information about the Syslinux mailing list