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
signature.asc
Description: PGP signature
_______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
