[Dnsmasq-discuss] dhcp-name-match ?
james at nurealm.net
Mon Oct 28 02:45:31 GMT 2019
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
> On 22/10/2019 15:43, James Feeney wrote:
>> dnsmasq 2.80-4
>> Arch Linux
>> $ 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?
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss at lists.thekelleys.org.uk
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
More information about the Dnsmasq-discuss