Re: spamming router with router solicitations

[Beniamino Galvani <bgalvani redhat com>]

On Tue, Jun 25, 2019 at 10:20:54AM -0400, Brian J. Murrell wrote:
> On Mon, 2019-06-24 at 08:52 +0200, Beniamino Galvani via
> networkmanager-list wrote:
> > Hi,
>
> Hi Beniamino,
>
> > I checked again the log you sent and I see the problem now. When NM
> > receives a RA, it checks whether the parameters
>
> Which parameters exactly?  Because I might be able to shed some light
> on this now that this is known.

Basically everything in the RA. See how the 'changed' variable is set in:

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/blob/1.18.0/src/ndisc/nm-lndp-ndisc.c#L110

> > changed compared to
> > the previous RA and if so it applies the new configuration. When it
> > does so, it also reapplies the token; this triggers a new router
> > solicitation from kernel due to:
> >
> >   
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv6/addrconf.c?h=v3.10#n4336
>
> Interesting.
>
> > The new RA received is:
> >
> >   neighbor discovery configuration changed [R]:
> >     dhcp-level none
> >     gateway fe80::6eb0:ceff:fef5:1e4a pref high exp 1799.2317
> >     address 2001:123:ab:123::2 exp permanent
> >     route 2001:123:ab:123::/64 via fe80::6eb0:ceff:fef5:1e4a pref
> > high exp permanent
> >     dns_server fd31:aeb1:48df::2 exp 7199.2317
> >
> > Note the "changed [R]" part which means that routes changed. This is
> > strange because according to log there was no change from previous
> > RA. This causes the reapply of token, a new RS, a RA and so on ...
>
> Here is what an RA from my router looks like:
>
> [...]
>
> But three things that the above is not saying:
>
>    1. Until yesterday, the Router Lifetime of one of those RAs was 0 and
>       the other was 1800 (I don't recall which was which).
>    2. Until the last week or two, the first prefix was being advertised
>       with a Router preference of high and the other was medium.
>    3. Each of those two RAs come in two different packets, one for each
>       prefix rather than them both being in the same RA which I think is
>       the typical behaviour.

I think all these should be handled well. But perhaps older versions
of NM had issues with the 0 lifetime of point 1.

> > Apart from this, I think NM should not apply the token when it's
> > already set;
>
> That seems reasonable.

This is now fixed in master:

 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/e4ce9bd7af6a39677ff1a1380906d18062abb24a

and stable branches nm-1-18, nm-1-16.

Beniamino

Attachment: signature.asc
Description: PGP signature