[ipxe-devel] Misc iPXE patches

[Michael Brown]

On Friday 12 Nov 2010 20:39:54 Jarrod Johnson wrote:
> 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:
> https://xcat.svn.sourceforge.net/svnroot/xcat/xcat-dep/trunk/xnba/ipxe-cmdl
> inesize.patch

Applied, thanks!

  http://git.ipxe.org/ipxe.git/commitdiff/4526f43

> 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.
> https://xcat.svn.sourceforge.net/svnroot/xcat/xcat-dep/trunk/xnba/ipxe-mach
> yp.patch

Applied a very-nearly-equivalent patch:

  http://git.ipxe.org/ipxe.git/commitdiff/312ae02

I avoided code duplication by letting storef_hex() handle both delimiters and 
adding a "delimiter" parameter to fetchf_hex().  Also, there is no need to 
create a separate ${machyp} setting; you can get what you need (using either 
your patch or mine) using ${mac:hexhyp}.

> 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:
> https://xcat.svn.sourceforge.net/svnroot/xcat/xcat-dep/trunk/xnba/ipxe-undi
> netchange.patch

Yes, that is worrisome, and I suspect it would break on some other NICs.  Do 
you have any details on how this NIC handled interrupts, and why this didn't 
work with iPXE?

> 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.
> https://xcat.svn.sourceforge.net/svnroot/xcat/xcat-dep/trunk/xnba/ipxe-expa
> ndfilename.patch 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.

At present there is no capability for verifying payloads before execution, so 
I think it would be acceptable to ignore this concern for now.

It would probably be useful to be able to expand the root-path in the same 
way.  I'll wrap this up into my reworking of your SAN+PXE patch.

> 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:
> https://xcat.svn.sourceforge.net/svnroot/xcat/xcat-dep/trunk/xnba/ipxe-drop
> packets.patch 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.

Both ICMP and TCP should be unicast, so I'm puzzled why you would see high 
traffic volumes for these protocols.  Removing the ability to respond with ICMP 
echo replies and TCP resets would noticeably downgrade functionality, whereas 
the ARP portion of the patch should result only in an extra pair of ARP 
packets, so I'm tempted to apply only the ARP portion.  Any thoughts?

Michael