Network Manager doesn't use route metrics to prioritise certain connections such as ethernet over other connections such as wifi. All connections use metric 0 for the default route which means sometimes low bandwidth connections can take priority over high bandwidth connections. Ubuntu applies a metric value even to ethernet connections. Reproducible: Always
This is a fairly significant feature request which would have to be implemented not by gentoo, but by networkmanager developers so that all distros can benefit from it. Please ask them directly at https://bugzilla.gnome.org/enter_bug.cgi?product=NetworkManager and explain what sort of behavior you would like to see (do you want a GUI for setting the route metric for a connection? or do you always want to give wireless a higher metric? under what conditions, with what exceptions?) and a specific use case where it would make a difference (e.g.: you have a machine connected to wifi, you plug in an ethernet cable, networkmanager creates an ethernet connection, but your traffic keeps going over wifi and not ethernet, leading to measurably worse performance: here are the logs showing that). Then please add a comment here with the URL for the bugzilla.gnome.org bug you opened.
I was thinking this: http://ubuntuforums.org/showthread.php?t=1499325 would be a good start, although I just checked the Debian and Fedora live cds and they don't appear to have this either, so I'll see if I can get the patch that Ubuntu uses.
Actually it looks like Debian 6.0.3 uses different metrics as well, but only when both lan and wireless are connected. My first test was on a virtual machine with a single network interface.
Fedora Live DVD doesn't appear to use different metrics when both lan and wireless are connected.
(In reply to comment #4) > Fedora Live DVD doesn't appear to use different metrics when both lan and > wireless are connected. Afaik this is a bug. This sort of bug reports and/or feature requests is more suitable for the NM upstream bugzilla.
*** Bug 471220 has been marked as a duplicate of this bug. ***
I cannot reproduce this with >=0.9.6.4, upstream points to a problem with drivers instead. I think you should reply there (the bug is tagged as NEEDINFO now)
