Bug 852793 - ethernet and wlan interfaces must use different metrics
ethernet and wlan interfaces must use different metrics
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
19
All Linux
unspecified Severity high
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-29 11:42 EDT by Ferry Huberts
Modified: 2013-07-04 02:51 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-04 02:51:42 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ferry Huberts 2012-08-29 11:42:11 EDT
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
Comment 1 Ferry Huberts 2012-08-29 11:49:10 EDT
PS. I already tried adding METRIC= to the respective config files, but it is ignored.
Comment 2 Ferry Huberts 2012-12-14 09:25:29 EST
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
Comment 3 Chris Irwin 2013-04-03 22:09:57 EDT
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.
Comment 4 Chris Irwin 2013-05-30 19:26:18 EDT
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.
Comment 5 Fedora End Of Life 2013-07-03 18:01:54 EDT
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.
Comment 6 Chris Irwin 2013-07-04 01:21:49 EDT
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.
Comment 7 Chris Irwin 2013-07-04 01:23:26 EDT
(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.
Comment 8 Ferry Huberts 2013-07-04 02:51:42 EDT
(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

Note You need to log in before you can comment on or make changes to this bug.