Bug 980274 - Thinkpad T430 wifi/wireless network speed decreases dramatically
Thinkpad T430 wifi/wireless network speed decreases dramatically
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
18
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-01 19:44 EDT by Daniel
Modified: 2014-02-05 17:02 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-05 17:02:04 EST
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)
dmsg - 130711 (69.44 KB, text/plain)
2013-07-11 23:33 EDT, Daniel
no flags Details
messages - 130711 (791.94 KB, text/plain)
2013-07-11 23:36 EDT, Daniel
no flags Details

  None (edit)
Description Daniel 2013-07-01 19:44:33 EDT
Description of problem:
Hi there, I'm using a Lenovo Thinkpad T430 with Fedora 18; when I have both the wireless and wired network connections 'On', web browsing speed slows down to the point that its almost unusuable (same with applications needing access to the network connection that I tried - ex. rhythmbox, etc).

How reproducible:
Has happened each time I've tried it, have also tried reinstalling OS.

Steps to Reproduce:
1. Enable wired network connection
2. Enable wireless network connection
3. Start firefox, try browsing sites

Actual results:
Seems when both network connections are active, the web browsing speed slows down signficantly (to the point that some things just time out).

Expected results:
Browsing at the same speed with both connections enabled.

Additional info:
When disabling (one of) either wireless or wired connection, everything goes back to working fine. Sorry if there is information missing, its my first bug report - please let me know if there is anything else I can provide.
Comment 1 Jirka Klimes 2013-07-11 07:58:08 EDT
It could be multiple reasons. One think that comes to my mind is your network configuration. Can you describe your setup?
I think there could be a problem if you are connected to a Wi-Fi router both via cable and Wi-Fi with the same computer.

Would you get some info and logs from your system, when both wired and wireless connections are active?

$ route -n
$ ip a
$ nmcli dev
* /var/log/messages log
* output of dmesg command
Comment 2 Daniel 2013-07-11 23:33:25 EDT
Created attachment 772530 [details]
dmsg - 130711

dmseg output
Comment 3 Daniel 2013-07-11 23:36:11 EDT
Created attachment 772531 [details]
messages - 130711

/var/log/messages output
Comment 4 Daniel 2013-07-11 23:39:36 EDT
(In reply to Jirka Klimes from comment #1)
> It could be multiple reasons. One think that comes to my mind is your
> network configuration. Can you describe your setup?
> I think there could be a problem if you are connected to a Wi-Fi router both
> via cable and Wi-Fi with the same computer.
> 
> Would you get some info and logs from your system, when both wired and
> wireless connections are active?
> 
> $ route -n
> $ ip a
> $ nmcli dev
> * /var/log/messages log
> * output of dmesg command

Hi there,

I do have a wireless router and have the laptop connected via wireless and wired connection; when I'm away from my desk I use the wifi but then put the laptop on a dock when I'm back.

The output from the commands are below (I have added the outputs as attachements):

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    0      0        0 em1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 em1

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:21:cc:ce:bc:8e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.105/24 brd 192.168.1.255 scope global em1
       valid_lft forever preferred_lft forever
    inet6 fe80::221:ccff:fece:bc8e/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether e0:06:e6:c5:a6:85 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.103/24 brd 192.168.1.255 scope global wlan0
       valid_lft forever preferred_lft forever
    inet6 fe80::e206:e6ff:fec5:a685/64 scope link 
       valid_lft forever preferred_lft forever

DEVICE     TYPE              STATE        
wlan0      802-11-wireless   connected    
em1        802-3-ethernet    connected
Comment 5 Fedora End Of Life 2013-12-21 09:12:49 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. 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 '18'.

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 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 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 18'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 zippi zippone 2013-12-27 09:20:51 EST
The problem here is that NetworkManager (again) adds every route with the same Metric!

Problem was solved in Fedora 19 and "unfixed" with the redesign of NM in Fedora 20.

So I have the same Problem here.
If you connect the cable the traffic is not rerouted to the wired NIC because of the same Metric.

[zippi@garm ~]$ route
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         192.168.15.254  0.0.0.0         UG    1024   0        0 eth0
192.168.15.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.15.0    0.0.0.0         255.255.255.0   U     0      0        0 wlan0

When you connect the wireless first the last 2 entries will swap and wireless will remain the "active" connection for all data the the network 192.168.15.0/24.
Comment 7 Fedora End Of Life 2014-02-05 17:02:04 EST
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 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.

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