[Dnsmasq-discuss] dhcp-name-match ?

James Feeney james at nurealm.net
Mon Oct 28 02:45:31 GMT 2019

Hey Simon

Thanks for that.  Yes, that's it.

I tried simply removing the dhcp-host hostname, and then the tag is added, as expected.

Yes, that does not seem to be an "expected" behavior, dhcp-host interacting with dhcp-name-match.

>From reading the man page, at dhcp-host:

This allows a machine with a particular hardware address to be always allocated the same hostname, IP address and lease time. A hostname specified like this overrides any supplied by the DHCP client on the machine.

This would seem to imply that dnsmasq would just offer the dhcp-host specified hostname in the options returned, and not otherwise discriminate against the client.

*Without* the dhcp-host hostname, dnsmasq simply "reflects" the hostname provided by the client:
option: 12 hostname  NPI8C840E

And *with* the dhcp-host hostname specified, "NPI8C840E" in this case, dnsmasq simply offers that dhcp-host hostname, but converted to lower-case - where DNS is not case sensitive, of course:
option: 12 hostname  npi8c840e

It seems to make no difference whether the dhcp-host hostname is specified with just the hostname part, or as a FQDN, with both the hostname part "dot" the domain name part.

So, all in all, I'd interpret that as a bug, that dhcp-name-match is failing when a dhcp-host hostname is specified.

Even if the "client provides name:" value were something wild, and nothing to do with the specified hostname, I don't know that there would be any reason to ignore that wild client provided name.  I could imagine that some appliance might both provide a client name and, at the same time, always ignore the offered dhcp hostname.  We might still want to be able to "tag" that appliance.

What do you think?


On 10/22/19 4:31 PM, Simon Kelley wrote:
> Looking at the code, the only obvious explanation is if you are
> over-riding the hostname in the dnsmasq configuration, ie with dhcp-host.
> In that case the client-provided name is ignored, including for the
> purposes of dhcp-name-match. (This may be a bug, but it is also an
> explanation.)
> Simon
> On 22/10/2019 15:43, James Feeney wrote:
>> dnsmasq 2.80-4
>> Arch Linux
>> /etc/dnsmasq.conf
>> dhcp-name-match=set:printer,NPI*
>> $ journalctl -ab
>> ...
>> client provides name: NPI8C840E.prime
>> ...
>> tags: known, enp4s0
>> Uhm - so, did I miss something?  Or, is "dhcp-name-match=" broken?
>> Why is the tag "printer" not been appended to the list of tags?
>> The similar "dhcp-vendorclass=" seems to work as expected.
>> Is "dhcp-name-match=" different in some way?
>> Thanks
>> James
>> _______________________________________________
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss at lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

More information about the Dnsmasq-discuss mailing list