Hide Forgot
Description of problem: On a Lenovo T420s laptop, my system is unable to communicate over the network when I initially connect to a network via wifi, and then dock my system which connects the wired ethernet port. I see that NetworkManager brings up the interface, and then network traffic almost completely fails to pass, but it seems like some packets do make it through intermittently (5-10 packets every 60 seconds or so). If I disable the wireless interface, eventually (~30 seconds later?) I can again access external network resources. This worked fine on F19 and prior. Version-Release number of selected component (if applicable): NetworkManager-0.9.9.0-18.git20131003.fc20.x86_64 How reproducible: Every time Steps to Reproduce: 1. With system undocked, connect to wifi network. 2. Start pinging a host outside of the local network. 3. Dock system to a dock which is connected to a wired ethernet network. Actual results: Pings to remote host fail to get through. If I disable the wifi interface via the NetworkManager applet, eventually my network access comes back. Expected results: Network works as expected through and after the docking process. Additional info:
Here's the behavior I expect: I'd like to see an "interface priority" system, that would allow me to say: "When both Wifi and Ethernet are connected, favor Ethernet." I'd like to achieve this by assigning weights to interfaces (both via nmcli AND the gui!) This would allow me to more easily dock and undock my laptop, even if I have to withstand network disconnection because of failing over from one connection to another.
Still occurring on a 2014 Lenovo Carbon X1. Is there any interest in finding a solution to this issue?
I'm seeing this too with my Lenovo X230 but I think it may actually be #1080709
Could you provide the output of 'route -n' when the problem occurs? Are the wired network and the wifi on the same logical network segment, and do they both receive an IP address in the same subnet? Also, could you confirm that the MAC address of your wired interface is different than the MAC address of your wifi one? 'ip link' will tell you that. (I only ask because some laptop BIOS plays tricks with this and tries to make them the same for "seamless" roaming, but of course that screws some things up too)
Hi Dan, thanks for taking a look! Wired and wifi are on the same logical segment, and they have IP addresses on the same subnet. This is a simple home network, a Verizon Fios router is serving DHCP. I understand the challenge of having multiple interfaces on the same subnet, but I do think that we could make some assumptions based on likely use cases and try to provide functionality around those. I think being able to either weight interfaces through NetworkManager to provide routing priority for one interface over another might give me the functionality I need to make this work. Perhaps being able to prioritize interface with an existing configuration over a newcomer might make this particular experience more seamless. One interesting point - the dock is a Lenovo OneLink Prodock. It appears as though when docking, the dock presents a new (usb) ethernet interface as eth0. When undocked, I see enp0s25 (ethernet) and wlp3s0 (wifi). When docked, eth0 pops up in addition. However, I saw this same behavior on the old-style Lenovo docks, which just provided an electrical passthrough from3 the on-laptop ethernet chipset. Before docking: $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 1024 0 0 wlp3s0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlp3s0 After docking: $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 1024 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlp3s0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 What I'm seeing from a user perspective is a lack of connectivity (in this instance, pinging google.com) after the laptop is docked (and the new interface comes up). From a lower-level perspective, I see pings initially get through but start failing after 12 or so seconds. They fail for 32 seconds, give or take, then get through for 8 or so seconds. The process then repeats. During this entire time, I am unable to navigate to web sites via Firefox. Here's the behavior I'm seeing via a simple ping: (i've snipped repetitive lines for brevity, full session here: http://fpaste.org/179282/42271615/) $ ping -O google.com PING google.com (74.125.226.8) 56(84) bytes of data. 64 bytes from lga15s42-in-f8.1e100.net (74.125.226.8): icmp_seq=1 ttl=250 time=77.8 ms 64 bytes from lga15s42-in-f8.1e100.net (74.125.226.8): icmp_seq=2 ttl=250 time=76.0 ms [snip] 64 bytes from lga15s42-in-f8.1e100.net (74.125.226.8): icmp_seq=7 ttl=250 time=92.5 ms [dock laptop here] 64 bytes from lga15s42-in-f8.1e100.net (74.125.226.8): icmp_seq=8 ttl=250 time=85.3 ms 64 bytes from lga15s42-in-f8.1e100.net (74.125.226.8): icmp_seq=9 ttl=250 time=90.0 ms 64 bytes from lga15s42-in-f8.1e100.net (74.125.226.8): icmp_seq=10 ttl=250 time=80.1 ms [snip] 64 bytes from lga15s42-in-f8.1e100.net (74.125.226.8): icmp_seq=22 ttl=250 time=72.4 ms 64 bytes from lga15s42-in-f8.1e100.net (74.125.226.8): icmp_seq=23 ttl=250 time=62.2 ms no answer yet for icmp_seq=24 no answer yet for icmp_seq=25 no answer yet for icmp_seq=26 [snip] no answer yet for icmp_seq=55 no answer yet for icmp_seq=56 64 bytes from lga15s42-in-f8.1e100.net (74.125.226.8): icmp_seq=57 ttl=250 time=60.7 ms 64 bytes from lga15s42-in-f8.1e100.net (74.125.226.8): icmp_seq=58 ttl=250 time=52.1 ms [snip] 64 bytes from lga15s42-in-f8.1e100.net (74.125.226.8): icmp_seq=63 ttl=250 time=54.5 ms 64 bytes from lga15s42-in-f8.1e100.net (74.125.226.8): icmp_seq=64 ttl=250 time=55.8 ms no answer yet for icmp_seq=65 no answer yet for icmp_seq=66 [snip] no answer yet for icmp_seq=110 no answer yet for icmp_seq=111 64 bytes from lga15s42-in-f8.1e100.net (74.125.226.8): icmp_seq=112 ttl=250 time=30.8 ms 64 bytes from lga15s42-in-f8.1e100.net (74.125.226.8): icmp_seq=113 ttl=250 time=39.9 ms 64 bytes from lga15s42-in-f8.1e100.net (74.125.226.8): icmp_seq=114 ttl=250 time=51.2 ms 64 bytes from lga15s42-in-f8.1e100.net (74.125.226.8): icmp_seq=115 ttl=250 time=38.8 ms 64 bytes from lga15s42-in-f8.1e100.net (74.125.226.8): icmp_seq=116 ttl=250 time=57.6 ms 64 bytes from lga15s42-in-f8.1e100.net (74.125.226.8): icmp_seq=117 ttl=250 time=50.9 ms 64 bytes from lga15s42-in-f8.1e100.net (74.125.226.8): icmp_seq=118 ttl=250 time=46.1 ms 64 bytes from lga15s42-in-f8.1e100.net (74.125.226.8): icmp_seq=119 ttl=250 time=39.9 ms no answer yet for icmp_seq=120 no answer yet for icmp_seq=121 no answer yet for icmp_seq=122 ... and the cycle repeats from there.
Quick revision, if I hit a web site during the periods of successful pings, I can get some traffic through, but everything drops on the floor once the pings stop going through. I also just tested with ping, not docked, but using the onboard (enp0s25, e1000e) ethernet chipset, and saw the same behavior, with identical results to the docked test in the routing table. I see no changes to the routing table after the initial change when the new interface is configured, even during the periods where pings are passing through OK.
(In reply to Dan Williams from comment #4) > Also, could you confirm that the MAC address of your wired interface is > different than the MAC address of your wifi one? 'ip link' will tell you > that. (I only ask because some laptop BIOS plays tricks with this and tries > to make them the same for "seamless" roaming, but of course that screws some > things up too) I missed answering this question - yes, the MACs are different for all the ethernet interfaces involved.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. 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 EOL if it remains open with a Fedora 'version' of '21'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 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 this bug is closed as described in the policy above. 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.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.