[Dnsmasq-discuss] Method to get Dnsmasq serve address of a host from interface address

[Simon Kelley]

Thanks for the bug report, it's definitely not noise.

The history of line 363 is interesting.

When the dynamic-host option was added, it looked like

if (netmask.s_addr == 0xffff)


and stayed like that until October 2022 when it got changed to the 
current version

if (netmask.s_addr == 0xffffffff)

That's what was released as part of 2.88

So that explains why it used to work for you, and no longer does in 2.88 
and 2.89. If your PPoe interface had netmask 255.255.0.0 then it would 
not have worked previously, but would work now.

The change was prompted by this email to the list.

https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2022q4/016607.html

and the explanation that it looks like the intention was to skip 
interfaces with /32 prefixes looks pretty sensible, so the patch went in 
without too much thought.

My dilemma is that I can't see the reason to do that and I have no 
recollection of why I might done it in early 2021 when dynamic-host was 
first implemented. Someone should invent a way to core-dump human brain 
state to git for future reference.

The best I can come up with is that what you are trying to do is not 
what I expected dynamic-host to be used for. I expected it to be used to 
name hosts on an internal network whose prefix was supplied by the ISP, 
typically in IPv6-land with prefix delegation. So the host is not the 
one running dnsmasq but another host connected to the same network as 
the interface but with a suffix. Clearly that can only exist when the 
prefix length is smaller than 32(IPv4) or 128(IPv6).

Actually, it's reasonable not to have considered your "weird hack", 
because dnsmasq has had an explicit mechanism to do what you want for a 
long time, interface-name. You could just use.

interface-name=myip.my.local.domain,dsl-provider

So.

There's an easier way to do what you want to do.
Your "weird hack" used to work because the code that was supposed to 
stop it used to be buggy and didn't.
The bug got fixed in 2.88 and now does stop your weird hack.
There's a very limited need for the once-buggy, now fixed code and I 
can't really remember what it was for.

Going forward we have three options for line 363

1) revert the October 2022 change. That would be stupid.
2) leave as is and educate people to use interface-name for this and not 
hack dynamic-host
3) remove it so that people skimming the man page who find dynamic-host 
before they find interface-name and rediscover your "weird hack" are not 
bewildered. This would also avoid people who found and used the "weird 
hack" in pre-2.88 releases from suffering a regression when they upgrade.


For that last reason alone, I propose option 3.


Comments?



Cheers,

Simon.

On 13/03/2023 00:31, 0zl wrote:
> Well, it seems like dnsmasq just ignores addresses with /32s. I see in 
> src/network.c for some reason if an interface has 255.255.255.255 it 
> just skips it (line 363)?
> 
> This might possibly the cause for the issue, I'm not sure if this is 
> intentional or some sort of bug.
> 
> Thanks again and sorry for the noise!
> 
> 
> On 3/13/23 02:08, 0zl wrote:
>> Hi everyone,
>>
>> Previously on Debian Stable, I was using dynamic-host as a weird hack 
>> to get Dnsmasq to serve my PPPOE interface's IP address however this 
>> no longer seems to work with the Dnsmasq supplied in Debian Testing.
>>
>> It was OK to just specify 0.0.0.0 as my ISP would allocate for me a 
>> /32 and so this thankfully matched my interface address and worked 
>> properly.
>>
>> Now that this no longer works on 2.89, are there any alternatives I 
>> could use?
>>
>> (What no longer works is 
>> `dynamic-host=myip.my.local.domain,0.0.0.0,dsl-provider` and Dnsmasq 
>> fails with `warning: no addresses found for interface dsl-provider`)
>>
>> TIA
>>
>>
>>
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>