[syslinux] Confusion on lpxelinux vs. gpxelinux vs. ipxe vs gpxe.

[Gene Cumm]

On Sat, Oct 24, 2015 at 4:57 PM, Doug Scoular via Syslinux
<syslinux at zytor.com> wrote:
> Hi All,
> I've been trying to understand how to use pxechn.c32 to chain a local
> pxelinux menu item to a remote server which has it's own pxelinux hierarchy
> served via TFTP and HTTP.
>
> We have no control over DHCP next-server and filename fields so I wanted to
> exploit the "prefix" -p option that pxechn.c32 accepts.

Remember, pxechn.c32 option "-p" is a shortcut to set DHCP option 210.
I see I did make this note in doc/pxechn.txt.

> I spent a long time hitting my head against a brick wall until I recompiled
> with various DEBUG macros set... my pxechn stanza looked like this:
>
>   # Test Doug's chaining...
>   LABEL chain018
>           MENU LABEL ^Doug's REMOTE lpxelinux.
>           KERNEL pxechn.c32
>           APPEND
> http://wwwin-kickstart.remote.com/tftpboot/dscoular/syslinux/lpxelinux.0 -p
> http://wwwin-kickstart.remote.com/tftpboot/dscoular/syslinux

Which is likely an unintended error.

> With DEBUG set I could see that my local lpxelinux.0 would successfully
> load pxechn.c32, then pxechn.c32 would load the remote lpxelinux.0 via
> HTTP... but then it would fail to find it's needed ldlinux.c32.
>
> It took a wireshark packet dump to discover that the pxechn "prefix" -p
> option *MUST* be given a trailing slash (ouch):
>
>     HTTP/1.1 404 Not Found
>     The requested URL /tftpboot/dscoular/syslinuxldlinux.c32 was not found
> on this server.
>
> Adding the trailing slash solved our issues and we were able to load the
> remote lpxelinux.0 and have it use our remote .../syslinux/pxelinux.cfg.
> Hurray!

Almost always it should need a trailing slash.

> However, I'm left feeling a bit confused about all the Network Boot
> Programs mentioned in the syslinux documentation. I'd like to try and
> summarise my understanding here and have someone in the know correct any
> mistaken impressions I have (no doubt quite a few).
>
> So for syslinux 6.03 we have the following syslinux config compatible
> Network Boot Programs which can load com32 modules:
>
> 1. pxelinux.0 - a syslinux Network Boot program that only understands TFTP
> not HTTP or FTP, etc.
> 2. lpxelinux.0 - a syslinux Network Boot program linked against the
> light-weight TCP/IP (lwIP) stack. Offering fast HTTP, FTP, etc.
> 3. gpxelinux.0 - a syslinux Network Boot program linked against another
> Network Boot Program's implementation of HTTP (gpxe). Possibly problematic
> and slow on VMs.

Mostly right.  gpxelinux.0 is pxelinux.0 wrapped inside gPXE.
pxelinux.0 can use gPXE/iPXE callbacks regardless of how they're
loaded.

I believe lpxelinux.0 had some reported issues in the past with
patches that should have resolve this but I don't think there's been
quite as much testing as we'd like.

> We also have a gpxecmd.c32 which doesn't seem to be documented in the
> "modules" section of the syslinux wiki.

Executes an arbitrary gPXE/iPXE command through callbacks.

> As separate projects we appear to have:
>
> 1. gpxe - a mothballed Network Boot Program but with a possibly problematic
> and slow HTTP implementation.
> 2. ipxe - an active fork of gpxe but still with the possibly problematic
> and slow HTTP implementation (?)
>
> I presume that for pxechn.c32 to use HTTP, then it has to have been loaded
> either by gpxelinux.0 or, preferably lpxelinux.0 with it's shiny new lwIP
> stack or is pxechn independent loading it's own lwIP stack through ldlinux
> or another library module ?

pxechn.c32 just calls the Syslinux file calls.  It's up to the
Syslinux variant to interpret the filename.  Feeding pxelinux.0 an
HTTP URL without gPXE/iPXE to call for HTTP may result in some
interesting file retrieval attempts against the TFTP server.

> I see mentions of both iPXE and gPXE in the comments in the source.
>
> I note that if I try to use pxechn.c32 to load gpxelinux.0 it seems to
> ignore the "prefix" -p argument and for older versions my test VM seems to
> freeze.
>
> I further note that when I successfully pxechn to a remote lpxelinux.0 it
> doesn't seem to be quite as verbose as pxelinux.0 once was about the search
> enumerations it makes in it's sibling pxelinux.cfg directory, which I miss:
>
> /mybootdir/pxelinux.cfg/b8945908-d6a6-41a9-611d-74a6ab80b83d
> /mybootdir/pxelinux.cfg/01-88-99-aa-bb-cc-dd
> /mybootdir/pxelinux.cfg/C0A8025B
> /mybootdir/pxelinux.cfg/C0A8025
> /mybootdir/pxelinux.cfg/C0A802
> /mybootdir/pxelinux.cfg/C0A80
> /mybootdir/pxelinux.cfg/C0A8
> /mybootdir/pxelinux.cfg/C0A
> /mybootdir/pxelinux.cfg/C0
> /mybootdir/pxelinux.cfg/C
> /mybootdir/pxelinux.cfg/default

This looks like the old behavior that didn't rewrite a single line.

> Any thoughts and/or detailed clarification of how all the various bits of
> the puzzle fit hugely appreciated. Sorry to ask so many questions...

Hope this helps.

-- 
-Gene