[syslinux] pxechn.c32: Status

[Jeffrey Hutzelman]

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