On 28/10/2019 02:45, James Feeney wrote:
> 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?
I think it's a definite bug. If the dhcp-host line sets a name for the
host, then dhcp-name-match NEVER matches that name OR the one supplied
by the host. That's wrong.
The question is, is 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 be 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.
Patch in git now, fixing DHCPv4 and DHCPv6
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=6ebdc95754cbae1cea376f4856634377566485c0
Cheers,
Simon.
>
>
> 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@lists.thekelleys.org.uk
>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>>
>>
>>
>> ___
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss@lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
