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 >>> Dnsmasqfirstname.lastname@example.org >>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >>> >> >> >> _______________________________________________ >> Dnsmasq-discuss mailing list >> Dnsmasqemail@example.com >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >> > _______________________________________________ Dnsmasq-discuss mailing list Dnsmasqfirstname.lastname@example.org http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss