GNOME Bugzilla – Bug 761389
don't mess with interface handled by clatd
Last modified: 2016-04-04 13:41:34 UTC
See https://mail.gnome.org/archives/networkmanager-list/2016-January/msg00092.html Just a reminder to fix before 1.2
Created attachment 324294 [details] debug output from when bug occurs Since the filebin with the original logs has expired, here's a new debug log showing the problem occurring. It's taken with NM ecd42cd915 (2016-03-15). Included are also output from "ip monitor" and clatd. The route that gets removed by NM is "2a02:fe0:c420:57e6:c04c:20a8:6378:0 dev clat".
I can reproduce the issue with the following script adapted from bug 740702: #!/bin/sh while true; do ip l del TESTDEV 2> /dev/null ip tuntap add TESTDEV mode tun ip l set TESTDEV up sleep 1 ip a a dev TESTDEV 192.0.0.1/32 ip -6 route add 2001:db8::1 dev TESTDEV sleep 1 if ip -6 route list dev TESTDEV | grep -q 2001:db8::1; then echo 'OK (the route is still there)' else echo 'FAIL (the route has been removed)' fi sleep 5 done When NM detects the new interface it tries to create an in-memory connection to assume, but since there are no addresses assigned this fails, the device is put to DISCONNECTED and user-mode IPv6LL generation is enabled. Later, an IP address and a route are added to the device. This makes the device ready to be assumed and thus NM creates a generated-assumed in-memory connection, reverting to kernel-mode IPv6LL; but this change also removes the externally added IPv6 route. So the cause of the problem seems to be that we deconfigure IPv6 when an interface cannot be assumed or activated, which was an issue reported also in bug 763236. Please review the patch there.
«[PATCH v2] device: don't deconfigure interfaces which can't be assumed or activated» does indeed seem to fix this issue, thank you very much! Tore
Actually, I just noticed that the patch also introduces a rather nasty bug. When unplugging a wired ethernet cable (whose connection was fully managed by NM), the connection goes down (no longer shows in "nmcli c show --active"), but all the IP addresses and routes remain intact. Since the default routes on the wired ethernet has a lower metric than that on the wifi interface, this essentially prevents the machine from successfully failing over to using wifi. Also, when I reconnect the ethernet cable, connectivity is restored, but the connection does not show up in "nmcli c show --active" any longer. So the patch clearly needs more work. Tore
Should be fixed on master with https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=2716c7f11592e00df5a37f181966c97e1ca2ca16