On 05/12/2019 22:48, Simon Kelley wrote:
> On 15/11/2019 03:53, James Feeney wrote:
>> Hey Simon
>>
>> On 11/8/19 4:36 PM, Simon Kelley wrote:
>>> If there's no name configured in the dnsmasq configuration, then the
>>> client-provided name will be matched. However if there is a name
>>>
On 15/11/2019 03:53, James Feeney wrote:
> Hey Simon
>
> On 11/8/19 4:36 PM, Simon Kelley wrote:
>> If there's no name configured in the dnsmasq configuration, then the
>> client-provided name will be matched. However if there is a name
>> configured in the dnsmasq configuration, selected by MAC
On 11/17/19 9:58 AM, James Feeney wrote:
On 11/14/19 10:17 PM, Geert Stappers wrote:
I look forward to the change proposal.
Learn to read English for comprehension, and then refer back to the post you
quoted.
he's saying submit a patch and see what happens ;)
--
NOTE: No off-list
On 11/14/19 10:17 PM, Geert Stappers wrote:
> I look forward to the change proposal.
Learn to read English for comprehension, and then refer back to the post you
quoted.
> Zero fuck giving how much disagreement there might be.
> What matters is where we agree.
We may agree that dnsmasq is
On Thu, Nov 14, 2019 at 08:53:07PM -0700, James Feeney wrote:
> On 11/8/19 4:36 PM, Simon Kelley wrote:
> > If there's no name configured in the dnsmasq configuration, then the
> > client-provided name will be matched. However if there is a name
> > configured in the dnsmasq configuration,
Hey Simon
On 11/8/19 4:36 PM, Simon Kelley wrote:
> If there's no name configured in the dnsmasq configuration, then the
> client-provided name will be matched. However if there is a name
> configured in the dnsmasq configuration, selected by MAC address or
> client-id, then that will be used in
On Wed, Oct 30, 2019 at 09:32:14PM +, 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
On 07/11/2019 03:52, James Feeney wrote:
> Hey Simon
>
> On 10/30/19 3:32 PM, Simon Kelley wrote:
>> The question is, [if] 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
Hey Simon
On 10/30/19 3:32 PM, Simon Kelley wrote:
> The question is, [if] 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
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.
>
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
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
12 matches
Mail list logo
