Syslinux - Oct 2015 - Confusion on lpxelinux vs. gpxelinux vs. ipxe vs gpxe.

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.

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

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!

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.

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

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 ?

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

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

Cheers,

Doug

On 24/10/15 21:57, Doug Scoular via Syslinux wrote:
> 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 (?)
iPXE's HTTP implementation is definitely not slow.  On a Gigabit LAN, 
you should get the full 1000Mbps speed for HTTP downloads: a 200MB test 
file should transfer in under two seconds.  For most practical OS boots, 
you won't even have time to read the text that iPXE displays on-screen.

Also, not a fork: http://git.ipxe.org/ipxe.git/commitdiff/8406115

Michael

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

On Sat, Oct 24, 2015 at 6:15 PM, Michael Brown via Syslinux
<syslinux at zytor.com> wrote:
> Also, not a fork: http://git.ipxe.org/ipxe.git/commitdiff/8406115
A fork is a fork, regardless the reasons behind it (yes, I have some
understanding in this case).  iPXE is based off of forking further
development as of a certain gPXE commit with some backporting of gPXE
development to iPXE.

-- 
-Gene

>>>
On 24/10/15 21:57, Doug Scoular via Syslinux wrote:
> 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 (?)
iPXE's HTTP implementation is definitely not slow.? On a Gigabit LAN, 
you should get the full 1000Mbps speed for HTTP downloads: a 200MB test 
file should transfer in under two seconds.? For most practical OS boots, 
you won't even have time to read the text that iPXE displays on-screen.
<<<
HTTP at line speed (1Gb) on an iPXE client?
I was never able to get anything even close to that.

>>>
Also, not a fork: http://git.ipxe.org/ipxe.git/commitdiff/8406115
Michael Brown

<<<
it is a fork

Best,Patrick