GNOME Bugzilla – Bug 683206
maximize device availability (IFF_UP/IFF_LOWER_UP) for IPv6 link-local communication during runtime and after exit
Last modified: 2016-02-23 10:15:53 UTC
Wired devices should be kept up when NetworkManager exits. It should not be based on any 'connection assume' magic and it should work every time the same. The same applies to its IPv4 and IPv6 configuration. The purpose of this feature is not (only) to cope with 'assume' use cases. Wired networking is often the only way to access the host without physical contact. This feature will provide robustness in the following use cases. 1) IPv6 link-local addresses can be *always* used to access the host from a neighboring network device. 2) IPv4 and IPv6 global addresses can be used to access the host unless the administrator explicitly breaks the configuration. If he breaks it, there is still (1) or there could be a rollback watchdog (later implemented in NM or separately). 3) NetworkManager can be restarted (e.g. to run a new version) without address configuration being disturbed. Without 'connection assume' magic, this will work with granularity down to individual IPv4 and IPv6 addresses. 4) In future, NetworkManager could be set up to exit when it only manages static configuration and is therefore not needed to run permanently. This is only suitable for very specific use cases. I may have forgotten something.
I wonder if we should just keep the interfaces up even when we don't exit NetworkManager but mark the device unmanaged. It would be the easiest way to implement this and it would be a reasonable measure to prevent a remotely configured NetworkManager from disconnected a device the administrator only wanted to take out of management by NetworkManager (e.g. for his own manual testing). That said, 'unmanage device' would not imply 'tear down configuration'.
This should also work for bridges and bonds but sometimes it's not a good idea to leave virtual devices behind. I thing this should be at least configurable.
From duplicate: Harry Monroe [reporter] 2012-10-26 18:04:18 UTC When i'm going to sleep mode NetworkManager takes the eth0 device down. Result: WakeOnLan won't work Workaround: disable NetworkManager, manually edit /etc/network/interfaces, ifup eth0, WOL works. Pavel Simerda [NetworkManager developer] 2013-05-09 10:58:37 UTC (In reply to comment #0) > Workaround: disable NetworkManager, manually edit /etc/network/interfaces, ifup > eth0, WOL works. A better workaround might be upping the interface via dispatcher.d scripts.
*** Bug 686951 has been marked as a duplicate of this bug. ***
Created attachment 243848 [details] [review] Simple patch, no guarantees.
For suspend/resume, NM should actually just leave devices up and handle any udev events for hotplug on resume (ie, rely on the kernel/udev to send the right events). For now, it should move them to DISCONNECTED, but in the future we may actually just want to leave addresses/routes/etc on the interface and attempt to confirm they are still valid on resume by running a DHCP RENEW or sending an IPv6 SOLICIT.
(In reply to comment #6) > For suspend/resume, Looks like that's only loosely related, as this ticket was about NetworkManager exit, not sleep. > NM should actually just leave devices up and handle any > udev events for hotplug on resume (ie, rely on the kernel/udev to send the > right events). For now, it should move them to DISCONNECTED, but in the future > we may actually just want to leave addresses/routes/etc on the interface and > attempt to confirm they are still valid on resume by running a DHCP RENEW or > sending an IPv6 SOLICIT.
My mistake, I added information from the other bugreport myself. Plus I agree with your points regarding the sleep, the question is, whether DISCONNECTED implies !IFF_UP or not.
(In reply to comment #0) > 1) IPv6 link-local addresses can be *always* used to access the host from > a neighboring network device. Connection assumption is currently being reworked as part of bug 702488 which keeps IPv6 in mind. Also, we're using userspace IPv6 autoconfiguration (bug 699772) in git master. Therefore only localhost (::1) and link-local (fe80::...) addresses are now managed by the kernel. Therefore the only thing needed to keep IPv6 link-local communication is to keep the device up (IFF_UP) and connected (IFF_LOWER_UP). Managed wired interfaces are AFAIK currently being kept up all the time but it needs more checking. On NetworkManager exit, we should IMO to make sure wired devices are not being set down. It may contradict with some of my remarks in bug 682932, though, so we need a careful decision over all of the related issues/features. > 2) IPv4 and IPv6 global addresses can be used to access the host unless > the administrator explicitly breaks the configuration. If he breaks it, > there is still (1) or there could be a rollback watchdog (later implemented > in NM or separately). This is expected as part of bug 702488, therefore can be discarded. > 3) NetworkManager can be restarted (e.g. to run a new version) without > address configuration being disturbed. Without 'connection assume' > magic, this will work with granularity down to individual IPv4 > and IPv6 addresses. The implementation done for bug 702488 is something in between. We still want to be able to find a configured connection matching the kernel configuration status for temporary/persistent configuration workflow but we indeed now perform IP configuration even for assumed connections including the DHCP/rdisc workflows. This point can be discarded as dupe to 702488. > 4) In future, NetworkManager could be set up to exit when it only manages > static configuration and is therefore not needed to run permanently. This > is only suitable for very specific use cases. To my knowledge, we don't plan such a feature any soon. I still have some thoughts on that and may eventually write it down in a separate bug report, but for now we can just ignore this point. The only remaining issue is #1 which can be summarized as a request to maximize the administrative availability (IF_UP) of the interface both during runtime and after NetworkManager exit. Changing the summary accordingly. For example, a managed wired device can be kept running during the whole NetworkManager runtime (unless there's an explicit reason to do otherwise) and as well be kept running after exit. A wireless device is usually out of discussion anyway.
See: https://fedoraproject.org/wiki/Networking/Ideas/NetworkManagerMethods#DISCONNECTED_state_considerations There are also links to bugs whose resolution might affect (positively or negatively), the feature described in this bug report.
This bug has a wide scope. Some things already work: (In reply to Pavel Simerda from comment #0) > Wired devices should be kept up when NetworkManager exits. It should not be > based on any 'connection assume' magic and it should work every time the > same. The same > applies to its IPv4 and IPv6 configuration. > > The purpose of this feature is not (only) to cope with 'assume' use cases. > > Wired networking is often the only way to access the host without > physical contact. This feature will provide robustness in the following > use cases. > > 1) IPv6 link-local addresses can be *always* used to access the host from > a neighboring network device. > > 2) IPv4 and IPv6 global addresses can be used to access the host unless > the administrator explicitly breaks the configuration. If he breaks it, > there is still (1) or there could be a rollback watchdog (later implemented > in NM or separately). > > 3) NetworkManager can be restarted (e.g. to run a new version) without > address configuration being disturbed. Without 'connection assume' > magic, this will work with granularity down to individual IPv4 > and IPv6 addresses. All the above should already work (otherwise, let's open a new issue). > 4) In future, NetworkManager could be set up to exit when it only manages > static configuration and is therefore not needed to run permanently. This > is only suitable for very specific use cases. This is partly fixed using "configure-and-quit" configuration option, which spawns the nm-iface-helper to babysit DHCP. Arguably, that solution has it's own flaws and we want to improve on that by: - possibly also support restart for Wi-Fi/VPN/etc - better pickup after restart. Anyway, let's open a new bug for this and it's anyway on our minds as a long-term goal. (In reply to Pavel Simerda from comment #1) > I wonder if we should just keep the interfaces up even when we don't exit > NetworkManager but mark the device unmanaged. It would be the easiest way > to implement this and it would be a reasonable measure to prevent > a remotely configured NetworkManager from disconnected a device the > administrator only wanted to take out of management by NetworkManager > (e.g. for his own manual testing). > > That said, 'unmanage device' would not imply 'tear down configuration'. This is fixed too. nmcli device set $DEV managed no works as described (otherwise, open new bug). (In reply to Pavel Simerda from comment #2) > This should also work for bridges and bonds but sometimes it's not a good > idea > to leave virtual devices behind. I thing this should be at least > configurable. works too, but not configurable. I'm closing this bug as FIXED. Let's open new, more specific bugs in case something is missing or not working as desired.