Bug 389381 - rt2500usb with D-Link dwl-g122 rev b1 stopped working
rt2500usb with D-Link dwl-g122 rev b1 stopped working
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-18 09:35 EST by André Pinto
Modified: 2008-05-27 10:12 EDT (History)
4 users (show)

See Also:
Fixed In Version: 2.25.3-18.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-27 10:12:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
The messages from the working and not working kernels (19.35 KB, text/plain)
2007-11-18 09:35 EST, André Pinto
no flags Details
log of kernel -62.fc8 (3.75 KB, text/plain)
2007-11-22 04:58 EST, André Pinto
no flags Details
My logs (19.79 KB, text/plain)
2007-12-10 16:53 EST, Kevin Kofler
no flags Details

  None (edit)
Description André Pinto 2007-11-18 09:35:52 EST
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
Comment 1 André Pinto 2007-11-18 09:35:52 EST
Created attachment 262931 [details]
The messages from the working and not working kernels
Comment 2 John W. Linville 2007-11-21 15:44:11 EST
Could you verify that this problem still occurs with the -62.fc8 kernels?  
Thanks!

http://koji.fedoraproject.org/koji/buildinfo?buildID=25030
Comment 3 André Pinto 2007-11-22 04:58:33 EST
Created attachment 266641 [details]
log of kernel -62.fc8
Comment 4 André Pinto 2007-11-22 05:02:14 EST
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.
Comment 5 John W. Linville 2007-11-26 15:12:31 EST
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?
Comment 6 Kevin Kofler 2007-12-09 06:53:07 EST
"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.
Comment 7 Kevin Kofler 2007-12-09 06:56:25 EST
Setting hardware to "All" because I'm seeing this on i686, the reporter on 
x86_64.
Comment 8 Kevin Kofler 2007-12-09 23:08:27 EST
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.
Comment 9 André Pinto 2007-12-10 08:55:46 EST
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.
Comment 10 John W. Linville 2007-12-10 12:12:49 EST
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.
Comment 11 Kevin Kofler 2007-12-10 12:22:06 EST
> 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).
Comment 12 John W. Linville 2007-12-10 12:43:11 EST
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!
Comment 13 Kevin Kofler 2007-12-10 16:53:26 EST
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.
Comment 14 John W. Linville 2007-12-11 09:28:38 EST
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?
Comment 15 Kevin Kofler 2007-12-14 02:56:25 EST
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.)
Comment 16 André Pinto 2007-12-14 08:37:09 EST
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... 
Comment 17 Kevin Kofler 2008-01-07 04:10:02 EST
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?
Comment 18 John W. Linville 2008-01-07 10:57:39 EST
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.
Comment 19 Ivo van Doorn 2008-01-07 13:48:57 EST
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... :(
Comment 20 André Pinto 2008-01-07 16:10:40 EST
I've got back my usb device and just FYI the problem still exists with the
newest kernel... Unusable device.
Comment 21 Ivo van Doorn 2008-01-09 16:40:45 EST
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.
Comment 22 Kevin Kofler 2008-01-11 01:21:14 EST
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).
Comment 23 Kevin Kofler 2008-02-10 12:01:12 EST
Still broken in kernel-2.6.23.14-115.fc8.
Comment 24 Kevin Kofler 2008-02-10 22:21:39 EST
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.
Comment 25 Kevin Kofler 2008-02-10 23:28:38 EST
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?
Comment 26 Ivo van Doorn 2008-02-11 13:19:52 EST
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.
Comment 27 Kevin Kofler 2008-03-17 20:54:50 EDT
kernel-2.6.24.3-34.fc8 still not working.
Comment 28 John W. Linville 2008-05-20 15:18:54 EDT
Is this still a problem with the latest f8 kernels?
Comment 29 André Pinto 2008-05-24 21:40:10 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.