On Wed, Oct 30, 2019 at 09:32:14PM +0000, Simon Kelley wrote: > 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 > Seeing "DHCPv6" did me wonder if http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q4/012707.html still would apply. It did.
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss