[Dnsmasq-discuss] Proposal for DHCP Option 93 capture

Simon Kelley simon at thekelleys.org.uk
Sun Dec 28 17:31:33 GMT 2008

Joey Korkames wrote:

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

I've implemented something which ticks all the boxes, and adds a trivial
amount of extra code: the trick is that the same code that parses
dhcp-option can be used to parse dhcp-match. This gives the added
advantage of named options, and the ability to give the matching code
knowledge of the size of data types - this becomes important later.

The hex-n-wildcards option is supported, so

dhcp-match=tag,<option number>,00:11:*:33


With other data types, the matching code assumes that it's receiving an
array of values, and matches each one, so

dhcp-match=hammers, option:client-arch, 6

knows that "client-arch" is option 93, and expects 16bit integers. It
will therefore search the array of integers sent by the client, and set
the tag if any of them equals 6. This gives full RFC 4578 goodness.

Your examples become:

dhcp-match=peecees, option:client-arch, 0 #x86-32
dhcp-match=itanics, option:client-arch, 2 #IA64
dhcp-match=hammers, option:client-arch, 6 #x86-64
dhcp-match=mactels, option:client-arch, 7 #EFI x86-64

Test code here.


If Sam is still around, this release includes a generalisation of your
encapsulated option patch, too.



More information about the Dnsmasq-discuss mailing list