Re: 5f47182 fix has regressed in 1.2-beta1

[Tore Anderson <tore fud no>]

* Thomas Haller

> from the logfile, NM is assuming the device and should not interfere.
> Especially it does not remove the routes.
>
> NM does however set the addrgenmode first to "none" then back to
> "eui64". But according to my tests, that would not cause the deletion
> of the route.
>
> Dunno. Are you sure it's caused by NetworkManager? And it does not
> happen with v1.0?

I've not had this problem with NM-1.0 (the standard F23 RPMs), and
there's been no other changes to the system that seem remotely
relevant, so to me it does indeed look like it is caused by NM.

> btw. now all outstanding branches for 1.2-beta2 are merged. If you
> could, it would be great if you could retest current master.

I can still reproduce it with NM git master from yesterday evening
(6dc431b). It doesn't happen every time, so it is probably some kind of
race condition.

I've attached log with debug messages from NM and clatd as well as
output from "ip monitor" here: http://filebin.net/fr71uh512e/journal.txt

What happens is that NM gets started, auto-connects to an IPv6 only
WLAN, and then starts clatd from a dispatcher script. (I'm somewhat
sceptical that the messages from the three different systemd services
are 100% in order.) It's the route to
2a02:fe0:c421:2034:b6b6:76c1:a717:2e83 on the "clat" interface that
goes AWOL in the end, breaking clatd's functionality.

Curiously enough, during the connection setup clatd gets started three
times instead of the expected one. That shouldn't be a problem in
itself, but I'll try to investigate that further as well as do a
git-bisect run later this week.

Tore