[ipxe-devel] Misc iPXE patches

Jarrod Johnson jarrod.b.johnson+ipxe at gmail.com
Fri Nov 12 20:39:54 UTC 2010

I thought I'd enumerate the remotely significant patches I apply for my
purposes to iPXE (against ipxe today).

I take the kernel cmdline size from 0x100 to match syslinux' 0x7ff.  I think
newer bzImage format is handled nicer, but 'older' (aka current in
enterprise world) kernels are overlimited compared to pxelinux:

I use iPXE scripts to load kernel but provide BOOTIF that looks just like
IPAPPEND 2.  The catch was that gPXE had no variable for the NIC mac that
would format the same (hyphen instead of : delimited).  This patch gave me
the 'machyp' variable so I could mimick IPAPPEND 2 exactly.

I have had a NIC vendor tell me that gPXE failed as a chainloaded payload on
their nic because they didn't do interrupts quite as gPXE expected.  The
following workaround was needed to proceed on their NIC, though I think it's
potentially worrisome:

One patch submitted before to gPXE, gives me the ability to expand variables
in the filename parameter from DHCP.  The biggest downside would be that if
using signed payloads to verify trust of scripts before potentially
expanding 'secret' variables, this would provide a way to divulge those
variables via malicious DHCPOFFERs.
The most interesting aspect is for 'next-server' to be defined at the subnet
level of dhcp config, and the 'filename' in a host-declaration and having
client assemble the full url.

And finally, for lack of debug I cannot provide an ongoing assessment of how
required it is, but I disabled arp table population on non-arp traffic, ICMP
echo replies and TCP resets because with thousands of nodes on a vlan,
gPXE's neighbor table wasn't quite coping with the chaotic traffic (tried to
learn too many incidental macs and didn't manage to get the boot servers in
the table).  Unfortunately, debugging thousands of nodes booting at once is
not a frequent test case and I had no need of 'proper' network behavior, so
I took a hatchet to it:
It could be possible to reproduce the problem more synthetically at small
scale for a 'proper' fix, but I didn't try given a good enough solution to
my problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20101112/8b93ce16/attachment.htm>

More information about the ipxe-devel mailing list