Red Hat Bugzilla – Bug 970293
Activates both wired and wireless devices
Last modified: 2015-02-18 06:11:59 EST
Description of problem:
NetworkManager activates both wired and wireless devices at the same time. This causes ambiguous routing tables like
# ip route
default via 192.168.46.254 dev eth0 proto static
192.168.46.0/24 dev eth0 proto kernel scope link src 192.168.46.11
192.168.46.0/24 dev wlan0 proto kernel scope link src 192.168.46.19
and makes it impossible to use the same ip address for both devices.
With setup above, data can be sent over the slow wireless interface, although fast ethernet is available. There is created unneeded radiation and power consumption too.
There should be added some configuration option (e.g. redundancy/failover pools of interfaces with adjustable priorities) so that only one interface is active at a time.
Version-Release number of selected component (if applicable):
this has already been discussed in bug #454955 ... but things have changed over time, maybe it could be reconsidered?
having to disable autoconnecting to wifi and then connecting manually if no ethernet is available is a royal PITA :-(
btw, one of the ways how to automate is here:
... could we at least get this dispatcher script preinstalled, and a GUI checkbox to activate/deactivate it, if there is no better solution on the NM roadmap?
Every GUI solution is not an option for me because login requires NFS mounted /home which requires network. And not every laptop has a physical rfkill switch.
The script idea looks promising; I will see how it will work for my use case (the ultimate goal is to use the same ip address for eth0 and wlan0 because NFS does not behave well when client address changes)
The routes not getting assigned the right priorities was a bug which was fixed recently upstream and will be in NM updates for fedora soon. With these new builds you should see a 'metric' item:
192.168.1.0/24 dev p4p1 proto kernel scope link src 192.168.1.135 metric 1
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.190 metric 9
where the higher metric items will be chosen for traffic and thus the routing is not ambiguous.
NetworkManager-0.9.8.2-1.fc19,network-manager-applet-0.9.8.2-1.fc19 has been submitted as an update for Fedora 19.
ok; routes are not ambiguous anymore. But it still does not allow to use the same ip address for both interfaces. Extra power consumption and unneeded radiation are not solved either.
fwiw, the script from comment #1 works perfectly for my use case. wlan0 gets assigned the MAC of eth0 and both interfaces get same ip from dhcp server. After removing laptop from docking station (-> eth0 gets disconnected), wlan0 gets up and NFS /home is usable without synchronization delays. Ditto for placing it on docking station again.
Of curse, script will not cover all use cases (e.g. when there are multiple wireless interfaces) but they are not interesting for me atm.
NetworkManager-0.9.8.2-1.fc19, network-manager-applet-0.9.8.2-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
This message is a notice that Fedora 19 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 19. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 19 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.