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

Fri May 29 08:33:03 PDT 2009

Luis,

But what is the technical explaination / mechanism?

The PXE mechanism (specification) itself doesn't impose such a constraint.
And I don't see how this could result mere naming difference (that
only reflects in the initial load of the Network Boot Program by the
PXE firmware) could yeld such a result?

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