Hi,
I have a super annoying problem that is not Fedora specific, but it's been driving me nuts for a few weeks. Any idea for a more appropriate forum to post this in is as useful as an idea what's going on or next steps.
Linksys WRT600N using dd-wrt in client mode, with laptop and Intel NUC connected via wired. Both laptop and NUC would get fast.com and speedtest.net download speeds of ~16Mbps for about 30 minutes then tank to maybe 150kbps after that until the Linksys radio was disabled then renabled, or just rebooted. The same thing happens when flashed with openwrt except it only takes 5 minutes to manifest.
I assumed it was a bad radio on the WRT600N or maybe it's some hardware incompatibility with the local APs. I went down the road of multihoming (in previous emails I was sorting out how to get wireless routed by default for internet and wired for local stuff.)
Well get this. The Apple laptop wireless always gets 16Mbps, it never tanks. The Intel NUC does the same thing as the WRT600N. It gets 16Mbps for 5-10 minutes, then implodes until I do a 'nmcli c down' followed by 'nmcli c up' sort of thing, and then it gets good bandwidth.
So WTF?
I just noticed this odd duck behavior:
# sudo journalctl -b | grep AssocResp
laptop fedora 24 (same results with fedora 23) https://paste.fedoraproject.org/378329/
intel NUC https://paste.fedoraproject.org/378331/
The Apple laptop wireless is bouncing between two APs exactly two minutes apart all the time. This is constant over weeks. But the Intel NUC doesn't do that, it pretty much sticks with one AP for hours at a time. All three devices are within 2 meters of each other. I have no idea where these APs are.
Whatever is causing the Apple wifi card to go back and forth between two APs is somehow acting like a disconnect/reconnect "fix" that I've been doing manually with the WRT600N and NUC, which uses an Intel 3165 wireless card. Where the other two persist in holding on to an AP where the performance has face planted.
My Motorola Android phone also doesn't have the problem.
Maybe this is enough information to forward to the IT folks who manage this wifi setup? Is there anything else I should provide? Or some way of making this write up more concise?
iwlist gets me this
Cell 01 - Address: B4:C7:99:ED:F8:A8 Channel:11 Frequency:2.462 GHz (Channel 11) Quality=46/70 Signal level=-64 dBm
Cell 02 - Address: B4:C7:99:EE:25:08 Channel:1 Frequency:2.412 GHz (Channel 1) Quality=60/70 Signal level=-50 dBm
Cell 08 - Address: B4:C7:99:ED:F0:C8 Channel:1 Frequency:2.412 GHz (Channel 1) Quality=30/70 Signal level=-80 dBm
I have no idea why anything would pick cell 08 with that kind of signal, but bloop there it is.
I don't think this is an 802.11g vs n issue. The WRT600N does n on dd-wrt, but only bg on openwrt. The Apple wireless is not using proprietary driver, so 802.11n isn't supported, only bg. The Intel NUC supports n as well as many others.
Thanks,
On Sun, 12 Jun 2016, Chris Murphy wrote:
Hi,
I have a super annoying problem that is not Fedora specific, but it's been driving me nuts for a few weeks. Any idea for a more appropriate forum to post this in is as useful as an idea what's going on or next steps.
[snip]
I think this is a problem that comes up with Linksys routers in general, not just the WRT600N. It used to happen to me with an older Linksys device, and I went through the "try changing the MTU, try changing the firmware, try resetting to factory..." etc.
All that stuff. Sometimes it would work for awhile, and sometimes it wouldn't. If you go to the Linksys forums, it always seems to boil down to bad firmware -- whether ma nufacturere or dd-wrt for any number of models of products from this brand.
The only thing I ever found that seemed to work for one person (it didn't work for me), was to shield cables or move the router away from the cable modem. The claim was that it was electrical noise:
http://www.speedguide.net/articles/router-speed-drop-solved-1885
Other explanations I have seen include:
1) You are dropping a lot of packets because of noise and the router automatically drops down to lower bandwidth when that happens (my old DSL router did this all the time back in the day because I had a noisy phone line)
2) You are in an area where there is congestion on a particular channel (e.g. you live in an apartment and all your neighbors are simultaneously downloading porn and playing World of Warcraft 24 hours a day)
And, I have to admit, when I looked at my router, it did follow a pattern of dropping increasing numbers of packets before it crumped.
But mostly it was just Linksys/Cisco consumer product issues.
See:
http://www.dd-wrt.com/phpBB2/viewtopic.php?p=419398&sid=26a65103ddffd19c... http://community.linksys.com/t5/Wireless-Routers/Linksys-WRT600N-Losing-Down...
other models:
https://community.linksys.com/t5/Wireless-Routers/WRT1900AC-dropping-2-4ghz-... https://community.linksys.com/t5/Wireless-Routers/WRT-1900-AC-Wi-Fi-Speed-Dr...
billo
On Mon, Jun 13, 2016 at 5:15 AM, vendor@billoblog.com wrote:
On Sun, 12 Jun 2016, Chris Murphy wrote:
Hi,
I have a super annoying problem that is not Fedora specific, but it's been driving me nuts for a few weeks. Any idea for a more appropriate forum to post this in is as useful as an idea what's going on or next steps.
[snip]
I think this is a problem that comes up with Linksys routers in general, not just the WRT600N. It used to happen to me with an older Linksys device, and I went through the "try changing the MTU, try changing the firmware, try resetting to factory..." etc.
All that stuff. Sometimes it would work for awhile, and sometimes it wouldn't. If you go to the Linksys forums, it always seems to boil down to bad firmware -- whether ma nufacturere or dd-wrt for any number of models of products from this brand.
The only thing I ever found that seemed to work for one person (it didn't work for me), was to shield cables or move the router away from the cable modem. The claim was that it was electrical noise:
http://www.speedguide.net/articles/router-speed-drop-solved-1885
Other explanations I have seen include:
- You are dropping a lot of packets because of noise and the router
automatically drops down to lower bandwidth when that happens (my old DSL router did this all the time back in the day because I had a noisy phone line)
- You are in an area where there is congestion on a particular channel
(e.g. you live in an apartment and all your neighbors are simultaneously downloading porn and playing World of Warcraft 24 hours a day)
And, I have to admit, when I looked at my router, it did follow a pattern of dropping increasing numbers of packets before it crumped.
But mostly it was just Linksys/Cisco consumer product issues.
See:
http://www.dd-wrt.com/phpBB2/viewtopic.php?p=419398&sid=26a65103ddffd19c... http://community.linksys.com/t5/Wireless-Routers/Linksys-WRT600N-Losing-Down...
other models:
https://community.linksys.com/t5/Wireless-Routers/WRT1900AC-dropping-2-4ghz-... https://community.linksys.com/t5/Wireless-Routers/WRT-1900-AC-Wi-Fi-Speed-Dr...
Like I mentioned though, this happens with Intel NUC wireless directly connecting to the AP. The WRT600N isn't involved at all.
On 06/13/2016 11:40 AM, Chris Murphy wrote:
On Mon, Jun 13, 2016 at 5:15 AM, vendor@billoblog.com wrote:
On Sun, 12 Jun 2016, Chris Murphy wrote:
Hi,
I have a super annoying problem that is not Fedora specific, but it's been driving me nuts for a few weeks. Any idea for a more appropriate forum to post this in is as useful as an idea what's going on or next steps.
[snip]
I think this is a problem that comes up with Linksys routers in general, not just the WRT600N. It used to happen to me with an older Linksys device, and I went through the "try changing the MTU, try changing the firmware, try resetting to factory..." etc.
All that stuff. Sometimes it would work for awhile, and sometimes it wouldn't. If you go to the Linksys forums, it always seems to boil down to bad firmware -- whether ma nufacturere or dd-wrt for any number of models of products from this brand.
The only thing I ever found that seemed to work for one person (it didn't work for me), was to shield cables or move the router away from the cable modem. The claim was that it was electrical noise:
http://www.speedguide.net/articles/router-speed-drop-solved-1885
Other explanations I have seen include:
- You are dropping a lot of packets because of noise and the router
automatically drops down to lower bandwidth when that happens (my old DSL router did this all the time back in the day because I had a noisy phone line)
- You are in an area where there is congestion on a particular channel
(e.g. you live in an apartment and all your neighbors are simultaneously downloading porn and playing World of Warcraft 24 hours a day)
And, I have to admit, when I looked at my router, it did follow a pattern of dropping increasing numbers of packets before it crumped.
But mostly it was just Linksys/Cisco consumer product issues.
See:
http://www.dd-wrt.com/phpBB2/viewtopic.php?p=419398&sid=26a65103ddffd19c... http://community.linksys.com/t5/Wireless-Routers/Linksys-WRT600N-Losing-Down...
other models:
https://community.linksys.com/t5/Wireless-Routers/WRT1900AC-dropping-2-4ghz-... https://community.linksys.com/t5/Wireless-Routers/WRT-1900-AC-Wi-Fi-Speed-Dr...
Like I mentioned though, this happens with Intel NUC wireless directly connecting to the AP. The WRT600N isn't involved at all.
Just for giggles, try doing:
# echo '0' >/proc/sys/net/ipv4/tcp_sack
and see if that helps. We need to use that when using SSH over several of our VPNs and firewalls.
If it helps, you can add an /etc/sysctl.d/10-disablesack.conf file containing:
net.ipv4.tcp_sack = 0
to have it "stick" on the next reboot.
Just an idea. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - The problem with being poor is that it takes up all of your time - ----------------------------------------------------------------------
On Mon, Jun 13, 2016 at 12:53 PM, Rick Stevens ricks@alldigital.com wrote:
echo '0' >/proc/sys/net/ipv4/tcp_sack
No change.
Intel NUC is getting 98kbps downloads of the exact same file from the same AP as the Mac, but the Mac is at 1200kbps. And today, even an 'nmcli c down' and 'nmcli c up' cycle does not improve the NUC.
Wonky.
On Tue, 14 Jun 2016, Chris Murphy wrote:
On Mon, Jun 13, 2016 at 12:53 PM, Rick Stevens ricks@alldigital.com wrote: echo '0' >/proc/sys/net/ipv4/tcp_sack
No change.
Intel NUC is getting 98kbps downloads of the exact same file from the same AP as the Mac, but the Mac is at 1200kbps. And today, even an 'nmcli c down' and 'nmcli c up' cycle does not improve the NUC.
Wonky.
-- Chris Murphy
... and I bet there's a huge rise in dropped packets before it happens, right? I'm tellin' ya, it's gotta be the driver/firmware and there's nothing you can do except get a different box or wait until the next revision of the driver/firmware and hope it works. If you've tweaked the MTU, moved things to avoid interference, changed channels, and hopped around between g and n, that's all you can do as a sysadmin/user.
billo
On Wed, Jun 15, 2016 at 4:34 AM, vendor@billoblog.com wrote:
... and I bet there's a huge rise in dropped packets before it happens, right?
How can I tell? I tried this but it suggests no dropped packets.
# ip -s -d a
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 34:02:86:cc:d8:69 brd ff:ff:ff:ff:ff:ff promiscuity 0 inet 172.19.11.32/24 brd 172.19.11.255 scope global dynamic wlp2s0 valid_lft 15235sec preferred_lft 15235sec inet6 fe80::3602:86ff:fecc:d869/64 scope link valid_lft forever preferred_lft forever RX: bytes packets errors dropped overrun mcast 198972107 245657 0 0 0 0 TX: bytes packets errors dropped carrier collsns 8006062 90794 0 0 0 0
I'm tellin' ya, it's gotta be the driver/firmware and there's nothing you can do except get a different box or wait until the next revision of the driver/firmware and hope it works. If you've tweaked the MTU, moved things to avoid interference, changed channels, and hopped around between g and n, that's all you can do as a sysadmin/user.
I think it's a local configuration problem. I was in this same environment a year ago and this worked with the same hardware (well, it was a different building so different physical APs but the people managing it are the same).
On Wed, Jun 15, 2016 at 6:25 PM, Chris Murphy lists@colorremedies.com wrote:
On Wed, Jun 15, 2016 at 4:34 AM, vendor@billoblog.com wrote:
... and I bet there's a huge rise in dropped packets before it happens, right?
How can I tell? I tried this but it suggests no dropped packets.
# ip -s -d a
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 34:02:86:cc:d8:69 brd ff:ff:ff:ff:ff:ff promiscuity 0 inet 172.19.11.32/24 brd 172.19.11.255 scope global dynamic wlp2s0 valid_lft 15235sec preferred_lft 15235sec inet6 fe80::3602:86ff:fecc:d869/64 scope link valid_lft forever preferred_lft forever RX: bytes packets errors dropped overrun mcast 198972107 245657 0 0 0 0 TX: bytes packets errors dropped carrier collsns 8006062 90794 0 0 0 0
I'm tellin' ya, it's gotta be the driver/firmware and there's nothing you can do except get a different box or wait until the next revision of the driver/firmware and hope it works. If you've tweaked the MTU, moved things to avoid interference, changed channels, and hopped
around
between g and n, that's all you can do as a sysadmin/user.
I think it's a local configuration problem. I was in this same environment a year ago and this worked with the same hardware (well, it was a different building so different physical APs but the people managing it are the same).
A lot can change over a year what with updates to router software and policy changes. The sad thing is that the effort needed to sort out problems like this is measured in days -- more time than many of us can spare -- and some potentially useful information will be on the routers and is often inaccessible to the people who could use it.
-- Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://lists.fedoraproject.org/admin/lists/users@lists.fedoraproject.org Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On Wed, 15 Jun 2016, Chris Murphy wrote:
On Wed, Jun 15, 2016 at 4:34 AM, vendor@billoblog.com wrote:
... and I bet there's a huge rise in dropped packets before it happens, right?
How can I tell? I tried this but it suggests no dropped packets.
# ip -s -d a
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 34:02:86:cc:d8:69 brd ff:ff:ff:ff:ff:ff promiscuity 0 inet 172.19.11.32/24 brd 172.19.11.255 scope global dynamic wlp2s0 valid_lft 15235sec preferred_lft 15235sec inet6 fe80::3602:86ff:fecc:d869/64 scope link valid_lft forever preferred_lft forever RX: bytes packets errors dropped overrun mcast 198972107 245657 0 0 0 0 TX: bytes packets errors dropped carrier collsns 8006062 90794 0 0 0 0
I'm tellin' ya, it's gotta be the driver/firmware and there's nothing you can do except get a different box or wait until the next revision of the driver/firmware and hope it works. If you've tweaked the MTU, moved things to avoid interference, changed channels, and hopped around between g and n, that's all you can do as a sysadmin/user.
I think it's a local configuration problem. I was in this same environment a year ago and this worked with the same hardware (well, it was a different building so different physical APs but the people managing it are the same).
Yow. I wasn't expecting that.
Well, this weekend, I'll plug in a little Chinese usb wifi adapter that exhibited the same kind of behavior you described, at least when I played with it with Fedora 22. I have four cheap usb adapters, all of which are *supposed* to have the same chips. Yayy ebay. Two of them do the same sort of thing you write about -- run fine for 20-30 mins and then crump. One of them only does it when it's talking to a Cisco router. Two of them work great.
I'll see what wireshark has to say. Maybe what I find on my toys might help.
billo
-
Chris Murphy -
George N. White III -
Rick Stevens -
William Oliver