GNOME Bugzilla – Bug 700695
NM lost connection each 2 minutes because of rescaning the network
Last modified: 2013-06-23 07:21:34 UTC
Hi guys, had to switch to wicd because of this bug. Small description: I am using an usb wi-fi adapter. Previously it was tp-link which worked well with no issues. But it was pretty slow, I wasn't able to translate HD video with it so switched to Linksys AE3000. It brings a new unsupported chip, so had to build the driver first: https://aur.archlinux.org/packages/rt3593/ The problem: After all that the blue led started blinking, but I noticed that each few minutes (or so) my internet connection goes down (not like completely disconnected, but ping time grows up to a few seconds). This affects audio streams, torrents, etc and makes the work in internet not comfortable in general. After some investigation I found that this happens each time NM performs scanning. In /var/log/everything.log I seen: ===>rt_ioctl_giwscan. 3(3) BSS returned, data->length = 706 and errors like these: ===>rt_ioctl_giwscan. 4(4) BSS returned, data->length = 852 fe3, flush one! ===>rt_ioctl_giwscan. 3(3) BSS returned, data->length = 706 ffc, flush one! ===>rt_ioctl_giwscan. 3(3) BSS returned, data->length = 706 Indicate_Legacy_Packet():flush reordering_timeout_mpdus! RxWI->Flags=128, pRxWI.TID=0, RxD->AMPDU=0! 1e, flush one! ===>rt_ioctl_giwscan. 3(3) BSS returned, data->length = 706 2e, flush one! DeQueueRunning[0]= TRUE! Ping looks like this: 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=10 ttl=54 time=95.6 ms 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=11 ttl=54 time=96.2 ms 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=12 ttl=54 time=1538 ms 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=13 ttl=54 time=529 ms 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=14 ttl=54 time=1426 ms 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=15 ttl=54 time=417 ms 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=16 ttl=54 time=3010 ms 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=17 ttl=54 time=2001 ms 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=18 ttl=54 time=1001 ms 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=19 ttl=54 time=95.4 ms 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=20 ttl=54 time=544 ms 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=21 ttl=54 time=95.6 ms ... 2 minutes later ... 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=26 ttl=54 time=96.7 ms 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=27 ttl=54 time=96.2 ms 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=28 ttl=54 time=4961 ms 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=29 ttl=54 time=3961 ms 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=30 ttl=54 time=2960 ms 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=31 ttl=54 time=1965 ms 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=32 ttl=54 time=1057 ms 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=33 ttl=54 time=95.7 ms 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=34 ttl=54 time=2529 ms 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=35 ttl=54 time=1529 ms 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=36 ttl=54 time=529 ms 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=37 ttl=54 time=96.3 ms 64 bytes from linux.org.ru (217.76.32.61): icmp_seq=38 ttl=54 time=95.5 ms I can reproduce this with wicd as well. The only difference is that wicd does not do a re-scan each 2 minutes after connection has established. But performs it each time I open the widget (this one: http://kde-apps.org/content/show.php/?content=132366 ). So it only re-scans when user wants to browse available networks. In general I understand that this is a bug in chip driver and it shouldn't disconnect during scanning (probably). But is this possible to make this configurable in NM? I mean to be able to set the pooling interval or disable it at all after connected? P.S. Severity is set to major because it is not possible to use NM with mentioned Linksys adapters with current poling settings (unless your nerves are of steel :)). Best, Alex
You can turn off periodic scanning by locking your connection to the BSSID of the access point you'd like to talk to. If you do this, then the whole reason for scanning (ie, finding an AP to roam to) is irrelevant, and so scanning is not performed. You can find this option in nm-connection-editor under the Wireless tab, in the "BSSID" entry. Locking the BSSID does not affect manual scans done via the D-Bus API, which can be requested by apps at any time.
And, obviously, the kernel driver needs to be fixed :) Low quality drivers are always a source of wifi bugs... If the BSSID lock thing doesn't help, please reopen and we can diagnose further. Thanks!
Hi Dan, thank you for the response. Yes, the driver is of bad quality, but I lost any hope something will be fixed in it. There are no any updates for a long time: http://www.mediatek.com/_en/07_downloads/01_windows.php?sn=501 What a reason to continue the network scanning if connection has been established? It could be refreshed only when it is required by other applications, e.g. by NM widget, when user open it to check available networks, etc. Will try the trick with BSSID later on today and come back with a response. Thank you, Alex
The BSSID trick works for me, thank you. But I am not sure if it is too obvious for other users. I personally spent lots of time to figure out this problem. Best, Alex