Description of problem: NetworkManager made it normal to have both ethernet and wlan interfaces active. These interfaces are brought up with metric zero, with no way to change that metric. Since (in general) wlan has less bandwidth than ethernet, it must have a higher metric (ideally a metric should be calculated, for example from MII and wlan information). Example: on my home network I have 1Gbps ethernet and 100Mbps wlan. Both interfaces get a metric of 0 with the result that (many times) a connection (large copy) goes over wlan instead of ethernet. This is completely dependent on the order of the routes in the kernel. This is very undesireable: It makes the load on the wlan much higher than needed, makes the network seem much slower than it actually is and makes having these interfaces up at the same time completely pointless. Ok, I can work around it by disabling the wlan, but come on, not really the point of having both interfaces active, right? User expectation is that the fastest connection is used, which clearly isn't the case here. Version-Release number of selected component (if applicable): initscripts-9.37.1-1.fc17.x86_64 NetworkManager.x86_64 1:0.9.4.0-9.git20120521.fc17 How reproducible: always Additional Info: Found two related bugs: #193047 and #498472
PS. I already tried adding METRIC= to the respective config files, but it is ignored.
I consistenly have the situation that my wlan link is picked over the eth link. This is extremely annoying, especially when copying big files. Please please change the metric on wlan links to something higher than 0
The issue is not specific to METRICs obtained via the "ifcfg-rh" back-end to Network Manager. I thought maybe the METRIC directive was being dropped when passing data to NM, but the switching to the "keyfile" backend and defining the routes with a higher metric also does not work. While testing that theory (and a workaround of manually defining routes with higher metrics), I found that most of NM's route configuration doesn't seem to work (Fails to ignore automatic routes, fails to apply manual routes). I've filed those additional issues as bug #852793, though it is possible that these two bugs are related to a general problem with routing in Network Manager. Using F18.
This bug is still present in Fedora 19 Beta. Both wired and wireless interfaces obtain metric 0, which causes network dropouts when both interfaces are connected (i.e. a docked laptop) Even when manually configuring an address in Network Manager, there is no way to define a metric for the gateway/default route.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. 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 prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 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 to Fedora 17's end of life. 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.
Interestingly, this seems to be solved now. I'm not sure at what point this behaviour was resolved, but F19 final appears to be assigning different metrics to my two connections (and favouring the wired). I'm unsure how it calculates those metrics, but at this point I don't really care :) I'd recommend closing this bug. It doesn't appear I am capable of doing this.
(In reply to Chris Irwin from comment #6) > Interestingly, this seems to be solved now. I'm not sure at what point this > behaviour was resolved, but F19 final appears to be assigning different > metrics to my two connections (and favouring the wired). > > I'm unsure how it calculates those metrics, but at this point I don't really > care :) > > I'd recommend closing this bug. It doesn't appear I am capable of doing this. Whoops, I confused this with an issue I reported, and don't want to step on Ferry Huberts toes, who may still be affected by the issue.
(In reply to Chris Irwin from comment #6) > Interestingly, this seems to be solved now. I'm not sure at what point this > behaviour was resolved, but F19 final appears to be assigning different > metrics to my two connections (and favouring the wired). > > I'm unsure how it calculates those metrics, but at this point I don't really > care :) > > I'd recommend closing this bug. It doesn't appear I am capable of doing this. Ah, yes. I seem to have missed that when checking the routing table. My eth now has metric 1 and my wlan has metric 9. That solves it. Also the interface with the lowest metric seems to be chosen as the default gateway, which is good. thanks for fixing