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

Fri May 29 08:54:56 PDT 2009

Geert, Luis,

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

And BTW, I vaguely recall that this .0 trick was a convention that was
used by the initial Intel PXE server implementation for implementing a
two-phase network boot: The first (.0) NBP would implement a menu, and
the next file would be the actual NBP doing the boot.But from the
BOOTP, DHCP and PXE specs, this is a mere convention that I see
nowhere enforced.
There is nothing hardcoded in the PXE firmware nor anywhere else I can
know of that imposes to follow that scheme. The name of the first NBP
that PXE loads comes from either the filename BOOTP field or the DHCP
67 field, and after it's been opened by the TFTP server, the NBP name
is not used much.

On Fri, May 29, 2009 at 17:16, Luis Correia <buga at loide.net> wrote:
> Phillipe,
>
> On Fri, May 29, 2009 at 16:00, Philippe Auphelle <pauphelle at gmail.com> wrote:
>> Geert,
>>
>> Thanks for for your work, and for a very detailed analysis.
>> All that you wrote found and described is perfectly exact.
>>
>>> I think the culpritt is using pxelinux.bin for PXE booting.
>>
>> pxelinux.bin and pxelinux.0 are both from the "core" -Pre16 directory
>> and are the two exact same files (I just double checked by a bin
>> compare followed by an MD5 and SHA1 checksum computation - belt and
>> suspenders).
>>
>> Did you fear that both files were actually different, or is there
>> something else that I'm missing?
>>
>
> For PXE you should use exclusively files ending in '.0'.
>
> this is what I get from the documentation.
>
> Luis Correia
>
>
>>
>>
>> On Fri, May 29, 2009 at 15:19, Geert Stappers <stappers at stappers.nl> wrote:
>>> Op 20090529 om 11:33 schreef Philippe Auphelle:
>>>> Hi Geert,
>>>
>>> This goes to a mailinglist ...
>>>
>>>> On Fri, May 29, 2009 at 10:21, Geert Stappers <stappers at stappers.nl> wrote:
>>>> > Op 20090528 om 09:16 schreef Philippe Auphelle:
>>>> >>
>>>> >> I extracted pxelinux.bin and menu.c32 from Testing pre-16 and ran the
>>>> >> test. I unfortunately got a result that's quite similar to the one I
>>>> >> had with the 3.80 release:
>>>> >>
>>>> >> The last activity pxelinux.bin displays is the transfer of the
>>>> >> "default" file ("Trying to load: pxelinux.cfg/default"). Looking at
>>>> >> the trace, that transfer is successful.
>>>> >>
>>>> >> Then the client sends an TFTP RRQ for menu.c32, the TFTP server
>>>> >> ignores the option negociation and sends back a regular TFTP data
>>>> >> packet with a 516-byte payload (524-byte UDP, 544-byte IP, 558-byte
>>>> >> eNet), and at this point, the pxelinux client machine freezes.
>>>> >> WireShark doesn't report any kind of error on the reply data packet.
>>>> >> The server does 3 retries then gives up.
>>>> >> I have a WireShark-readable trace ready reflecting the problem.
>>>> >
>>>> > I willing to explore it with WireShark.
>>>> > Send me ( and/or this mailinglist) where to download it.
>>>>
>>>> You can download it from there:
>>>> http://dl.free.fr/qHGA8UhQq/PXELinux3_81-Pre16Hang.zip
>>>>
>>>> >> Compared to my previous test with 3.80 release, the only (minor)
>>>> >> difference I see is that this time, the client hard freezes (i.e. Caps
>>>> >> log toggle or Ctrl-Alt-Del don't do anything anymore). Last time,
>>>> >> keyboard interrupt handling was still alive.
>>>> >>
>>>
>>>
>>> PXELinux3_81-Pre16Hang.zip has a nice  .pcap file.
>>>
>>> Wireshark tells me the same as the original poster is telling.
>>>
>>>
>>> Here my further review:
>>>
>>>
>>> There are 2 DHCP servers in the network,
>>> one is the router at 192.168.1.1 and another one at 192.168.1.101.
>>>
>>> The router hands out adress 192.168.1.100 the client
>>> The other DHCPserver tells which file to use from which next server.
>>>
>>> The client seems to mix both DHCP answers and continues.
>>>
>>> pxelinux.bin is succesfull fetched
>>>
>>> next is pxelinux.cfg/default fetched
>>> with this content
>>> | DEFAULT menu.c32
>>> | PROMPT 0
>>> | MENU TITLE Boot Menu
>>> | TIMEOUT 80
>>> | ONTIMEOUT ImageMgr
>>> |
>>> | LABEL nfs
>>> |  MENU LABEL Boot Local HDD
>>> |  LOCALBOOT 0
>>> |
>>> | LABEL ImageMgr
>>> |  MENU LABEL Boot Windows (Image Manager, diskless)  kernel mPXEldr.bin keeppxe
>>>
>>> Then there is a TFTP Read request for menu.c32 from the client
>>> The server provides it, but the client is allready death.
>>>
>>>
>>>
>>>    ....... some research .....
>>>
>>> [1]
>>>
>>>
>>> I think the culpritt is using pxelinux.bin for PXE booting.
>>>
>>> This is from the syslinux documentation (in the released tarbal)
>>>
>>>    The following commands are available after a LABEL statement:
>>>
>>>    LINUX image                 - Linux kernel image (default)
>>>    BOOT image                  - Bootstrap program (.bs, .bin)
>>>    BSS image                   - BSS image (.bss)
>>>    PXE image                   - PXE Network Bootstrap Program (.0)
>>>    FDIMAGE image               - Floppy disk image (.img)
>>>    COMBOOT image               - COMBOOT program (.com, .cbt)
>>>    COM32 image                 - COM32 program (.c32)
>>>    CONFIG image                - New configuration file
>>>
>>>
>>> I couldn't find that on the syslinux webpages,
>>> but on http://syslinux.zytor.com/wiki/index.php/PXELINUX
>>> is pxelinux.0 used.
>>>
>>>
>>> My advice: put pxelinux.0 on the TFTP server and change dhcpd.conf
>>> something like  s/pxelinux.bin/pxelinux.0/
>>>
>>>
>>>> Best!
>>>> Phil
>>>
>>>
>>> Looking forward for feedback
>>>
>>> Geert Stappers
>>> taking topqoutes as a slap in the face
>>>
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.9 (GNU/Linux)
>>>
>>> iEYEARECAAYFAkof4MkACgkQOSINbgwa/7v/vwCfQ6CE/6YvKJP5ROXc3cCxn4hR
>>> 7SMAoMIGXF9XPsZKBk3niC9MQbG5dBwL
>>> =W10u
>>> -----END PGP SIGNATURE-----
>>>
>>> _______________________________________________
>>> Syslinux mailing list
>>> Submissions to Syslinux at zytor.com
>>> Unsubscribe or set options at:
>>> http://www.zytor.com/mailman/listinfo/syslinux
>>> Please do not send private replies to mailing list traffic.
>>>
>>>
>>>
>>
>> _______________________________________________
>> Syslinux mailing list
>> Submissions to Syslinux at zytor.com
>> Unsubscribe or set options at:
>> http://www.zytor.com/mailman/listinfo/syslinux
>> Please do not send private replies to mailing list traffic.
>>
>>
>
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>
>