Hey Simon

On 10/30/19 3:32 PM, Simon Kelley wrote:
> The question is, [if] the client-provided name and the dhcp-host name
> differ, which one should be matched? Since this is broken, there's no
> pre-existing behaviour to consider. Any configurations relying on one or
> the other are currently broken [by] definition.
> I've decided that if both exist, then the name from dhcp-host should be
> matched. It seems that if the config explicitly nails a MAC address or
> client-id to a name, that's the one that should be used.

Hmm - if you would, let me make sure I understand, then, how this will work.

I would have thought to make "dhcp-name-match" match against the client 
provided name, since there is nothing that will assure that the client provided 
name is anything different from what the client wants to provide.  The client 
is not, necessarily, going to adopt the hostname provided by the dhcp server.

So then, does the "new" behavior mean that, effectively, "dhcp-name-match" is 
really a kind of "MAC-address-match", or "DUID-match", by way of the dhcp-host 
specified hostname?

I should, then, simply write "dhcp-name-match=<dhcp-host_name_>", where the 
name is just the name associated with the dhcp-host MAC address, or with the 

Also, then, if there is *no* dhcp-host hostname specified, will 
"dhcp-name-match" still match the client provided name?  Or, will that no 
longer work, at all?

A difficulty I see here, is that, if the client DUID or MAC address is *not* 
known, and only the persistent client provided name is offered by the client, 
then there will be no way to actually tag the client, unless every client DUID 
or MAC address is first discovered and manually configured with a hostname.

And then, why not simply have a "dhcp-DUID-match" or a "dhcp-MAC-addr-match", 


Dnsmasq-discuss mailing list

Reply via email to