Authentication with AP timed out

Live forum: http://rt2x00.serialmonkey.com/viewtopic.php?t=4534

mrjoel

04-01-2008 03:59:20

I tried several times in the past to get the rt2x00 drivers working but haven't been successful (nor put much effort into it). Since the rt2570 driver no longer appears to work with 2.6.24 (to be posted in a separate thread), I'm trying in earnest now to get it working and ensure a functioning quality driver in the kernel.

I'm using a Gigabyte GN-WBKG (rt2570) adapter which has been working perfectly well with the legacy driver. I'm trying to get things up and running under Debian, but that probably isn't relevant.

I initially tried the driver as built in the Debian 2.6.24-rc5 kernel image and had problems, so I got a git clone of the rt2x00 repo (resynced against linux-2.6) and built it from that with the same issue.

I am trying to get a basic association going, so I've disable WEP to have an open connection, broadcasted SID, etc - it should be the most straight forward connection. I load the drivers manually (`modprobe rt2500usb` which loads rt2x00lib and rt2x00usb), then manually set the essid, channel, ap, etc with iwconfig. I get the following message sequence

[code2fp9xzkj]
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:02:2d:20:e6:a6
wlan0: authenticate with AP 00:02:2d:20:e6:a6
wlan0: authenticate with AP 00:02:2d:20:e6:a6
wlan0: authentication with AP 00:02:2d:20:e6:a6 timed out
[/code2fp9xzkj]

I saw similar issues addresses in other threads from around the November timeframe but never saw any resolution. Is there a fix for this, or can I provide other information to get this working?

This also seems related to, if not the same issue as, the following kernel bug http//bugzilla.kernel.org/show_bug.cgi?id=9388

Thanks!

Edit Wrong forum, please move to the rt2x00 forum - apologies

Spy84464

04-01-2008 12:43:21

Hello,
Ivo posted on the mailing list that rt2570usb is currently broken, he's working on this.

Regards,
Romain

AdamBaker

04-01-2008 20:39:42

If mrjoel has access to another wireless card that supports monitor mode he could help with debugging by seeing if the auth request gets sent to give an indication if the fault is with the transmit or receive side of the driver.

mrjoel

04-01-2008 21:58:02

Unfortunately I don't have another wireless adapter that I can do that with. Is this a common issue, or does it seem to be isolated to this device? Is there a general characterization of the problem, exist only on USB devices, only on rt2500usb?

IvD

04-01-2008 22:06:05

rt2500usb is the only one seriously affected it appears.

Attached is a script for debugfs, could you use it to create a dump of the rt2500usb registers after your attempt to associate.
And after that use the legacy driver (compiled with "make debugfs") and make a similar dump after the association.

With those 2 dumps I can check if there is a register problem,.

mrjoel

05-01-2008 05:32:50

Ok, here are the dumps. The script worked properly on the legacy driver (rt2570), but I had a couple of issues with it on the rt2500usb 1) the register files were in a register subdir instead of as the same level as "chipset", more more importantly 2) the chipset file existed, but had empty contents. I hard-coded the values that were reported in the legacy driver to get the provided dumps.

There are several differences in the values, likely some are strength, etc since the values are close. I have the rt2570 driver built with channels 1-14 enabled in case that shows up in the registers. Most interestingly, the CSR registers on the legacy driver don't seem to be used, or are at least all filled with the same value.

In case it's useful, I've also included a dump (from rt2500usb/frame/dump) of the time period during an attempted association (I haven't done any sanity checking on it).

One other bit I noticed that may or may not be relevant at this stage of association is the mode reported in debugfs - it seems to default to 802.11g but I'll need it at 802.11b, will this get negotiated during the assoociation stage?

Thanks, and let me know what else I can provide or test.

IvD

05-01-2008 09:01:01

Ok, here are the dumps. The script worked properly on the legacy driver (rt2570), but I had a couple of issues with it on the rt2500usb 1) the register files were in a register subdir instead of as the same level as "chipset", more more importantly 2) the chipset file existed, but had empty contents. I hard-coded the values that were reported in the legacy driver to get the provided dumps.
[/quote1noq4yxi]

Strange that the chipset file was empty. S


There are several differences in the values, likely some are strength, etc since the values are close. I have the rt2570 driver built with channels 1-14 enabled in case that shows up in the registers. Most interestingly, the CSR registers on the legacy driver don't seem to be used, or are at least all filled with the same value.
[/quote1noq4yxi]

This means the CSR debugfs reading in the legacy driver is broken. (
I'll try to check the rt2x00 register and see if that provides sufficient information. (My guess is that the bug is in the BBP registers.


In case it's useful, I've also included a dump (from rt2500usb/frame/dump) of the time period during an attempted association (I haven't done any sanity checking on it).
[/quote1noq4yxi]

Excellent thanks.


One other bit I noticed that may or may not be relevant at this stage of association is the mode reported in debugfs - it seems to default to 802.11g but I'll need it at 802.11b, will this get negotiated during the assoociation stage?
[/quote1noq4yxi]

802.11G is backwards compatible with 802.11B so it won't change during association but shouldn't hurt either,

mrjoel

12-01-2008 18:08:10

Any status updates on this? I'd love to be able to find a fix before the 2.6.24 release, but am not sure what else I can provide to be useful.

Thanks

IvD

12-01-2008 18:24:59

These issues (including the empty chipset file) should all be fixed in latest rt2x00.git.

mrjoel

13-01-2008 20:12:29

I was able to verify that the association bug is indeed fixed in latest version. Once I associate however, I'm not able to pass traffic over the interface. I'll look at other issues in the forum to try and resolve that however, and start a new one if I don't find anything. Thanks for getting this fixed.

angiest

15-01-2008 03:18:58

I am also able to authenticate with my AP (using WPA-PSK) with the latest git. I am also unable to communicate with the network. I would get 95% packet loss pinging my router, with the ones that were successful having something on the order of 50000ms latency.

mrjoel

04-03-2008 04:16:20

I've been watching the git commit progress and tried again, hoping that the issues with rt2500usb would be fixed. Unfortunately I'm back to where I was in this post initially

There seems to be a regression somewhere. I tried using the latest git (8a8dd6cbfa9..) and am again unable to associate. I had previously been able to associate but was having issue passing traffic (discussion[/url1bcgl3dx]).

What is the expected state of the rt2500usb driver? If it was expected to be working, what debug output can I provide? (Would the debugfs dumps again be useful?)