Syslinux - Nov 2010 - pxechn.c32: Status

Now that pxechain.com can work (with my patch to core/pxelinux.asm), a
PXE Chainload COM32 is not as big of a deal but I agree with HPA that
it would be a good idea, especially considering the possible
flexibility that this may allow.

For the moment, I've named the chain module pxechn.c32 in order to not
collide with the name pxechain.com when not specifying the .com/.c32
extension.  Currently, I've got pxechn.c32 to the point that it's
equivalent to just running the new nbp from PXELINUX (without a PXE
restart).

I'm looking at being able to either call the PXE API with opcode 0073h
(PXENV_RESTART_TFTP) or do it all ourselves.  I think that if it's
possible, it would also be nice to be able to specify parameters for
DHCP options 209, 210 and 211 (config, prefix and reboot) when doing
it ourselves.  However, editing the cached packets that the PXE stack
holds is a little dirty, unstable but needed.  I'll also want to
detect gPXE as it would be safer if I could tell gPXE to do it all for
us (is there a good callback for this?).

Proposed command line:

-Do it ourselves (or tell gPXE to; partially implemented)
pxechn.c32 _new_nbp_ [config [prefix [reboot]]]

where reboot is converted with strtoul and all other arguments are in
any applicable format (URL or PXELINUX-specific format) or a special
ignore character/string (probably "-" or "--" would be best)
to allow
the later arguments to be specified.  I think this order would
probably provide the most common and logical order (since I'd think a
user is less likely to override the later arguments).

-Use PXENV_RESTART_TFTP (not implemented)
pxechn.c32 -r [[ipaddress]::]tftp_filename

Equivalent to "pxechain.com [[ipaddress]::]tftp_filename"

-- 
-Gene

--On Sunday, November 07, 2010 08:12:22 AM -0500 Gene Cumm 
<gene.cumm at gmail.com> wrote:
> Now that pxechain.com can work (with my patch to core/pxelinux.asm)
Thanks for tracking this down; somehow I don't think I'd have found the 
time to do so anytime soon.

> I'm looking at being able to either call the PXE API with opcode 0073h
> (PXENV_RESTART_TFTP) or do it all ourselves.
As you know, PXECHAIN currently uses the PXENV_RESTART_HTTP method.  I've 
partially implemented the "do it ourselves" method, asking PXELINUX to
load
and run the new NBP, but I have a few bugs I haven't had time to track 
down.  So, I don't see any reason why a COM32 version shouldn't be able
to
use that approach; in fact, I expected it to be more reliable as well as 
having a better chance of regaining control if something goes wrong.  I 
also considered an approach of TFTP'ing the new NBP and then asking 
PXELINUX to run it, but that seemed unnecessarily complex.




  I think that if it's
> possible, it would also be nice to be able to specify parameters for
> DHCP options 209, 210 and 211 (config, prefix and reboot) when doing
> it ourselves.  However, editing the cached packets that the PXE stack
> holds is a little dirty, unstable but needed.
Yes; editing the cached packets is definitely needed, because some NBP's 
really need us to rewrite the siaddr and bootfile fields in order for 
anything useful to happen.  I agree that being able to add/edit other 
options would be useful; that's the sort of thing that's really too
complex
to do in PXECHAIN.ASM but ought to be reasonable for a COM32 module.
> Proposed command line:
>
> -Do it ourselves (or tell gPXE to; partially implemented)
> pxechn.c32 _new_nbp_ [config [prefix [reboot]]]
>
> where reboot is converted with strtoul and all other arguments are in
> any applicable format (URL or PXELINUX-specific format) or a special
> ignore character/string (probably "-" or "--" would be
best) to allow
> the later arguments to be specified.  I think this order would
> probably provide the most common and logical order (since I'd think a
> user is less likely to override the later arguments).
I wonder if it's worth doing actual getopt-style processing for the later 
arguments.  That would allow any combination, as well as allowing for 
future expansion to provide other DHCP options.
> -Use PXENV_RESTART_TFTP (not implemented)
> pxechn.c32 -r [[ipaddress]::]tftp_filename
>
> Equivalent to "pxechain.com [[ipaddress]::]tftp_filename"
Sure.

-- Jeff