After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 620218 - NetworkManager interferes with ar9170usb supported wireless devices
NetworkManager interferes with ar9170usb supported wireless devices
Status: RESOLVED NOTGNOME
Product: NetworkManager
Classification: Platform
Component: general
0.8.x
Other Linux
: Normal normal
: ---
Assigned To: Dan Williams
Dan Williams
Depends on:
Blocks:
 
 
Reported: 2010-06-01 05:55 UTC by Pata Jaga
Modified: 2016-03-11 17:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Excerpt from syslog (3.38 KB, text/plain)
2010-06-01 07:20 UTC, Pata Jaga
Details

Description Pata Jaga 2010-06-01 05:55:50 UTC
There seems to be some sort of interference between NetworkManager and wireless devices using the ar9170usb module (like e.g. TP-Link TL-WN821N). When associated with an AP, the device intermittently (and after a random period of time) drops the connection and is not accessible afterwards until it is unplugged and replugged again, i.e. it produces no scan results with iwlist and won't reassociate. After replugging, everything works as expected (until the next connection drop, that is). Restarting networking or network-manager services has no effect.

According to https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/549140, this seems closely related to NetworkManager. I can confirm that with NM uninstalled and wireless connection configured manually (wpa_supplicant), the connection is actually stable.

I'd really like to assist sorting this issue out, as the situation is quite a bit annoying - if there is any additional information I could provide (such as logs etc), please don't hesitate to ask. I will be frequently monitoring this report in order to help finding a proper solution.
Comment 1 Dan Williams 2010-06-01 07:05:30 UTC
Since restarting NM does not have any effect, and unplugging does, this points directly to a driver problem.  There is no reason why the device should not work with NetworkManager (most other devices that are supported by the upstream kernel do), but NM does demand more from the device than just wpa_supplicant does by itself.  This could be due to periodic scanning, but note that if the device does have problems with periodic scanning, this is 100% a driver problem as the device needs to be able to cope with that.

One way to test is to set up the connection with wpa_supplicant, and then every 30 seconds or so, run this sequence of commands:

iwlist wlan0 scan
iwconfig wlan0

over and over.  Does that bork the device in the same way?  If so, there's clearly a driver bug that needs to be fixed upstream.
Comment 2 Pata Jaga 2010-06-01 07:20:22 UTC
Created attachment 162433 [details]
Excerpt from syslog
Comment 3 Pata Jaga 2010-06-01 07:22:47 UTC
Dan, thank you for your explanations. As this is a production system (home office), I'll later try configuring the wireless connection with wpa_supplicant and running the commands you mentioned, to see whether that produces a similar issue. Meanwhile, I have attached a syslog excerpt that possibly shows some messages from the time when the connection was failing this morning.
Comment 4 Pata Jaga 2010-06-09 18:51:17 UTC
Ok, this is definitely not related to NetworkManager. A manually configured connection (wpa_supplicant) also dies intermittently and shows no more scan results. Sorry for the confusion; I guess this bug can be closed then.
Comment 5 Pata Jaga 2010-06-11 07:47:50 UTC
Just another small suggestion: would it be possible to equip NetworkManager with a gconf setting to enable / disable regular scans for nearby wireless networks while associated to an AP? This could provide a workaround for devices suffering from problems like the one I mentioned in this report; also, I've read about other issues being introduced with regular scans: this seems to have a negative impact on bandwidth with some devices / drivers.. Well, as I wrote, just a suggestion. This wouldn't even require UI, but could help experienced users avoiding possible problems.
Comment 6 Dan Williams 2010-06-26 16:48:55 UTC
For scanning behavior changes see https://bugzilla.gnome.org/show_bug.cgi?id=513820.  It's desirable to enable scanning in many situations, but in some situations it's not.  While I'd rather not hack around driver bugs (I'd obviously prefer the drivers get fixed) there are obviously cases where even actively developed open-source kernel drivers have bugs.  A nice side-effect of 513820 is that you could disable the periodic scanning for your device as well.
Comment 7 Pata Jaga 2010-06-27 06:51:18 UTC
Yes, I've already noticed that report; sounds reasonable and would provide a solution for the disconnect problem. Of course I totally agree with you that a driver fix is actually the more preferable solution.. :) Well, thank you for your patience.