GNOME Bugzilla – Bug 726177
[review] th/rh907836_rename_iface: follow interface renames
Last modified: 2015-02-17 13:08:32 UTC
Upstream clone of https://bugzilla.redhat.com/show_bug.cgi?id=907836 which is private for various customer reasons. NM has never correctly handled interface renames, which can happen at bootup when NM is racing with udev. Now that udev renames pretty much everything, this happens a lot more often, and NM should really handle it. DHCP needs to be restarted if the rename happens when DHCP is active, and same goes for RA though that's less of a concern as all the RA code uses ifindex, not interface name.
Thomas' branch has already gone through a round or two of review, and some patches were split off into th/cleanup_read_sysfs and th/refactor_platform.
Branch passes my light testing, although I can't get NM to race with udev even on my SSD-based system. +1 on the merge from me.
First part of the patch was merged as http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=a0fc5098b379e788ac20f69d0abc11fbca5cf7e7 Following parts are still missing: (1) if you do `ip link set em1 down ; ip link set em1 name em2; ip link set em2 up` NM does not disconnect the connection. Depending on ignore_carrier, it either does not care about downing the interface, or it waits for 4 seconds before it starts downing the connection. However it does restart DHCP4 and DHCP6. In case of DHCP6 there still is the problem, that the device has no LL address initially and DHCP6 will fail because of that. See separate bug 726280 for that. (2) rdisc does not get restarted either. The consequences of this are not yet clear. (3) any other??? (1) and (2) however should have as worst case, that the connection has to be restarted. Thus, the patches so far already help a lot, because the device *is* still usable after renaming.
(In reply to comment #3) I would say, that fixing DHCP6/LL should be handled as bug 726280. The remaining issues for this bug are restart of RDisc and possibly other (firewalld, avahi, ???).
This bug stayed open for possible further issues that are to be fixed when renaming an interface. > (1) and (2) however should have as worst case, that the connection has to be > restarted. Thus, the patches so far already help a lot, because the device > *is* still usable after renaming. There are no concrete problems at this point, hence I close this bug. Let's open a new bug, when something concrete comes up.