NetworkManager mishandles multiple interfaces on same subnet
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Linux Mint |
New
|
Undecided
|
Unassigned | ||
| Debian |
New
|
Undecided
|
Unassigned | ||
| Fedora |
Won't Fix
|
Undecided
|
|||
| network-manager (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Bug Description
1) The version and edition of Linux Mint you are using (if you are not sure, open a terminal and run "mintwelcome").
Release: 1 (debian)
Edition: Debian 64-bit
2) What you did for the problem to happen, and how to reproduce it.
In NetworkManager, I configured both wired and wireless network interfaces to connect to the same network. I set both interfaces to "Off" in NetworkManager. I then turned on and connected the wireless interface. After the wireless interface was connected, I turned on and connected the wired interface.
3) What happened.
When only the wireless network was connected, both the local subnet route and default route went over the wireless connect, the only one available. Upon connection of the wired interface, NetworkManager properly prioritizes the wired interface for the default route, but left the wireless network prioritized for the local subnet route. Here is an example of the improper routing table, notice that the route for wlan0 appears above the route for eth0:
default via 192.168.77.254 dev eth0 proto static
192.168.77.0/24 dev wlan0 proto kernel scope link src 192.168.77.41
192.168.77.0/24 dev eth0 proto kernel scope link src 192.168.77.40
This is due to the order of the routes in the routing table that results from the order that the network connects were enabled. If the order of connection is reversed, so are the local subnet routes, correcting the issue.
4) What you expected to happen instead.
I expected the wired network to be prioritized for both the default route and local subnet route, producing a routing table something like this:
default via 192.168.77.254 dev eth0 proto static
192.168.77.0/24 dev wlan0 proto kernel scope link src 192.168.77.41 metric 1
192.168.77.0/24 dev eth0 proto kernel scope link src 192.168.77.40 metric 0
5) If the problem happened once, sometimes, or always.
This problem always happens. At some point in the past the network routes were handled properly, producing a routing table that looked like this:
default via 192.168.77.254 dev wlan0 proto static metric 1
default via 192.168.77.254 dev eth0 proto static metric 0
192.168.77.0/24 dev wlan0 proto kernel scope link src 192.168.77.41 metric 1
192.168.77.0/24 dev eth0 proto kernel scope link src 192.168.77.40 metric 0
6) Possible relevant reference.
I found a NetworkManager a couple of bugs about this issue that indicates this is a problem with libnl3. Here is the NetworkManager bug report:
https:/
https:/
The second NetworkManager bug (659984) references a libnl mailing list message indicating a fix to the issue. Here is that post:
http://
|
|
#2 |
|
|
#4 |
|
|
#7 |
|
|
#10 |
|
|
#11 |
|
|
#12 |
|
|
#13 |
| Launchpad Janitor (janitor) wrote | #1 |
| Changed in network-manager (Ubuntu): | |
| status: | New → Confirmed |
| affects: | ubuntu → network-manager (Ubuntu) |
| Changed in fedora: | |
| importance: | Unknown → Undecided |
| status: | Unknown → Won't Fix |
Description of problem:
If, while connected over wifi, ethernet connection is made, routing table is not properly updated
Version-Release number of selected component (if applicable):
How reproducible:
Every time
Steps to Reproduce:
1. Boot a laptop without ethernet, have it connected to a wifi network
2. Connect ethernet cable (same network)
3. Browse pages/check email/etc.
Actual results:
Wifi route is stuck as the default in the routing table, so network connection is not working right.
Expected results:
routing table should become exactly same as it would've been if laptop was booted up with wifi and ethernet enabled and plugged in, respectively.
Additional info:
Turning wifi off and then back on seems to work around the problem because the wifi interface gateway is removed when wifi is disabled. When re-added, wifi doesn't override ethernet gateway (correct behavior)