Association timeouts with DWL-G122, including past forum ref

Live forum:


29-11-2007 15:55:12

Howdy. Sorry if this has been solved; I'm a newbie to the rt2x00 list.

I'm having what I believe to be the same problem as the posts listed below, and I'm just wondering if anyone has a solution yet...

http// ... php?t=4395
http// ... php?t=4434
http// ... php?t=4387

I'm running a DLINK DWL-g122, using the complete current git kernel and driver, and am experiencing the same association timeouts mentioned in the above forum posts.

If any further information is required, I'd be delighted to run any kind of register dump, packet trace, or whatever else is required.

Thanks in advance.


29-11-2007 19:58:59

Ok, please give us some more information.

What's your wireless setup (most important encryption)?

We'll need syslog output, please switch on rt2x00/mac80211 debugging options in the kernel configuration if you haven't done so and post the relevant output here.

Btw. DWL-G122 is rt73.


30-11-2007 15:59:35

I'll get some syslog output posted here fairly quickly, but I have a question

Are you certain that the DWL-G122 is an rt73? I've removed the rt2500usb driver, modprobed the rt73usb driver, and it will not pick up the usb device. A listing of the DWL-G122 says it has USB id 20013c00, which is claimed only by the rt2500usb driver, not the rt73...


30-11-2007 19:14:05

I've attached the relevant chunk of /var/log/messages.

On another note, this must be a 2570. The rt73usb driver won't claim the device at all, and it doesn't reference the USB ID for it in /lib/modules/2.6.24-rc3/modules.usbmap.

I'm using 128-bit WEP.

The legacy rt2570usb driver works.


30-11-2007 23:57:42

Are you certain that the DWL-G122 is an rt73? I've removed the rt2500usb driver, modprobed the rt73usb driver, and it will not pick up the usb device. A listing of the DWL-G122 says it has USB id 20013c00, which is claimed only by the rt2500usb driver, not the rt73...[/quote1qvqh3to]

Well, what hardware rev do you have? My DWL-G122 rev C1 is rt73. But it's quite possible they used different chips in other versions of the device.


01-12-2007 00:03:06

Your syslog doesn't have any indications of driver failure. Does scanning work correctly? How do you configure the connection? Manually or using NetworkManager or some distro script?

It'd be interesting to see what packets show up on air. Do you have another device that you can use for monitoring? Alternatively, you can try the new frame dumping facility that was recently committed. Just drop a line if you want to do so and I'll provide further instructions.


03-12-2007 16:15:56

Scanning works, but not correctly at all times. I usually get different results on subsequent scans; sometimes my local AP doesn't show up at all, sometimes I get reports on 2 cells, sometimes 5. These are using the iwlist wlan0 scan command repeatedly, one after another.

The connection is being configured manually for the moment, with the following commands

# ip link set dev wlan0 up
# iwconfig wlan0 key xxxxxxxxxxxxxxxxxxx
# iwconfig wlan0 essid xxxxxxx

At this point, the iwconfig command correctly reports the Access Point MAC address, and the association timed out message appears in the /var/log/messages file. ifconfig wlan0 never shows RUNNING status, presumably because the association never completes.

I would be very pleased to provide packet dumps as necessary, just let me know what the procedure is and I'll get the info for you right away.

Thanks for your assistance!


03-12-2007 16:21:30

I'm not sure where I look to find out the hardware revision of my DWL-G122. Nothing in /proc/bus/usb/devices seems to indicate a revision ID, other than the Rev= 0.01 in the P line

P Vendor=2001 ProdID=3c00 Rev= 0.01


03-12-2007 16:25:03

Sorry, I must be having a blond moment. This DWL-G122 is a rev B1 device. It actually says so on the label -)


03-12-2007 20:51:06

You say scanning works partially, sometimes you get more, sometimes less results. This probably means the device doesn't pick up all responses, which can have various reasons, e.g. antenna setup problems, bad sensitivity settings etc.

What git kernel exactly are you running? Does it have the "rt2x00 Only update rssi average approximation on receiving beacon frames" patch? This one fixes a problem that causes sensitivity to be configured to low in noisy environments.

If you want to try frame dumping, please download my rt2wtap utility at [url1d8goxe1][/url1d8goxe1]
Compile it and run it like (not sure about the exact path, assuming debugfs is mounted on /debug)

./rt2wtap -i /debug/ieee80211/phyX/rt2500usb/frame/dump -o dump.pcap

Now it'll dump all frames that go through the driver to the dump.pcap file until you kill it. Try some scanning and associating, kill rt2wtap and post the dump.pcap file.


05-12-2007 03:41:26

just noticed my post linked in the original
and thought i would chime in with my observations
i see the same things as roe wether i connect using WPA,WEP or w/o encryption
including inconsistent scanning results and authentication/association timeouts appearing in /var/log/messages
my router also gives no indication that it recieved or sent anything to/from my adapter .
i noticed that if i tried to put it in monitor mode (to see if i could crack my own WEP) it craps out immediatly.
dont know if any of this info is helpful
if there is anything else i can give let me know


05-12-2007 09:19:46


Do you have another wireless device you could use for monitoring? So we can see whether the TX frames actually hit the air?



05-12-2007 20:41:08

I'm running the very latest git kernel/driver set (I checked this morning, no update required).

I'm attaching a dump.pcap file. This includes an association attempt, and two or three iwlist wlan0 scan commands.


06-12-2007 00:42:21

Your dump looks quite interesting. I can see all the probe requests, but never a probe response that comes back. However, all the beacons from your AP (i presume it's the one announcing the "lgbregina" ssid) seem to be received just fine. This either means

a) we have a problem with TX, so the packets don't get transmitted properly. Obviously, there cannot be any replies then.
b) There are replies, but we fail to pick them up.

To rule out any incorrect RX frame filtering by the device, I've attached a patch that you can try. Please create another dump with the patch applied.

However, my current bet is your problem is a). It'd help a lot if you could run another wireless device in monitor mode to find out whether the frames sent out by the rt2x00 driver actually hit the air. Do you have any other hardware available to do that? This can even be done using wireshark on windows IIRC.


06-12-2007 15:21:13

Yes, I have hardware available to do a monitor dump. What's the procedure?


06-12-2007 15:25:22

I should mention that my "other hardware" is running linux, not windoesn't.


06-12-2007 19:29:33

On Linux you need to bring up the wireless device in monitor mode (replace wlanX with your interface and Y with the wireless channel you want to monitor)

[codedqft5hm6]iwconfig wlanX mode monitor
ip link set wlanX up
iwconfig wlanX channel Y[/codedqft5hm6]

Then, run wireshark (as root), select Capture -> Interfaces and click the start button for your interface. Alternatively, you can use dumpcap if you don't want to run wireshark as root

[codedqft5hm6]dumpcap -i wlanX -w <file>[/codedqft5hm6]

Please also start rt2wtap to dump the packets received and transmitted by the driver, so we can correlate the contents of the dumps and find if something is missing in one or the other.

Then, just do some scanning and association attempts as before.

When you're done, stop all dumping (save the dump file if you used wireshark) and bring the monitor interface back down

[codedqft5hm6]ip link set wlanX down[/codedqft5hm6]

P.S. If you want to do the dump on windows, please consult the wireshark website, I haven't done any monitoring on windows, so I cannot give precise instructions. If there is somebody who knows how to do that, please speak up!

Thanks for your efforts!


07-12-2007 15:31:04

OK, here's a post-patch dump of an association and a couple of scans.

The symptoms are identical, so I suspect you are correct that transmission is having a problem.

I'm in the middle of installing an OS on a monitoring system, and will post further dumps once I get that done.

Thanks again for the assistance.


07-12-2007 16:05:13

I've attached two files, dump.pcap.gz (an rt dump), and dump.monitor.gz, which is a dumpcap from the monitor box.

I hope this sheds some light.


08-12-2007 02:58:26

Interesting dumps indeed. It seems there are lots of frames that the driver fails to receive. Actually there are probe responses to the probe requests in the monitor log, but not in the rx log. This probably means the receive path is broken, not the transmit path as I suspected before.

Now the question is what might be wrong. Could be antenna setup, txpower, whatever. Since you said the legacy driver works, the best way to find out is to compare what it actually does different. It'd be great if you could obtain register dumps. The necessary script and more instructions are here [url3rfzvl7i][/url3rfzvl7i] Please make sure you run the register dump after you brought up the device and tried scanning.