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


James



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