[Dnsmasq-discuss] RA-acquired address not marked as 'dynamic' with 2.82

[Simon Kelley]

On 02/06/2021 09:18, Christian Ehrhardt wrote:
> On Mon, Jan 25, 2021 at 4:28 PM Christian Ehrhardt
> <christian.ehrhardt at canonical.com> wrote:
>>
>> On Thu, Sep 17, 2020 at 8:57 AM Christian Ehrhardt
>> <christian.ehrhardt at canonical.com> wrote:
>>>
>>> Hi,
>>> since nothing happened on this topic (e.g. committed to git / further
>>> discussion) I wondered if you waited for a confirmation.
>>>
>>> The first patch by Iain was ignored or not seen, I'd expect both might work.
>>> Nevertheless in case there was any (hidden) reason I picked the second
>>> patch suggested at:
>>> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q3/014346.html
>>>
>>> I built dnsmasq 2.82 with it and ran the various Ubuntu tests against it.
>>> I wanted to state that this made it fully work again from my POV and
>>> hope that it can be considered to be applied.
>>>
>>
>> @Simon - Re-ping
> 
> And re-ping again we are at 2.85 and Ubuntu still has to carry this
> patch that came up in the original discussion:
> 


Arg, apologies for ignoring you all on this. I was having a bad time,
pandemic-wise, when this first came up, and it slipped through.

I'm not sure that the patch(es) are fixing the problem here, rather than
band-aiding the symptoms.

The intention is that the advertised time should be based on the
lifetime of the relevant address on the interface through which dnsmasq
is sending the advert. There is a configured time (in the dhcp-range
statement), that can reduce this time, and a floor, specified by the
RFC, which can increase it. There's also a default for configured time.

The basic change which broke things is that the default stopped applying
to RA, it now only applies to DHCPv6. I think that's a sensible thing to
do: If you're advertising a router and subnet over an interface which
has an address of infinite lifetime on that subnet, it's fine to make
all the other addresses in that subnet infinite too.

There are two valid ways to reduce that lifetime. 1) configure the
interface with an address with a lower lifetime, or 2) explicitly
configure a lower time, with something like

dhcp-range=::,constructor:eth0,slaac,1d

I realise that both of those changes are probably networkmanager things,
but I'd rather fix that than re-break dnsmasq to sort it. There's also
the possibility that the new behaviour is actually correct, and the fix
is simply to change the tests to reflect that.


Cheers,

Simon.

> diff --git a/src/radv.c b/src/radv.c
> index 3255904b..d10f2b6b 100644
> --- a/src/radv.c
> +++ b/src/radv.c
> @@ -628,8 +628,9 @@ static int add_prefixes(struct in6_addr *local,  int prefix,
> 
>   /* find floor time, don't reduce below 3 * RA interval.
>      If the lease time has been left as default, don't
> -    use that as a floor. */
> - if ((context->flags & CONTEXT_SETLEASE) &&
> +    use that as a floor.
> +    Always set lease time if requested to do so. */
> + if ((context->flags & CONTEXT_SETLEASE) ||
>       time > context->lease_time)
>     {
>       time = context->lease_time;
> 
> History on this
> Submitted and Discussed:
>  https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q3/014341.html
> Pinged:
>  https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q3/014387.html
>  https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q1/014639.html
> 
> 
> 
>> We now have had 2.83 (released for CVEs) so some activity is happening
>> again I guess.
>> So I thought it might be worth to ping on this "old issue with known
>> fix" once more.
>>
>>> P.S. I wasn't subscribed before so I can't reply directly, due to that
>>> it might be broken up in the tree view of the ML archive, sorry for
>>> that
>>>
>>> --
>>> Christian Ehrhardt
>>> Staff Engineer, Ubuntu Server
>>> Canonical Ltd
>>
>>
>>
>> --
>> Christian Ehrhardt
>> Staff Engineer, Ubuntu Server
>> Canonical Ltd
> 
> 
> 
> --
> Christian Ehrhardt
> Staff Engineer, Ubuntu Server
> Canonical Ltd
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>