Description of problem: wi-fi adapter based on Ralink RT2500 can not connect to network even if the encryption is off. Version-Release number of selected component (if applicable): uname -a Linux 2.6.25.6-55.fc9.i686 How reproducible: try to connect wi-fi network Actual results: /etc/init.d/network restart or /sbin/ifdown /sbin/ifup following record appears /var/log/messages kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready however iwlist wlan0 scan wlan0 Scan completed : Cell 01 - Address: 00:14:D1:3F:FB:7D ESSID:"dart" Mode:Master Channel:6 Frequency:2.437 GHz (Channel 6) Quality=53/100 Signal level:-39 dBm Encryption key:off 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=0000004c02615181 in case NetwokManager controls the device following records appear in /var/log/messages NetworkManager: <info> (wlan0): supplicant connection state change: 3 -> 0 NetworkManager: <info> (wlan0): supplicant connection state change: 0 -> 2 NetworkManager: <info> (wlan0): supplicant connection state change: 2 -> 3 NetworkManager: <info> Activation (wlan0/wireless): association took too long, failing activation. NetworkManager: <info> (wlan0): device state change: 5 -> 9 NetworkManager: <info> Activation (wlan0) failed for access point (dart) NetworkManager: <info> Marking connection 'dart' invalid. NetworkManager: <info> Activation (wlan0) failed. NetworkManager: <info> (wlan0): device state change: 9 -> 3 NetworkManager: <info> (wlan0): deactivating device. Expected results: Wi-Fi network connection Additional information: wi-fi worked on previous kernels
What is the last kernel which was working for you?
I just wanted to report the same bug. For me the last working kernel version is kernel-2.6.25.3-18.fc9.i686 My card is this one: 00:0a.0 Network controller: RaLink RT2561/RT61 rev B 802.11g Subsystem: D-Link System Inc DWL-G510 Rev C Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 32, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at dfff0000 (32-bit, non-prefetchable) [size=32K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: rt61pci Kernel modules: rt61pci If there is anything I can help to debug this, please say so.
(In reply to comment #1) > What is the last kernel which was working for you? kernel-2.6.25.3-18.fc9 was the last that seems to work :( I wounder is it a vanilla kernel problem or is it a result of RedHat patches?
kernel-2.6.25.9-76.fc9.i686 seems to be the first kernel, which works for me again.
I am using a "Linksys WUSB54GC 802.11g Adapter [ralink rt73]" and the reported problem occurs since update to kernel-2.6.25.9-76.fc9.i686 for me. kernel-2.6.25.6-55.fc9.i686 works like expected. It seems that the problem is somehow related to dhclient cause between the logentries of NetworkManager there are the following logentries from dhclient: Jul 3 19:36:53 localhost dhclient: Sending on Socket/fallback Jul 3 19:36:56 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4 Jul 3 19:37:00 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7 Jul 3 19:37:07 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8 Jul 3 19:37:15 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10 Jul 3 19:37:25 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 13 Jul 3 19:37:38 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 18 I could also observe that if i set manualy a ip with ifconfig while dhclient is trying to get a ip then i can succsesfull ping my router till dhclient times out. So the wpa encryption seems to work. If I boot the old kernel dhclient gets a ip.
I can confirm this is also the case with Fedora 8 and the 2.6.25.9-40.fc8 kernel (i386).
Same issue here. No kernel past kernel-2.6.25-14.fc9.i686 (default install kernel) works for me. Jul 12 13:06:55 localhost NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... Jul 12 13:06:55 localhost NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started... Jul 12 13:06:55 localhost NetworkManager: <info> (wlan0): device state change: 6 -> 4 Jul 12 13:06:55 localhost NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... Jul 12 13:06:55 localhost NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Jul 12 13:06:55 localhost NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Jul 12 13:06:55 localhost NetworkManager: <info> (wlan0): device state change: 4 -> 5 Jul 12 13:06:55 localhost NetworkManager: <info> Activation (wlan0/wireless): connection 'Auto wlan-ap' has security, and sec rets exist. No new secrets needed. Jul 12 13:06:55 localhost NetworkManager: <info> Config: added 'ssid' value 'wlan-ap' Jul 12 13:06:55 localhost NetworkManager: <info> Config: added 'scan_ssid' value '1' Jul 12 13:06:55 localhost NetworkManager: <info> Config: added 'key_mgmt' value 'WPA-PSK' Jul 12 13:06:55 localhost NetworkManager: <info> Config: added 'psk' value '<omitted>' Jul 12 13:06:55 localhost NetworkManager: <info> Config: added 'proto' value 'WPA RSN' Jul 12 13:06:55 localhost NetworkManager: <info> Config: added 'pairwise' value 'TKIP CCMP' Jul 12 13:06:55 localhost NetworkManager: <info> Config: added 'group' value 'WEP40 WEP104 TKIP CCMP' Jul 12 13:06:55 localhost NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete. Jul 12 13:06:55 localhost NetworkManager: <info> Config: set interface ap_scan to 1 Jul 12 13:06:55 localhost NetworkManager: <info> (wlan0): supplicant connection state change: 0 -> 2 Jul 12 13:06:56 localhost NetworkManager: <info> (wlan0): supplicant connection state change: 2 -> 3 Jul 12 13:07:16 localhost NetworkManager: <info> (wlan0): supplicant connection state change: 3 -> 0 Jul 12 13:07:16 localhost NetworkManager: <info> (wlan0): supplicant connection state change: 0 -> 2 Jul 12 13:07:17 localhost NetworkManager: <info> (wlan0): supplicant connection state change: 2 -> 3 Jul 12 13:07:20 localhost NetworkManager: <info> Activation (wlan0/wireless): association took too long. Jul 12 13:07:20 localhost NetworkManager: <info> (wlan0): device state change: 5 -> 6 Jul 12 13:07:20 localhost NetworkManager: <info> Activation (wlan0/wireless): asking for new secrets Jul 12 13:07:20 localhost NetworkManager: <info> (wlan0): supplicant connection state change: 3 -> 0 Jul 12 13:07:35 localhost NetworkManager: <info> wlan0: link timed out. Whether this is a result of my Billion router bugging out is unknown: Model Name BiPAC 7404VGO Host Name home.gateway System Up-Time 17 days, 0 hour Current Time Sat, 12 Jul 2008 - 13:47:58 Hardware Version Argon 432 ADSL-M/WG/VOS v1.00 Software Version 5.60a.dg8 Smolt info: http://www.smolts.org/client/show/pub_eb506a53-30c9-4f8b-ac9f-33c9532d7928
Tried again on WAG54G with the same results.
The same problem here, the last working is 2.6.25.3-18.fc9.x86_64, the last tested 2.6.25.10-91.fc9.x86_64. I'm also including regdumps, if it helps.
Created attachment 311665 [details] Dump from working kernel
Created attachment 311666 [details] Dump from the latest tested kernel - doesn't work
(In reply to comment #5) > I am using a "Linksys WUSB54GC 802.11g Adapter [ralink rt73]" and the reported > problem occurs since update to kernel-2.6.25.9-76.fc9.i686 for me. > kernel-2.6.25.6-55.fc9.i686 works like expected. It seems that the problem is > somehow related to dhclient cause between the logentries of NetworkManager there > are the following logentries from dhclient: > > Jul 3 19:36:53 localhost dhclient: Sending on Socket/fallback > Jul 3 19:36:56 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 > port 67 interval 4 > Jul 3 19:37:00 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 > port 67 interval 7 > Jul 3 19:37:07 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 > port 67 interval 8 > Jul 3 19:37:15 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 > port 67 interval 10 > Jul 3 19:37:25 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 > port 67 interval 13 > Jul 3 19:37:38 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 > port 67 interval 18 > > I could also observe that if i set manualy a ip with ifconfig while dhclient is > trying to get a ip then i can succsesfull ping my router till dhclient times > out. So the wpa encryption seems to work. > > If I boot the old kernel dhclient gets a ip. 2.6.25.10-86.fc9.i686 resolved this issue and wlan works again.
I installed kernel 2.6.25.11-93.fc9.i686 yesterday and I am still having problems. It detects the network, tries to connect, but it does not managed to (keeps asking for network key). The only kernel that works for me is 2.6.25.3-18.fc9.i686
John, this issue should be fixed by wireless-testing commit: 3da0ce9de317f8d685389ee80b6a8c3039d96055 rt2500pci: restoring missing line
I found great solution! Switch to Ubuntu does the trick! Seems Red Boss or JHAT doesn't care about it's users at all. Have fun!
Same results with 2.6.25.14-108.fc9.i686.
(In reply to comment #15) [silliness] Very helpful.
Yes, the patch from comment 14 is still not in there. There seems to have been a hiccup in the handover of merging upstream wireless fixes into the Fedora kernels. As for [silliness], well said! :-)
New install of Fedora 9, using "RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01)". Ran yum update. 2.6.25.14-108.fc9.i686 works as expected, albeit only at 1mbit/s. 2.6.25-14.fc9.i686 does not connect to wireless network.
*correction 2.6.25-14.fc9.i686 works as expected, albeit only at 1mbit/s. 2.6.25.14-108.fc9.i686 does not connect to wireless network.
What is the latest kernel you have tried? I don't believe the patch in comment 14 was in -108.
*** This bug has been marked as a duplicate of bug 451422 ***