KNetworkManager Does Not Fail Over To Active Ethernet Controller

Asked by cmnorton

Binary package hint: knetworkmanager

I am using a USB Port Replicator for my Thinkpad T61p's ethernet and PS/2 connections. Upon startup KNetworkManager will not fail over from usb0 to eth1. It did fail over in 7.10.

This is not an earth-shattering problem; it is only annoying. I just simply issue a sudo dhclient or select eth1 in KNetworkManager by right-mouse-clicking on the KNetworkManager icon. Then, I have my network back.

If there is a configuration workaround, I would gladly test it for you. I am posting some information from ifconfig. If you want anything else, please let me know.

Thanks.
cmn

eth0 Link encap:Ethernet HWaddr 00:1e:37:8a:92:a7
          UP BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
          Base address:0x1840 Memory:fe200000-fe220000

eth1 Link encap:Ethernet HWaddr 00:50:b6:01:7c:c8
          inet addr:10.100.100.64 Bcast:10.100.255.255 Mask:255.255.0.0
          inet6 addr: fe80::250:b6ff:fe01:7cc8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:208 errors:0 dropped:0 overruns:0 frame:0
          TX packets:82 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:27040 (26.4 KB) TX bytes:15362 (15.0 KB)

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:16436 Metric:1
          RX packets:16 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:800 (800.0 B) TX bytes:800 (800.0 B)

usb0 Link encap:Ethernet HWaddr c6:ca:7e:71:7c:9d
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:90 (90.0 B)

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu knetworkmanager Edit question
Assignee:
No assignee Edit question
Solved by:
cmnorton
Solved:
Last query:
Last reply:
Revision history for this message
cmnorton (octopusgrabbus) said :
#1

I have confirmed this behavior does not happen with KNetworkManager in 7.10.

Revision history for this message
cmnorton (octopusgrabbus) said :
#2

I want to add some more information to this bug. This problem occurs where multiple interfaces present themselves to KNetworkManager. Specifically, working correctly now on KUbuntu 7.10 is a StarTech USB 2.0 docking station, through which I am getting my eth1 connection.

On 8.04, KDesktopManager appears to get stuck on the usb0 interface and never fails over to eth1.

Revision history for this message
cmnorton (octopusgrabbus) said :
#3

Similar behavior is also present in 7.10. I have two 7.10 laptops. One is running Kubuntu; the other is running Ubuntu. The Ubuntu laptop is using a Cardbus wireless card; the Kubuntu laptop is using a builtin wireless card. The Ubuntu system connects automatically; the KUbuntu system has to be manually connected, but it succeeds. If this is a configuration issue, I would love to know what it is. I have looked everywhere to see how to set one interface as primary.

Revision history for this message
cmnorton (octopusgrabbus) said :
#4

I no longer think this is a bug, but is more KNetworkManager's decision making as it might have changed from 7.10 to 8.04. Once I took the port replicator out of the mix, I get dhcp perfectly. The behavior was different in 7.10. I got dhcp automatically though the port replicator without its being stuck on usb0, which was not an active port.

I no longer believe this is a bug.
cmn

Revision history for this message
cmnorton (octopusgrabbus) said :
#5

I no longer consider this a bug or a question.