Description of problem: I have a USB Wi-fi dongle based on rt2500usb module (D-Link dwl-g122 rev b1) that worked out of the box with kernel version 2.6.23.1-42.fc8 then I did an update with yum to kernel version 2.6.23.1-49.fc8 then it stopped working. The network manager keeps popping up messages to type my password. I can send the log messages. If I boot with the good old kernel, the wi-fi network just works again. I will attach the log messages from both of the versions. Version-Release number of selected component (if applicable): How reproducible: Just upgrade kernel 2.6.23.1-42.fc8 to 2.6.23.1-49.fc8
Created attachment 262931 [details] The messages from the working and not working kernels
Could you verify that this problem still occurs with the -62.fc8 kernels? Thanks! http://koji.fedoraproject.org/koji/buildinfo?buildID=25030
Created attachment 266641 [details] log of kernel -62.fc8
The problem still exists as you could see on attachment above. Just to be sure, I made a fresh install of fc8 and installed the kernel -62.fc8 to test it. The log above is from the new install. As before, the out of the box kernel (42) works perfectly. Thanks for your attention.
Can you disable NetworkManager and try configuring the network manually? service NetworkManager stop ifconfig wlan0 up iwlist wlan0 scan iwconfig wlan0 key <your WEP key> iwconfig wlan0 essid penguimnet dhclient wlan0 Does that get an IP address? If not, can you attach the output of running "iwconfig wlan0" after DHCP exits?
"iwconfig wlan0 key <your WEP key>" won't work there, he's using WPA according to the log, he has to use wpa_supplicant. I'm doing just that (manual setup using wpa_supplicant and dhclient) on a very similar configuration (rt2500usb, Surecom EP-9001-g rev 3A, WPA (TKIP CCMP), F8) and I'm getting what I believe to be the same problem: dhclient can't get an IP address, presumably because wpa_supplicant fails to connect. Known working: kernel-2.6.23.1-21.fc7, kernel-2.6.23.1-42.fc8 Known failing: kernel-2.6.23.8-63.fc8, kernel-2.6.23.9-80.fc8 I couldn't find anything pointing to the problem in the dmesg output.
Setting hardware to "All" because I'm seeing this on i686, the reporter on x86_64.
Known working: kernel-2.6.23.1-48.fc8 Known failing: kernel-2.6.23.1-49.fc8 Almost certainly the same bug as for the original submitter, it's a regression in -49.fc8.
Sorry, but I can't do more tests for now, since this device is not with me anymore. Luckly, Kevin is probably with the same problem as me. I hope it gets fixed.
Regarding comment 6, everyone using NetworkManager is using wpa_supplicant -- that doesn't mean they are all using WPA. The "Config: added 'wep_key0' value" line suggests that Andre is using WEP. Kevin, what is the USB ID of your device? Have you tried using rt73usb instead of rt2500usb? There is some overlap in the devices supported. Please attach the contents of /var/log/messages so there is something to suggest what the problem might actually be. There were a huge number of wireless changes between -42 (or -48) and -49, so it is difficult to no where to start.
> Regarding comment 6, everyone using NetworkManager is using wpa_supplicant -- > that doesn't mean they are all using WPA. The "Config: added 'wep_key0' > value" line suggests that Andre is using WEP. I based my observation on this: Nov 18 11:49:40 pinguimstation3 NetworkManager: <info> Config: added 'ssid' value 'pinguimnet' Nov 18 11:49:40 pinguimstation3 NetworkManager: <info> Config: added 'key_mgmt' value 'WPA-PSK' Nov 18 11:49:40 pinguimstation3 NetworkManager: <info> Config: added 'wep_key0' value '<omitted>' Nov 18 11:49:40 pinguimstation3 NetworkManager: <info> Config: added 'psk' value '<omitted>' Nov 18 11:49:40 pinguimstation3 NetworkManager: <info> Config: added 'proto' value 'WPA RSN' Nov 18 11:49:40 pinguimstation3 NetworkManager: <info> Config: added 'pairwise' value 'TKIP CCMP' Nov 18 11:49:40 pinguimstation3 NetworkManager: <info> Config: added 'group' value 'WEP40 WEP104 TKIP CCMP' Nov 18 11:49:40 pinguimstation3 NetworkManager: <info> Config: added 'wep_tx_keyidx' value '0' > Kevin, what is the USB ID of your device? 148f:2570 > Have you tried using rt73usb instead of rt2500usb? No, should I? This device is an rt2500usb chipset and has always worked with rt2500usb, and with the legacy rt2570 before that. About logfiles: I'll do so ASAP, probably later tonight (I'm going to reproduce it so I also have a dmesg).
FWIW, the log lines you are quoting are not in the attachment from comment 3. It looks like they are in the one from comment 1. I don't know what changed in between those logs. Also, it looks like your device will not work w/ rt73usb. There are some devices that work with both drivers to one degree or another. I'll leave this in NEEDINFO until you attach your logs...thanks!
Created attachment 283371 [details] My logs Here are my logs (hopefully no confidential stuff like WPA keys slipped in). Also, a small correction: my WPA is set to TKIP only, not dual TKIP/CCMP.
I'm not sure what is causing those authentication timeouts. This issue vaguely reminds me of bug 382781. I wonder if you might try forcing the bit rate to something fairly low: iwconfig wlan0 rate 5.5M Does that improve your connections?
Unfortunately it doesn't, it doesn't change anything. I also tried setting the rate to 11M or 54M, that didn't do any good either. (Sorry for the long turnaround, I've been busy with KDE 4 packaging and university stuff.)
Hey, during the tests I made, I have changed the router security to WEP and WPA to see if it worked too. But none of the configuration (WEP and WPA PSK) worked...
This is still not working with 2.6.23.12-101.fc8 (from Koji). Is there anything I can do to help debugging this any further?
I know Ivo is aware of the issue, and he is copied on this bug. He did just post a bunch of rt2x00 updates. I'll be processing them soon and should have fedora kernels available with his patches in the next couple of days...FYI.
I am afraid those patches won't bring the device back to life, at the moment I am stuck on this issue. I have run out of ideas for this issue, I will attempt to compile a few kernels with older rt2x00 versions to see which one was the last working version, and try to track down the patch that broke it. But unfortunately that will take some time, and I am not sure what the chance of success will be... :(
I've got back my usb device and just FYI the problem still exists with the newest kernel... Unusable device.
John, please make sure you merge the patch: rt2x00: Corectly initialize rt2500usb MAC which I have send to the linuxwireless mailinglist today, that should resolve this issue.
Unfortunately it doesn't. :-( I just tested kernel-2.6.23.13-105.fc8 from Koji which has this patch applied, it still doesn't work (I can't notice any difference in behavior from the other non-working kernels).
Still broken in kernel-2.6.23.14-115.fc8.
And still broken in kernel-2.6.23.15-137.fc8, so the Jan 23 wireless updates in 2.6.23.14-119.fc8 didn't fix it either.
Looking at the changes to MAC/BSSID addresses, there was this behavior change in the same changeset ("[PATCH] rt2x00: Remove duplicate code in MAC & BSSID handling") which introduced the thinko Ivo fixed ("rt2x00: Corectly initialize rt2500usb MAC"): + * Also note that when NULL is passed as address the + * we will send 00:00:00:00:00 to the device to clear the address. + * This will prevent the device being confused when it wants + * to ACK frames or consideres itself associated. The previous code just did nothing if NULL was passed. Forgive my ignorance (I'm a programmer, but not a device driver developer), but could it be that rt2500usb reacts badly to this change? If I understand the code correctly, rt2500usb handles MAC and BSSID registers somewhat differently (uses 48 bits rather than 64 bits as the other rt2x00 devices), so maybe it reacts differently to being passed a zero MAC or BSSID?
The change in required length is mainly due because of the difference in register word size. All Ralink devices have 32bit register words, except for rt2500usb which has 16bit register words. When the device is plugged in for the first time, the BSSID is 00:00:00:00:00:00, so that shouldn't be a problem. Your point about the MAC address might be, but it would be really strange if that matters for rt2500 and not for any of the other drivers. I'll look into it.
kernel-2.6.24.3-34.fc8 still not working.
Is this still a problem with the latest f8 kernels?
I haven`t tested with the new f8 kernels because I`m running FC9 now. Out of the box (2.25-14.fc9), the adapter is running just great and with the first kernel upgrade I did some minutes ago to 2.25.3-18.fc9, it runs like a charm. John, I think you can close this report. I didn`t close it because the problem may still exist on FC8 releases.