[syslinux] Syslinux-5.10-pre1 looks for ldlinux.c32 in TFTP instead of HTTP
gene.cumm at gmail.com
Thu Mar 7 16:40:40 PST 2013
On Thu, Mar 7, 2013 at 12:57 PM, Tobias Göbel <kubax1983 at gmail.com> wrote:
> Am 07.03.2013 18:24, schrieb H. Peter Anvin:
>> On 03/07/2013 04:51 AM, Matt Fleming wrote:
>>> On Thu, 2013-03-07 at 13:32 +0100, Tobias Göbel wrote:
>>>> As you can see, everything is set to HTTP and i have no clue, why
>>>> pxelinux.0 tries to load it from TFTP anyways.
>>> The lwIP PXE stack is called lpxelinux.0 in 5.10-pre1, not pxelinux.0.
>>> pxelinux.0 is the legacy code.
>> So the legacy stack does special things when it sees gPXE/iPXE
>> underneath it; it talks a custom protocol with iPXE to allow it to use
>> TCP-based protocols using the stack in iPXE.
>> The lwIP-based stack shouldn't need to do that, and probably shouldn't,
>> but it is not well know how much problem the iPXE stack being in between
>> will cause. I suspect we need to get the iPXE people involved, though.
>> We should check, though, that we aren't simply using vestiges of the
>> custom protocol that is tripping us up.
> I'll try tomorrow at work, if legacy pxelinux works.
> But i think i'll not work, i didn't checked the logs from the TFTP server
> back then, but the "ldlinux.c32 not found" thingy was there, too.
> I'll report back tomorrow.
On Thu, Mar 7, 2013 at 12:26 PM, H. Peter Anvin <hpa at zytor.com> wrote:
> It would be interesting to know what we see in the incoming cached
> packet at this time. Does legacy pxelinux.0 behave the same way?
An easy way to examine the packets as *pxelinux.0 finds them is
prdhcp.c32. If you can satisfy the path for the TFTP request, you
could easily examine the results.
More information about the Syslinux