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