[Dnsmasq-discuss] Proposal for DHCP Option 93 capture

Joey Korkames joey+lists at kidfixit.com
Fri Dec 26 08:39:57 GMT 2008


>> 
>> 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
>> 
> 
> 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

I really like this idea - a custom force match for recieved options to go 
along with the existing means of forcing options to be sent back.
This brings dnsmasq a lot of parity with ISC DHCP, minus all the crazy 
math/variable transformation functions for composing reply values.

> 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.

Well, one could write multiple statements (of the dhcp-match syntax) for all 
the possible variations of the option value that they can observe at their 
site (with dhcpdump). Or perhaps added support for matching against regular 
expressions. Its such an obscure (but useful) option that it may be best to 
only minimally support it until its current implementation by clients 
becomes more apparent (and fleshed out further with DHCPv6).

-joey




More information about the Dnsmasq-discuss mailing list