* 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 _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
