GNOME Bugzilla – Bug 689742
NM activates connection twice when both ipv4 and ipv6 are enabled
Last modified: 2013-08-13 18:55:12 UTC
Created attachment 230839 [details] NetworkManager log Version: 0.9.6.4 I use dhcpv4 an radvd and a connection which has method=auto for both ipv4 and ipv6 (connection file attached). When I start NetworkManager, it establishes the connection, after a few seconds it down's the connection again and activates it again. After that the connection is stable. Attached are the log files for NetworkManager, the dispatcher and the output of ifconfig before NetworkManager was started and after it has successfully established the connection.
Created attachment 230840 [details] connection config
Created attachment 230841 [details] dispatcher log
Created attachment 230842 [details] ifconfig before
Created attachment 230843 [details] ifconfig after
I have to add, this problem is only reproducible directly after NetworkManager has been started. Once NetworkManager is running, subsequent attempts to activate the connection to not yield this behaviour
(In reply to comment #5) > I have to add, this problem is only reproducible directly after NetworkManager > has been started. Once NetworkManager is running, subsequent attempts to > activate the connection to not yield this behaviour That's important. It may have various reasons.
One more detail which is apparently important to be able to reproduce the bug: I've tested this with a ethernet-type connection. 1/ I've booted the system, NM starts and correctly configures the eth0 interface 2/ shutdown NetworkManager (service NetworkManager stop). Notice how eth0 is still configured with the ipv4 and ipv6 address (ifconfig before). 3/ start NetworkManager --no-daemon --log-level=debug and now the problem can be obversed. If I down the interface between 2/ and 3/ (e.g. via rmmod/modprobe or ifconfig eth0 down), the problem does *not* occur. So the issue is most likely related to the fact that eth0 has an existing configuration. In theory, NM should actually pick up the existing configuration and *not* run dhclient again so the interface stays up all the time
Another problem with the long buggy 'assume' functionality.
*** Bug 691958 has been marked as a duplicate of this bug. ***
NM bugzilla reorganization. Sorry for the bug spam.
(In reply to comment #7) > In theory, NM should actually pick up the existing configuration and *not* run > dhclient again so the interface stays up all the time Just a remark. This is not entirely true, even for existing configuration, the dhclient process has to be started again.
It seems to be the case that the IPv6 RA-provided address is lost and that's causing the initial IPv6 configuration to fail. Perhaps that's due to touching accept_ra unconditionally in the ip6-manager code? Or possibly due to: /* Bounce IPv6 on the interface to ensure the kernel will start looking for * new RAs; there doesn't seem to be a better way to do this right now. */ if (device->target_state >= NM_IP6_DEVICE_GOT_ADDRESS) { nm_utils_do_sysctl (device->disable_ip6_path, "1"); g_usleep (200); nm_utils_do_sysctl (device->disable_ip6_path, "0"); } which may make the kernel remove the address and then add it back when the next RA comes? We need to make the IPv6 code more aware of connection assumption here; I believe that's been on the to-fix list for a while.
(In reply to comment #12) > It seems to be the case that the IPv6 RA-provided address is lost and that's > causing the initial IPv6 configuration to fail. Perhaps that's due to touching > accept_ra unconditionally in the ip6-manager code? > > Or possibly due to: > > /* Bounce IPv6 on the interface to ensure the kernel will start looking for > * new RAs; there doesn't seem to be a better way to do this right now. > */ > if (device->target_state >= NM_IP6_DEVICE_GOT_ADDRESS) { > nm_utils_do_sysctl (device->disable_ip6_path, "1"); > g_usleep (200); > nm_utils_do_sysctl (device->disable_ip6_path, "0"); > } > > which may make the kernel remove the address and then add it back when the next > RA comes? We need to make the IPv6 code more aware of connection assumption > here; I believe that's been on the to-fix list for a while.
(In reply to comment #12) > It seems to be the case that the IPv6 RA-provided address is lost and that's > causing the initial IPv6 configuration to fail. Perhaps that's due to touching > accept_ra unconditionally in the ip6-manager code? > > Or possibly due to: > > /* Bounce IPv6 on the interface to ensure the kernel will start looking for > * new RAs; there doesn't seem to be a better way to do this right now. > */ > if (device->target_state >= NM_IP6_DEVICE_GOT_ADDRESS) { > nm_utils_do_sysctl (device->disable_ip6_path, "1"); > g_usleep (200); > nm_utils_do_sysctl (device->disable_ip6_path, "0"); > } > > which may make the kernel remove the address and then add it back when the next > RA comes? We need to make the IPv6 code more aware of connection assumption > here; I believe that's been on the to-fix list for a while. nm-ip6-manager is no longer used with the introduction of userspace router discovery. (In reply to comment #7) > In theory, NM should actually pick up the existing configuration and *not* run > dhclient again so the interface stays up all the time dhclient is only being used for the DHCP transactions and *must* be started again to RENEW the DHCP lease in time. It is not related to keeping or not keeping the interface up. The notable line in the attached log is: NetworkManager[10477]: <error> [1354745459.572279] [nm-system.c:1221] nm_system_replace_default_ip6_route(): (eth0): failed to set IPv6 default route: -7 The failure is apparently linked to the way nm-ip6-manager and kernel autoconfiguration worked. As nm-ip6-manager is no longer part of NetworkManager git master and the problematic kernel autoconfiguration is no longer used, this bug is fixed. Please reopen if you are interested in solution for the older versions. You might want to make sure that connection assumption is not performed when IPv6 is configured, that it doesn't affect IPv6, and/or set the interface down+up instead of disabling+enabling IPv6 on it in nm-ip6-manager. Please start a new bug report if you find a bug in userspace router discovery in git master.