[Dnsmasq-discuss] dhcp-name-match ?

Geert Stappers stappers at stappers.nl
Sun Nov 10 09:40:42 GMT 2019


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.



More information about the Dnsmasq-discuss mailing list