rt2500pci works, rt2500usb not

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

ben

11-10-2007 08:14:13

I have two ralink cards which I have tried with the git-kernel. The pcmcia card works, though the download speed could be improved. The USB card does not work.
Both cards are 11g capable, but the driver starts them in 11b mode and I can't change that to 11g.

The working PCMCIA card is an E-tech WGPC03.

[code1lbtg1wj]# lspci -v -nn -s 06:00.0
06:00.0 Network controller [0280]: RaLink RT2500 802.11g Cardbus/mini-PCI [1814:0201] (rev 01)
Subsystem: RaLink Unknown device [1814:2560]
Flags: bus master, slow devsel, latency 64, IRQ 11
Memory at 2c000000 (32-bit, non-prefetchable) [size=8K]
Capabilities: [40] Power Management version 2[/code1lbtg1wj]

[code1lbtg1wj]$ iwconfig lwan0
wlan0 IEEE 802.11b ESSID:"BNC-WLAN"
Mode:Managed Frequency:2.412 GHz Access Point: 00:0D:9D:F6:43:87
Bit Rate=11 Mb/s Tx-Power=27 dBm
Retry min limit:7 RTS thr:off Fragment thr=2346 B
Link Quality=60/100 Signal level=-70 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0[/code1lbtg1wj]

upload speed
[code1lbtg1wj]$ scp 10mbtest user@othermachine:
10mbtest 100% 10MB 588.2KB/s 00:17[/code1lbtg1wj]

download speed
[code1lbtg1wj]$ scp user@othermachine:10mbtest .
10mbtest 100% 10MB 178.6KB/s 00:56[/code1lbtg1wj]

As you can see, the download-speed is a lot slower than the upload speed.

The second card is an E-tech WGUS02 USB card

[code1lbtg1wj]# lsusb
Bus 001 Device 002: ID 148f:2570 Ralink Technology, Corp. 802.11g WiFi[/code1lbtg1wj]

This card gets a time-out when authenticating. The scan works, but the
association fails (with all 3 AP's).

[code1lbtg1wj]# iwlist wlan1 scan
wlan1 Scan completed :
Cell 01 - Address: 00:0D:9D:F6:43:87
ESSID:"TEST"
Mode:Master
Channel:1
Frequency:2.412 GHz (Channel 1)
Quality=49/100 Signal level=-66 dBm
Encryption key:on
IE: WPA Version 1
Group Cipher : TKIP
Pairwise Ciphers (1) : TKIP
Authentication Suites (1) : PSK
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
12 Mb/s; 24 Mb/s; 36 Mb/s; 9 Mb/s; 18 Mb/s
48 Mb/s; 54 Mb/s
Extra:tsf=000000053d6fd181
Cell 02 - Address: 00:0D:9D:F6:62:A7
ESSID:"TEST"
Mode:Master
Channel:6
Frequency:2.437 GHz (Channel 6)
Quality=48/100 Signal level=-68 dBm
Encryption key:on
IE: WPA Version 1
Group Cipher : TKIP
Pairwise Ciphers (1) : TKIP
Authentication Suites (1) : PSK
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
12 Mb/s; 24 Mb/s; 36 Mb/s; 9 Mb/s; 18 Mb/s
48 Mb/s; 54 Mb/s
Extra:tsf=00000004c5aae181
Cell 03 - Address: 00:0D:9D:F6:62:8B
ESSID:"TEST"
Mode:Master
Channel:11
Frequency:2.462 GHz (Channel 11)
Quality=49/100 Signal level=-66 dBm
Encryption key:on
IE: WPA Version 1
Group Cipher : TKIP
Pairwise Ciphers (1) : TKIP
Authentication Suites (1) : PSK
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
12 Mb/s; 24 Mb/s; 36 Mb/s; 9 Mb/s; 18 Mb/s
48 Mb/s; 54 Mb/s
Extra:tsf=0000000400f9c181[/code1lbtg1wj]

Is there something I can post that can help debug this problem?

angiest

11-10-2007 13:05:27

I am experiencing the same behaviour using rt2x00 from git on Gentoo. Trying to authenticate against my AP (dd-wrt) results in a timeout, regardless of if I am using iwconfig or wpa_supplicant, either with WEP or WPA. I have a novatech adapter.

AdamBaker

11-10-2007 19:46:03

ben the problem with only getting b mode is known and various fixed are being discussed / tested to see what is best. The simplest fix is to remove the block of code
[code2ubkzifm]
if (spec->num_modes > HWMODE_B) {
hwmodes[HWMODE_B].mode = MODE_IEEE80211B;
hwmodes[HWMODE_B].num_channels = 14;
hwmodes[HWMODE_B].num_rates = 4;
hwmodes[HWMODE_B].channels = channels;
hwmodes[HWMODE_B].rates = rates;
}
[/code2ubkzifm]
from rt2x00dev.c but there is a possibility that could cause problems with old B only APs.

Do you know if you get auth timeouts only with WPA or if you get them with WEP or no authentication too? Are you sure if your git download includes commit 18ca6f265e8bd66c482c70cfeda7a3ad449c718a (mac80211 Defer setting of RX_FLAG_DECRYPTED) from 3 days ago without which WEP and WPA are broken. Do you have CONFIG_RT2X00_DEBUG=y in your .config (I guess so as you know auth is failing). In that case it might be useful to see the dmesg output to check for anything unusual.

angiest It would be useful to know what adapter you are using, if unencrypted fails and how old your git tree is.

IvD

11-10-2007 20:19:32

ben the problem with only getting b mode is known and various fixed are being discussed / tested to see what is best. The simplest fix is to remove the block of code
[code139yz8ft]
if (spec->num_modes > HWMODE_B) {
hwmodes[HWMODE_B].mode = MODE_IEEE80211B;
hwmodes[HWMODE_B].num_channels = 14;
hwmodes[HWMODE_B].num_rates = 4;
hwmodes[HWMODE_B].channels = channels;
hwmodes[HWMODE_B].rates = rates;
}
[/code139yz8ft]
from rt2x00dev.c but there is a possibility that could cause problems with old B only APs.
[/quote139yz8ft]

That is _not_ the correct section of code that should be removed. Commenting this code will cause a NULL pointer exception or a segmentation fault
The correct patch is

[code139yz8ft]diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 360f03a..89470c0 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -866,9 +866,9 @@ static int rt2x00lib_probe_hw_modes(struct rt2x00_dev *rt2x00dev,
ieee80211_register_hwmode(hw, &hwmodes[HWMODE_G]))
goto exit_free_rates;

- if (spec->num_modes > HWMODE_B &&
+ /*if (spec->num_modes > HWMODE_B &&
ieee80211_register_hwmode(hw, &hwmodes[HWMODE_B]))
- goto exit_free_rates;
+ goto exit_free_rates;*/

if (spec->num_modes > HWMODE_A &&
ieee80211_register_hwmode(hw, &hwmodes[HWMODE_A]))
[/code139yz8ft]

ben

12-10-2007 14:24:18

I did not have CONFIG_RT2X00_DEBUG in my kernel, I instead looked at the debugging output from wpa_supplicant.

I do have the patch you mentioned. I think that the pci card would have failed in wpa mode if the patch was missing?

I have now tried to associate with an AP without encryption. That worked, I got an IP-address with DHCP, the packetcount is increasing, but I can't get any data accross...

With WEP I again get a timeout and the following in dmesg

[code37hlgmej]usb 1-2: new full speed USB device using uhci_hcd and address 3
usb 1-2: configuration #1 chosen from 1 choice
phy0 -> rt2500usb_validate_eeprom: EEPROM recovery - NIC: 0xfff0
phy0 -> rt2x00_set_chip: Info - Chipset detected - rt: 1201, rf: 0005, rev: 00000005.
phy0: Selected rate control algorithm 'simple'
usbcore: registered new interface driver rt2500usb
udev: renamed network interface wlan0 to wlan1
phy0 -> rt2500usb_init_bbp: Debug - Start initialization from EEPROM...
phy0 -> rt2500usb_init_bbp: Debug - BBP: 0x11, value: 0x32.
phy0 -> rt2500usb_init_bbp: Debug - BBP: 0x15, value: 0x18.
phy0 -> rt2500usb_init_bbp: Debug - BBP: 0x16, value: 0x18.
phy0 -> rt2500usb_init_bbp: Debug - BBP: 0x3e, value: 0x00.
phy0 -> rt2500usb_init_bbp: Debug - ...End initialization from EEPROM.
ADDRCONF(NETDEV_UP): wlan1: link is not ready
phy0 -> rt2x00mac_conf_tx: Info - Configured TX ring 0 - CWmin: 4, CWmax: 10, Aifs: 2.
phy0 -> rt2x00mac_conf_tx: Info - Configured TX ring 1 - CWmin: 4, CWmax: 10, Aifs: 2.
phy0 -> rt2x00mac_conf_tx: Info - Configured TX ring 7 - CWmin: 5, CWmax: 10, Aifs: 2.
wlan1: Initial auth_alg=0
wlan1: authenticate with AP 00:50:18:4b:1f:e0
wlan1: authenticate with AP 00:50:18:4b:1f:e0
wlan1: authenticate with AP 00:50:18:4b:1f:e0
wlan1: authentication with AP 00:50:18:4b:1f:e0 timed out[/code37hlgmej]

does that help?

AdamBaker

12-10-2007 23:14:17

Yes, you are correct WPA would have failed for both cards if you were using the same kernel for both and didn't have the SW decryption patch.

As the chipset is so similar between these 2 cards I'm wondering if the difference is in antenna configuration. Looking at the E-tech web site I suspect the USB one has one visible external antenna and the PCMCIA one has an unknown number of internal antennas.

Are you able to produce register dumps?

angiest

14-10-2007 01:49:00

I am using a Novatech 902W adapter with git that is current as of yesterday (so far as I can tell).

ben

14-10-2007 11:49:55

As the chipset is so similar between these 2 cards I'm wondering if the difference is in antenna configuration. Looking at the E-tech web site I suspect the USB one has one visible external antenna and the PCMCIA one has an unknown number of internal antennas.[/quote1uxcfhkn]

Correct. The pcmcia card is something like this[/url1uxcfhkn], the USB adapter something like [url=http://e-tech.nu/Product_Detail.php?prodtitle=&SET_ID=1165&GET_LANG=E&LANG=E&SUB=Wireless541uxcfhkn]this[/url1uxcfhkn].

[quote1uxcfhkn]Are you able to produce register dumps?[/quote1uxcfhkn]

If you tell me how.

AdamBaker

14-10-2007 20:05:05

OK, here's a script to dump the register contents, I've inlined it so you can read it easily and attached it so you can get a copy with the spacing correct. You need to modify the DEBUG_DIR path to reflect where you have mounted debugfs and normally needs to be run as root.

[coderb6k2b3u]
#!/bin/bash
DEBUG_DIR=/proc/sys/debug/ieee80211/phy*/rt*
DEBUG_FILE=$DEBUG_DIR/chipset

for TYPES in `cat $DEBUG_FILE | cut -d ' ' -f 1`
do
echo $TYPES
COUNT=`grep $TYPES $DEBUG_FILE | cut -d ':' -f 2`
for (( x=1; x<$COUNT; x=x+1 ))
do
echo $x > $DEBUG_DIR/"$TYPES"_offset
echo -n $x :
cat $DEBUG_DIR/"$TYPES"_value
done
done
[/coderb6k2b3u]

ben

15-10-2007 07:54:47

OK, here's a script to dump the register contents, I've inlined it so you can read it easily and attached it so you can get a copy with the spacing correct. You need to modify the DEBUG_DIR path to reflect where you have mounted debugfs and normally needs to be run as root.[/quote2nfw3z3r]

I must be missing something. I (re)compiled a kernel with debugfs support

[code2nfw3z3r]...
CONFIG_DEBUG_FS=y
...
#
# Wireless
#
CONFIG_CFG80211=m
CONFIG_NL80211=y
CONFIG_WIRELESS_EXT=y
CONFIG_MAC80211=m
CONFIG_MAC80211_DEBUGFS=y
CONFIG_MAC80211_DEBUG=y
# CONFIG_MAC80211_VERBOSE_DEBUG is not set
# CONFIG_MAC80211_LOWTX_FRAME_DUMP is not set
# CONFIG_TKIP_DEBUG is not set
# CONFIG_MAC80211_DEBUG_COUNTERS is not set
# CONFIG_MAC80211_IBSS_DEBUG is not set
# CONFIG_MAC80211_VERBOSE_PS_DEBUG is not set
CONFIG_IEEE80211=m
CONFIG_IEEE80211_DEBUG=y
CONFIG_IEEE80211_CRYPT_WEP=m
# CONFIG_IEEE80211_CRYPT_CCMP is not set
CONFIG_IEEE80211_CRYPT_TKIP=m
CONFIG_IEEE80211_SOFTMAC=m
CONFIG_IEEE80211_SOFTMAC_DEBUG=y
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
...
CONFIG_RT2X00=m
CONFIG_RT2X00_LIB=m
CONFIG_RT2X00_LIB_PCI=m
CONFIG_RT2X00_LIB_USB=m
# CONFIG_RT2400PCI is not set
CONFIG_RT2500PCI=m
# CONFIG_RT2500PCI_RFKILL is not set
# CONFIG_RT61PCI is not set
CONFIG_RT2500USB=m
# CONFIG_RT73USB is not set
# CONFIG_RT2X00_LIB_DEBUGFS is not set
CONFIG_RT2X00_DEBUG=y
...[/code2nfw3z3r]

But I don't have the directory $DEBUGFS)/ieee80211/phy*/rt*, all I have is

[code2nfw3z3r]# ls -F ieee80211/phy0
antenna_sel_rx frequency netdev:wlan1/ statistics/
antenna_sel_tx keys/ netdev:wmaster0/ total_ps_buffered
bridge_packets long_retry_limit rts_threshold wep_iv
channel mode short_retry_limit
fragmentation_threshold modes stations/[/code2nfw3z3r]

AdamBaker

15-10-2007 19:58:02

After building debugfs support you need to mount the debugfs file system somewhere. I normally mount it on /proc/sys/debug with the fstab line

debugfs /proc/sys/debug debugfs defaults 0 0

ben

16-10-2007 06:47:15

The problem is not that I can't mount debugfs, but that in the debugfs the directory is missing in which the chipset file should be. So I do have

[code27t5uzvo]/proc/sys/debug/ieee80211/phy0/[/code27t5uzvo]

But in there the directory rt* is missing. Did I forget something? like a module or a kernel CONFIG_ directive?

fatbob

16-10-2007 08:07:21

I don't know, but this line in your kernel config look suspicious
[codeyq868ckf]# CONFIG_RT2X00_LIB_DEBUGFS is not set [/codeyq868ckf]

ben

16-10-2007 08:17:01

But in there the directory rt* is missing. Did I forget something? like a module or a kernel CONFIG_ directive?[/quote3jtor3l8]

It seems I overlooked CONFIG_RT2X00_LIB_DEBUGFS... (correctly spotted by fatbob).

Somehow attaching the dump went wrong, so I made it downloadable here[/url3jtor3l8]

AdamBaker

16-10-2007 10:28:40

Looks like I made a typo in the dump script, the inner for loop should start at 0 not 1 but that doesn't matter for checking the antenna data.

Your card claims to have only 1 antenna, Antenna A which should be used for rx and tx. This is one of the simplest setups and the code for that seems to match the legacy driver so I doubt the antenna setup is failing.

What is strange is that reading the bbp and rf registers has completely failed so I can't see what antenna has actually been selected. Is there anything in the dmesg output to indicate what might have gone wrong?

Does the legacy driver work for you? Do you know if your USB port is USB 1.1 or 2.0? If you don't know look in /proc/bus/usb/devices and in the block of entries for that device it should say Spd=12 or Spd=480 on the T line

ben

16-10-2007 11:30:57

What is strange is that reading the bbp and rf registers has completely failed so I can't see what antenna has actually been selected. Is there anything in the dmesg output to indicate what might have gone wrong?

Does the legacy driver work for you? Do you know if your USB port is USB 1.1 or 2.0? If you don't know look in /proc/bus/usb/devices and in the block of entries for that device it should say Spd=12 or Spd=480 on the T line[/quote34d0g2ch]

Lets retry some of that. I uploaded a new dump[/url34d0g2ch] (the first time I did not do anything with the wlan interface, which might explain the 'empty' rf registers).

Also the relevant part of my dmesg output

[code34d0g2ch]usb 1-2: new full speed USB device using uhci_hcd and address 2
usb 1-2: configuration #1 chosen from 1 choice
phy0 -> rt2500usb_validate_eeprom: EEPROM recovery - NIC: 0xfff0
phy0 -> rt2x00_set_chip: Info - Chipset detected - rt: 1201, rf: 0005, rev: 00000005.
phy0: Selected rate control algorithm 'simple'
usbcore: registered new interface driver rt2500usb
udev: renamed network interface wlan0 to wlan1
phy0 -> rt2500usb_init_bbp: Debug - Start initialization from EEPROM...
phy0 -> rt2500usb_init_bbp: Debug - BBP: 0x11, value: 0x32.
phy0 -> rt2500usb_init_bbp: Debug - BBP: 0x15, value: 0x18.
phy0 -> rt2500usb_init_bbp: Debug - BBP: 0x16, value: 0x18.
phy0 -> rt2500usb_init_bbp: Debug - BBP: 0x3e, value: 0x00.
phy0 -> rt2500usb_init_bbp: Debug - ...End initialization from EEPROM.
ADDRCONF(NETDEV_UP): wlan1: link is not ready
phy0 -> rt2x00mac_conf_tx: Info - Configured TX ring 0 - CWmin: 4, CWmax: 10, Aifs: 2.
phy0 -> rt2x00mac_conf_tx: Info - Configured TX ring 1 - CWmin: 4, CWmax: 10, Aifs: 2.
phy0 -> rt2x00mac_conf_tx: Info - Configured TX ring 7 - CWmin: 5, CWmax: 10, Aifs: 2.
wlan1: Initial auth_alg=0
wlan1: authenticate with AP 00:0d:9d:f6:62:8b
wlan1: authenticate with AP 00:0d:9d:f6:62:8b
wlan1: authenticate with AP 00:0d:9d:f6:62:8b
wlan1: authentication with AP 00:0d:9d:f6:62:8b timed out[/code34d0g2ch]

All this was done on an old laptop with only USB 1.1.

I might be able to set something up with a newer system, but that will take some time, so I will only set it up if it might provide new information...

[BTW I can't attach a dump.txt, because "the maximum filesize for all Attachments is reached"]

AdamBaker

16-10-2007 12:18:42

Well the BBP antenna registers are correct too so I'll have to look a bit deeper to see if anything else is wrong.

USB 1.1 was causing problems a few months back but they should be fixed now. In the absence of any indications to the contrary I wouldn't go to any great effort to try 2.0.

Have you tried the legacy driver? If that works can you do a register dump with that for comparison?

ben

16-10-2007 14:35:04

Have you tried the legacy driver? If that works can you do a register dump with that for comparison?[/quote1m1a59cr]

It does not work. The strange thing is, that the number of registers is different

[code1m1a59cr]csr length: 128
eeprom length: 53
bbp length: 96
rf length: 0[/code1m1a59cr]

I'll see if I can set up another (more recent) system tomorrow.

ben

19-10-2007 10:24:01

I am trying to figure out what is going wrong with the USB adapter. I noticed something strange in the kernel-log, when I try to associate with wpa_supplicant with this config

[code3v152hyz]ctrl_interface=/var/run/wpa_supplicant

network={
ssid="TEST"
proto=WPA
key_mgmt=WPA-PSK
psk="secret"
}[/code3v152hyz]

When running wpa_supplicant, an association attempt times out after 10 seconds with "Authentication with 000000000000 timed out." But in the kernel log this timeout happens almost immediately

[code3v152hyz]Oct 19 10:39:36 nstest kernel: phy1 -> rt2500usb_init_bbp: Debug - Start initialization from EEPROM...
Oct 19 10:39:36 nstest kernel: phy1 -> rt2500usb_init_bbp: Debug - BBP: 0x11, value: 0x32.
Oct 19 10:39:36 nstest kernel: phy1 -> rt2500usb_init_bbp: Debug - BBP: 0x15, value: 0x18.
Oct 19 10:39:36 nstest kernel: phy1 -> rt2500usb_init_bbp: Debug - BBP: 0x16, value: 0x18.
Oct 19 10:39:36 nstest kernel: phy1 -> rt2500usb_init_bbp: Debug - BBP: 0x3e, value: 0x00.
Oct 19 10:39:36 nstest kernel: phy1 -> rt2500usb_init_bbp: Debug - ...End initialization from EEPROM.
Oct 19 10:39:36 nstest kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Oct 19 10:39:37 nstest kernel: phy1 -> rt2x00mac_conf_tx: Info - Configured TX ring 0 - CWmin: 4, CWmax: 10, Aifs: 2.
Oct 19 10:39:37 nstest kernel: phy1 -> rt2x00mac_conf_tx: Info - Configured TX ring 1 - CWmin: 4, CWmax: 10, Aifs: 2.
Oct 19 10:39:37 nstest kernel: phy1 -> rt2x00mac_conf_tx: Info - Configured TX ring 7 - CWmin: 5, CWmax: 10, Aifs: 2.
Oct 19 10:39:37 nstest kernel: wlan0: Initial auth_alg=0
Oct 19 10:39:37 nstest kernel: wlan0: authenticate with AP 00:0d:9d:f6:62:8b
Oct 19 10:39:37 nstest last message repeated 2 times
Oct 19 10:39:37 nstest kernel: wlan0: authentication with AP 00:0d:9d:f6:62:8b timed out
Oct 19 10:39:47 nstest kernel: wlan0: Initial auth_alg=0
Oct 19 10:39:47 nstest kernel: wlan0: authenticate with AP 00:0d:9d:f6:62:8b
Oct 19 10:39:47 nstest kernel: phy1 -> rt2x00mac_conf_tx: Info - Configured TX ring 0 - CWmin: 4, CWmax: 10, Aifs: 2.
Oct 19 10:39:47 nstest kernel: phy1 -> rt2x00mac_conf_tx: Info - Configured TX ring 1 - CWmin: 4, CWmax: 10, Aifs: 2.
Oct 19 10:39:47 nstest kernel: phy1 -> rt2x00mac_conf_tx: Info - Configured TX ring 7 - CWmin: 5, CWmax: 10, Aifs: 2.
Oct 19 10:39:47 nstest kernel: wlan0: Initial auth_alg=0
Oct 19 10:39:47 nstest kernel: wlan0: authenticate with AP 00:0d:9d:f6:62:8b
Oct 19 10:39:47 nstest kernel: wlan0: Initial auth_alg=0
Oct 19 10:39:47 nstest kernel: wlan0: authenticate with AP 00:0d:9d:f6:62:8b
Oct 19 10:39:47 nstest last message repeated 2 times
Oct 19 10:39:47 nstest kernel: wlan0: authentication with AP 00:0d:9d:f6:62:8b timed out[/code3v152hyz]

And 10 seconds later, wpa supplicant tries again. In net/mac80211/ieee80211_sta.c you can see that this is not really a timeout

[code3v152hyz] ifsta->auth_tries++;
if (ifsta->auth_tries > IEEE80211_AUTH_MAX_TRIES) {
printk(KERN_DEBUG "%s: authentication with AP " MAC_FMT
" timed out\n",
dev->name, MAC_ARG(ifsta->bssid));
ifsta->state = IEEE80211_DISABLED;
return;
}[/code3v152hyz]

But I don't know why every try fails...

gabriele

22-10-2007 15:19:44

Just to let you know...

I'm using rt2500usb on PPC and the last working kernel for me is 2.6.23-rc6-g0f7b3002 which uses version 2.0.8 of the module.
Since then I get timeout during authentication with AP.

I use the kernel from rt2x00 git repository on a Debian Testing with wpa_supplicant 6.0.

Authentication method wpa-psk

AdamBaker

22-10-2007 23:07:54

The legacy driver not working is bad news - rt2x00 is primarily relying on the legacy driver for documentation of how the chipset should be used so if it is wrong for your card then either you've got a hardware fault or something strange in the hardware design that requires a special driver tweak we aren't aware of.

Every authenticate attempt failing could mean either that the auth requests aren't really being sent - you might be able to tell that on the access point or using another card and kismet or the replies aren't being received (or they are received but not decoded). You could differentiate the latter 2 cases by putting a printk into the receive code.

You don't say if scans are working - scan reception sometimes works even when association doesn't and can be a useful pointer to what is wrong.

ben

23-10-2007 08:04:18

The legacy driver not working is bad news - rt2x00 is primarily relying on the legacy driver for documentation of how the chipset should be used so if it is wrong for your card then either you've got a hardware fault or something strange in the hardware design that requires a special driver tweak we aren't aware of.[/quote3iyxag4w]

I know it is bad news and I always had trouble getting the legacy driver to work with this card. I did manage to get the RaLink driver (v2.0.8.0) to work with kernel 2.6.17.

A hardware failure is unlikely, as I tested another card straight out of the box (yesterday).

Every authenticate attempt failing could mean either that the auth requests aren't really being sent - you might be able to tell that on the access point or using another card and kismet or the replies aren't being received (or they are received but not decoded). You could differentiate the latter 2 cases by putting a printk into the receive code.[/quote3iyxag4w]

Where do I put a printk? In what function?

I do know how to write a printk, so I don't need a ready-to-apply patch, but I am not familiar with the low-level kernel drivers. I did manage to follow the code in the mac80211 layer, but on the lower level I am a bit lost... A few pointers could help my understanding a lot.

You don't say if scans are working - scan reception sometimes works even when association doesn't and can be a useful pointer to what is wrong.[/quote3iyxag4w]

Scanning is working.

AdamBaker

24-10-2007 21:50:38

The first place to try putting a printk would be rt2x00usb_interrupt_rxdone in the file rt2x00usb.c (actually you can use the slightly nicer rt2x00 DEBUG statement that prints the function name for you there as you've got an rt2x00dev pointer).

If that shows that data is being received then the next candidates to try would be the rx handlers in the file rx.c in mac80211 (ieee80211_rx_h_*). That is where the packet gets dropped if it can't be decrypted or looks corrupt.

angiest

25-10-2007 03:52:04

The legacy driver not working is bad news - rt2x00 is primarily relying on the legacy driver for documentation of how the chipset should be used so if it is wrong for your card then either you've got a hardware fault or something strange in the hardware design that requires a special driver tweak we aren't aware of.
[/quote35cmp3lw]

Unfortunately I don't have a whole lot of time to spend on this, but for me the legacy driver from portage is working with kernels 2.6.21-gentoo-r4 and lower. The legacy drivers in portage do not compile with higher kernel revs.

ben

26-10-2007 09:36:26

after a lot of printk's and comparing the result from a rt61pci with the rt2500usb, I found something.

When the rt61pci starts authenticating, the received frame is handled by ieee80211_rx_mgmt_auth, but when the rt2500usb starts authenticating, the received frame is handled by ieee80211_rx_mgmt_beacon.

Does this make any sense?

AdamBaker

26-10-2007 23:08:57

At a guess rt2500usb isn't receiving the auth (either because the AP didn't recognise the request or because it isn't listening properly) so the first receive packet you see is the next 100ms beacon. (We know beacons are received OK because scan works).

The auth message is addressed to the AP whereas the beacon is broadcast so this could suggest a problem with configuring the MAC address. It would really be helpful at this point if you are able to use the RT61 and wireshark to capture what happens when the rt2500 tries to authenticate.

ben

30-10-2007 10:13:30

Here is the output from wireshark

debug output from /var/log/debug
scan.dump wireshark dump of a 'iwlist wlan0 scan'
wpa.dump wireshark dump from a 'wpa_supplicant...'

(there are a few packets from an intel device, which should be ignored)

There is definitely something wrong, but I don't know enough of the protocol to say what...

AdamBaker

30-10-2007 21:23:31

That looks to me as if rt2500usb is failing to transmit any frames, including ACK frames, that are addressed to a specific (i.e. non broadcast) address.

Why that may be happening is a bit of a puzzle but does suggest investigation needs to focus on the transmit side, not receive.

ben

02-11-2007 13:08:34

Something strange here. I posted the wireshark-dump on Tuesday. Now since Wednesday I am missing all broadcast frames from my dumps... So I can see the Probe-Response, but not the Probe-Request. Any thoughts on that?

On topic, it does look like the auth-frame is not sent. But I don't know where it is dropped. The debug-log tells us that an auth-frame is being sent, but the wireshark dump show that it is not.

I put some extra printk's in the code and it looks like the frame is being handled by usb_submit_urb without an error (the callback to rt2x00usb_interrupt_txdone has a urb->status==0). Any thoughts on where to look for dropped frames?

AdamBaker

02-11-2007 17:29:59

There is some code that rounds up thew USB packet sizes to match the hardware's requirements that was only modified a few weeks ago. If the hardware doesn't like the packet (and if that code is wrong it won't) it will either transmit nothing or transmit a corrupt packet that another machine wouldn't see.

Not saying that's definitely the problem, it's just the first place I'd look.

ben

05-11-2007 09:51:08

As of this weekend, the driver stopped working completely.

[code2wb397sm]phy0 -> rt2500usb_validate_eeprom: EEPROM recovery - NIC: 0xfff0
phy0 -> rt2x00_set_chip: Info - Chipset detected - rt: 1201, rf: 0005, rev: 00000005.
phy0 -> rt2500usb_init_eeprom: Error - Invalid RT chipset detected.
phy0 -> rt2x00lib_probe_dev: Error - Failed to allocate device.
[/code2wb397sm]

This is probably related to the "Fix chipset revision validation" patch in the git-tree. Could this also help in finding the problem with this card?

IvD

05-11-2007 18:55:35

Fixed in git/cvs

ben

06-11-2007 12:58:17

IvD Thanks for the fix.

With the latest updates, I am getting a little further. The rt2500usb is sending the auth-frames, but it looks like it is not receiving the ack (or is my interpretation wrong?).

AdamBaker

06-11-2007 22:55:07

That certainly seems to be the case. You can see the ACKs captured but the continuous retries indicate that the ACK isn't seen by the RT2500. The AP then generates the responding AUTH message but the rt2500 misses that too. You can also see the 3 separate auth attempts as reported in dmesg from the sequence number changing.

Is scan still working?

ben

07-11-2007 09:45:11

yes, scanning still works. The rt2500usb even sends some ack-frames on the probe-responses (approx. the same as the rt61pci).