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 _______________________________________________ ipxe-devel mailing list [email protected] https://lists.ipxe.org/mailman/listinfo/ipxe-devel
