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

Christian Ehrhardt christian.ehrhardt at canonical.com
Mon Jun 21 05:58:06 UTC 2021


On Tue, Jun 15, 2021 at 10:48 PM Simon Kelley <simon at thekelleys.org.uk> wrote:
>
> 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.

Thank you for the reply, I hope you are in a better situation now.
If not best of luck to further resolve it.

> 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

Unless the effort explodes IMHO It is not so much about where we fix
it but about
what the right long term would be conceptually, thanks for explaining.
I've pinged Iain (who has started the discussion) on the related Ubuntu bug
and set him on CC again here so he can share his input on this.

> 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
> >
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss



-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd



More information about the Dnsmasq-discuss mailing list