wpa_supplicant dropouts with Ralink 2870 USB wireless dongle
Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
wpa_supplicant dropouts with Ralink 2870 USB wireless dongle
I am using the freebie MSI 3070 wireless USB dongle that comes with the Intel DP67BG motherboard. It works, but every 1/2 to 1 hour fails to reauthenticate with my AP using WPA2. wpa_supplicant then loops forever probing for the AP. If I set the debug level way up and generate tons of debug output, it fails much less frequently, sometimes not at all, suggesting a timing issue. I've written a monitor to watch wpa_supplicant and kill and restart it when this happens. It associates on the first try after a restart. I am using the nl80211 backend for wpa_supplicant, and the rt2800usb driver from my slackware64-13.37 distribution. One thing I notice is that while the kernel output (printk) from rt2800usb timestamps its probes 200ms apart, if I look at the actual radio traffic with airodump-ng, the probes are coming out one right after another, 5ms apart, with no traffic in between. The probe response doesn't get in until probe requests stop going out and the AP has a chance to say something. Then there are several, but by then the driver has given up. I know there is a tx queue in the mac802.11 stack, and I'm guessing the queue is not getting run after each probe is queued up so they all go out at once. For what its worth, the wireless dongle is the only device on this particular USB bus.
I have a laptop on the same wireless network with a Broadcom wireless chip (b43 driver), and it works flawlessly. But the laptop is old and slow, and the Intel motherboard has a Core5 64 bit processor that is tons faster (not to mention quad core) and I have a feeling the speed differential is related to the problem...
I've got a usbmon trace of the traffic to the dongle, but trying to interpret it and find the mac802.11 frames is like trying to learn Mandarin, and I haven't been able to decipher the trace. I'd like to get the probes better spaced as they go out on the radio, but I don;t know how to do that. Any ideas?
Slackware64-13.37 uses the 2.6.37 kernel. This IS the latest w/o stepping outside the distribution. New info: I ran Wireshark against wlan0 and got no useful info - the management frames (which is where the problem is) are not captured there. I ran in monitor mode, and, as advertised, authentication is broken by monitor mode. So no joy there. I ran a usb monitor capture and have the requisite data in usb packet format. But Wireshark won't break out the MAC frames embedded in that, so some coding will be required. I note that there is some code in the driver (rt2x00usb) to force ("kick") the tx queue to be sent - bulk USB transfers do not have latency guarantees, and it isn't clear if the "kick" code is used for management frames anyway. I also note some comments in the mac80211 core code that various aspects of duration control are not implemented. At this point I'm not sure if that is relevant to this problem or not. Need advice from those who understand the 80211 stack better than I do.
I downloaded and compiled the compat-wireless-2.6 package for the rt2800 driver (+mac80211 and friends) and the dropouts have disappeared. I used the 2012-04-14 version. Be advised that the entire package WILL NOT compile against the 2.6.37 kernel sources used by Slackware64-13.37. There is a reference to a nonexistent power management routine in the wl12xx driver that breaks the full compile. All the others work and can be compiled individually with some pain. FYI: the problem in the rt2800 driver in the Slackware distro is timing related. Using the same wireless hardware and the same kernel source on an old Pentium IV uniprocessor works much better - occasional dropouts but nothing serious. Its only the fast 4 core 64 bit processor that fails. But the compat-wireless package cures that well enough that wpa-supplicant and/or the wireless stack doesn't hang like it did before. It simply reauths/reassocs without retries, like it is supposed to.
FYI: the b43 driver in compat-wireless will not load on slackware-13.37 (32 bit). Fortunately, the distro version works fine. I had to revert after building compat-wireless on my laptop to test my USB dongle. The built-in wireless then no longer worked. The compat-wireless version compiled, but needed symbols not in the 2.6.37 kernel in order to modprobe successfully.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.