[ipxe-devel] PXELINUX-lwIP and iPXE (and presumably gPXE)

[H. Peter Anvin]

So, for those who aren't familiar, I have been working on a version of
PXELINUX containing an embedded version of the lwIP stack lately.  This
has a lot of advantages, especially when running on top of a
non-iPXE/gPXE enabled stack.

Unfortunately, it has had some issues on top of iPXE (and presumably
gPXE, which I haven't investigated yet.)

The current baseline code is syslinux-4.10-pre12, which is available on
the "lwip" branch of:

http://git.zytor.com/?p=syslinux/syslinux.git


This code by its very nature has to use the UNDI interface rather than
the UDP interface, which has shown some very "interesting" interactions.
 One of the things that is complicated is that I would like to retain
the ability to chainload another NBP, which means not killing the BC.

Overall, the goals and issues should be very similar as for undionly.kkpxe.


I have since found that a call to PXENV_STOP_BASE before PXENV_UNDI_OPEN
makes the UNDI interactions work stably on iPXE, however, during the
unload sequence it makes iPXE output the message:


No more network devices

Press Ctrl-B for the iPXE prompt...


... which obviously makes me a bit concerned, especially if iPXE *would*
find another network device.

I have tried this on two machines, one e1000 on which this worked but
was unstable, and one with a CK804 which did not work at all.  I have
yet to check if PXENV_STOP_BASE addresses the CK804 issue.

However, PXENV_STOP_BASE does concern me, both because of the message
above and because it would appear to require PXENV_START_BASE to have to
be executed in order to get the stack back to a position where another
NBP can be chained, but PXENV_START_BASE is defined to restart the boot
cycle from the beginning with DHCP.

For "stock" PXE stacks simply stealing the UNDI ISR seems to do the job,
and/or PXENV_UNDI_OPEN/PXENV_UNDI_CLOSE is sufficient to tell the vendor
BC to butt out.

	-hpa