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 23/10/19 8:04 am, Sean Warner wrote:
Hello,
Thank you for answering Uwe. Your response gave me some good pointers.
I don’t think a “default domain” entry is coming from my Windows
laptop. It’s Windows 7 Home Premium and that version knows nothing
about domains. I googled that and also to
On Tue, Oct 22, 2019 at 10:04:37PM +0100, Sean Warner wrote:
>
> I don't think a "default domain" entry is coming from my Windows laptop.
> It's Windows 7 Home Premium and that version knows nothing about domains. I
> googled that and also to see if Chrome maybe adds in a .home if a domain is
>
Hello,
Thank you for answering Uwe. Your response gave me some good pointers.
I don't think a "default domain" entry is coming from my Windows laptop.
It's Windows 7 Home Premium and that version knows nothing about domains. I
googled that and also to see if Chrome maybe adds in a .home if
On 22/10/2019 17:17, Normen Kowalewski wrote:
FAIW - i was curious to see if RFC 8415 of November 2018, the update of
the now officially obsoleted RFC 3315, uses some other wording, but it
also just speaks about 4 octets that jointly are an unsigned integer
Good question. This code happened five years ago, and has not been
touched since. Looking back at the changelog and through my old email
doesn't provide any inspiration. My feeling is that the reason is that
you can't necessarily expect to get back sensible answers from such
servers to queries
Hi Geert, Dominik,
FAIW - i was curious to see if RFC 8415 of November 2018, the update of the now
officially obsoleted RFC 3315, uses some other wording, but it also just speaks
about 4 octets that jointly are an unsigned integer
https://tools.ietf.org/html/rfc8415#section-21.21
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
Hi,
The reason for this is a “default domain” entry in the Windows 7 laptop
configuration, so it is sent by the client in the case of a missing domain. It
was not added by dnsmasq, but by the Windows client.
On the other hand, this still resolves, because you seem to also have a “domain
