[Dnsmasq-discuss] Proposal for DHCP Option 93 capture

[Simon Kelley]

Joey Korkames wrote:
> I wanted to air some thoughts about adding support for DHCP's option 93 
> in a future release of dnsmasq...
> EFI machines (and other non-typical architectures) use it to tell a dhcp 
> server that it is not an X86 (so you can direct it to TFTP GET 
> elilo/yaboot/etc instead of pxelinux)
> 
> Maybe the option could work like dhcp-vendorclass does now for recieved 
> vendor identifier strings, allowing you to reclass special machine types 
> to their own bootfiles/servers:
> 
> dhcp-arch=peecees,00:00 #x86-32
> dhcp-arch=itanics,00:02 #IA64 dhcp-arch=hammers,00:06 #x86-64
> dhcp-arch=mactels,00:07 #EFI x86-64
> 
> Here are examples of the option's current usage by ISC dhcpd:
> https://pyre.virge.net/doc/elilo/examples/netboot/dhcpd-pxe.conf
> http://www.mail-archive.com/et-mgmt-tools@redhat.com/msg01051.html
> 

Agreed that this would be a good thing to have, and agreed that it's not 
currently possible.

My first thought was that it might be better, rather than adding yet 
another keyword, to extend dhcp-match to match the contents of the 
option, using the same hex-and-wildcards data representation that 
dhcp-mac uses.

So your first example would become
dhcp-match=peecees,93,00:00

The same facility would then also be useful for the other options 
defined in RFC4578, and possibly others.

The only fly in the ointment is that RFC4578 specifies that option 93 
can hold _more_than_one architecture spec, and the above syntax is not 
rich enough to match that; to do so brings us back to a special keyword 
and associated code.

I wonder if more-than-one-arch-spec is ever used: the ISC example code 
you pointed at doesn't take it into account. Does anybody know?

Cheers,

Simon.