Bug 457441

Summary: Wifi connection problem with rt2500pci.
Product: [Fedora] Fedora Reporter: Florent Le Coz <louizatakk>
Component: kernelAssignee: John W. Linville <linville>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 12CC: brentrbrian, bugzilla, covex, cpanceac, ibmalone, ivdoorn, jan.skarvall, jan, juhani.jaakola, kernel-maint, kmcmartin, linville, miroslav.slunecko, misek, urilabob
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-06-08 13:35:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
messages and dmesg from Fedora 10 Live CD (gzipped tar file)
none
wireshark dump from mon0
none
2_6_25_6_55_fc9.txt
none
2_6_25_14_fc9.txt
none
F10 wireshark dump, watching rt2500pci F11 (rawhide)
none
F11 (rawhide) register dump of rt2500pci
none
F11 (rawhide) debugfs frame dump rt2500pci (using rt2x00_framedump)
none
Wireshark on another laptop watching this connection
none
Wireshark on RT2500 machine
none
/var/log/messages at time of wireshark dumps none

Description Florent Le Coz 2008-07-31 17:44:06 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.1) Gecko/2008071615 Fedora/3.0.1-1.fc9 Firefox/3.0.1

Description of problem:
When trying to connect to my router with my laptop, with a rt2500pci based card, it correctly scans, but when trying to connect to my router (no protection at all (no WEP or WPA)), it times-out on "Trying to join the wireless network" (this is approximately translated from the french "tentative de rejoindre le réseau sans-fil") from the Network-Manager applet. (the first "ball" becomes green but the second doesn't) and I can't connect...
It works with the kernel-2.6.25-14.fc9.x86_64

Version-Release number of selected component (if applicable):
kernel-2.6.25.11-97.fc9.x86_64

How reproducible:
Always


Steps to Reproduce:
1. With a rt2500pci based card, try to connect on a wireless network
2. Fail 


Actual Results:
You're not connected.

Expected Results:
You should be connected to the wireless network

Additional info:
Comment 1 John W. Linville 2008-07-31 18:40:04 UTC 
There is an upstream patch that I believe addresses this.  I'll try go get a 
build in the next few days.
Comment 2 Florent Le Coz 2008-08-08 17:05:27 UTC 
Information:

The kernel 2.6.25.14-108 in the testing repos doesn't change anything
Comment 3 John W. Linville 2008-08-12 15:41:48 UTC 
Not surprising, as it doesn't contain the patch in question... :-)
Comment 4 Florent Le Coz 2008-08-13 13:02:00 UTC 
Ok, good news.
I was worried because it contains fixes for the rt2500 driver, but I didn't know if they were supposed to fixe this bug or not.
Now I know I just have to wait. :-)
Comment 5 Juhani Jaakola 2008-10-19 08:42:22 UTC 
I have the same problem with kernel-2.6.26.5-45.fc9.i686 - I can see in /var/log/messages several DHCPDISCOVER messages but finally I get "dhclient: No DHCPOFFERS received."

It works with kernel-2.6.25-14.fc9.i686
Comment 6 Juhani Jaakola 2008-12-10 11:53:13 UTC 
Created attachment 326494 [details]
messages and dmesg from Fedora 10 Live CD (gzipped tar file)

The Fedora 10 Live CD has the same problem on the same PC as in comment #5. dmesg shows "disassociating by local choice (reason=3)".

/var/log/messages shows several DHCPDISCOVER messages but finally I get "NetworkManager: <info>  Device 'wlan0' DHCP transaction took too long (>45s), stopping it."

lspci -v shows this about the device:

00:0a.0 Network controller: RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01)
	Subsystem: CNet Technology Inc CWP-854 Wireless-G PCI Adapter
	Flags: bus master, slow devsel, latency 32, IRQ 17
	Memory at febf8000 (32-bit, non-prefetchable) [size=8K]
	Capabilities: [40] Power Management version 2
	Kernel driver in use: rt2500pci
	Kernel modules: rt2500pci

The network that I'm trying to join is an open network.
Comment 7 Juhani Jaakola 2008-12-11 15:49:30 UTC 
Kernel 2.6.27.7-53.fc9.i686 has the same problem.
Comment 8 Jan Willies 2008-12-14 17:33:51 UTC 
"Bug 473804 -  rt2500pci doesn't get an IP via DHCP" is a duplicate of this, so I'm closing #473804 and merge the information here (:

Description of problem: My rt2500pci card doesn't get an IP via DHCP. It
authenticates fine with the AP (via WPA2) but dhclient times out. Setting the
IP manually via NM works fine.

Nov 30 20:01:53 elke NetworkManager: <info>  (wlan0): supplicant connection
state:  associating -> associated
Nov 30 20:01:53 elke NetworkManager: <info>  (wlan0): supplicant connection
state:  associated -> 4-way handshake
Nov 30 20:01:53 elke NetworkManager: <info>  (wlan0): supplicant connection
state:  4-way handshake -> group handshake
Nov 30 20:01:53 elke NetworkManager: <info>  (wlan0): supplicant connection
state:  group handshake -> completed
Nov 30 20:01:53 elke NetworkManager: <info>  Activation (wlan0/wireless) Stage
2 of 5 (Device Configure) successful.  Connected to wireless network
'schnauze'.
Nov 30 20:01:53 elke NetworkManager: <info>  Activation (wlan0) Stage 3 of 5
(IP Configure Start) scheduled.
Nov 30 20:01:53 elke NetworkManager: <info>  Activation (wlan0) Stage 3 of 5
(IP Configure Start) started...
Nov 30 20:01:53 elke NetworkManager: <info>  (wlan0): device state change: 5 ->
7
Nov 30 20:01:53 elke NetworkManager: <info>  Activation (wlan0) Beginning DHCP
transaction.
Nov 30 20:01:53 elke dhclient: Internet Systems Consortium DHCP Client 4.0.0
Nov 30 20:01:53 elke dhclient: Copyright 2004-2007 Internet Systems Consortium.
Nov 30 20:01:53 elke dhclient: All rights reserved.
Nov 30 20:01:53 elke dhclient: For info, please visit
http://www.isc.org/sw/dhcp/
Nov 30 20:01:53 elke dhclient: 
Nov 30 20:01:53 elke NetworkManager: <info>  dhclient started with pid 4320
Nov 30 20:01:53 elke NetworkManager: <info>  Activation (wlan0) Stage 3 of 5
(IP Configure Start) complete.
Nov 30 20:01:53 elke NetworkManager: <info>  DHCP: device wlan0 state changed
normal exit -> preinit
Nov 30 20:01:53 elke dhclient: Listening on LPF/wlan0/00:11:09:be:de:4f
Nov 30 20:01:53 elke dhclient: Sending on   LPF/wlan0/00:11:09:be:de:4f
Nov 30 20:01:53 elke dhclient: Sending on   Socket/fallback
Nov 30 20:01:53 elke ntpd[1884]: Deleting interface #7 wlan0,
192.168.2.206#123, interface stats: received=3, sent=3, dropped=0,
active_time=87 secs
Nov 30 20:01:57 elke dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67
interval 4
Nov 30 20:02:01 elke dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67
interval 7
Nov 30 20:02:08 elke dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67
interval 8
Nov 30 20:02:16 elke dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67
interval 11
Nov 30 20:02:27 elke dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67
interval 15
Nov 30 20:02:38 elke NetworkManager: <info>  Device 'wlan0' DHCP transaction
took too long (>45s), stopping it.
Nov 30 20:02:38 elke NetworkManager: <info>  wlan0: canceled DHCP transaction,
dhcp client pid 4320
Nov 30 20:02:38 elke NetworkManager: <info>  Activation (wlan0) Stage 4 of 5
(IP Configure Timeout) scheduled...
Nov 30 20:02:38 elke NetworkManager: <info>  Activation (wlan0) Stage 4 of 5
(IP Configure Timeout) started...
Nov 30 20:02:38 elke NetworkManager: <info>  (wlan0): device state change: 7 ->
9
Nov 30 20:02:38 elke NetworkManager: <info>  Activation (wlan0) failed for
access point (schnauze)
Nov 30 20:02:38 elke NetworkManager: <info>  Marking connection 'Auto schnauze'
invalid.
Nov 30 20:02:38 elke NetworkManager: <info>  Activation (wlan0) failed.
Nov 30 20:02:38 elke NetworkManager: <info>  Activation (wlan0) Stage 4 of 5
(IP Configure Timeout) complete.
Nov 30 20:02:38 elke NetworkManager: <info>  (wlan0): device state change: 9 ->
3
Nov 30 20:02:38 elke NetworkManager: <info>  (wlan0): deactivating device
(reason: 0).
Nov 30 20:02:38 elke NetworkManager: <info>  Policy set 'System eth0' (eth0) as
default for routing and DNS.


Version-Release number of selected component (if applicable): NM in Fedora 10


How reproducible: always


Steps to Reproduce:
1. connect to a Network with rt2500pci
2. wait
3. see how it doesn't get an IP

Actual results: dhclient running into a timeout


Expected results: get the DHCP infos

Additional info: my other laptop gets the IP just fine
Comment 9 Jan Willies 2008-12-14 17:37:42 UTC 
*** Bug 473804 has been marked as a duplicate of this bug. ***
Comment 10 Brent R Brian 2008-12-28 13:33:28 UTC 
/var/log/messages contained:

17:48:01 kernel: pccard: CardBus card inserted into slot 0
17:48:01 kernel: rt2500pci 0000:02:00.0: enabling device (0000 -> 0002)
17:48:01 kernel: Registered led device: rt2500pci-phy1:radio
17:48:03 NetworkManager: <info>  wlan0: driver is 'rt2500pci'.
17:48:03 NetworkManager: <info>  wlan0: driver supports SSID scans (scan_capa
0x01).
17:48:03 NetworkManager: <info>  Found new 802.11 WiFi device 'wlan0'.
17:48:03 NetworkManager: <info>  (wlan0): exported as
/org/freedesktop/Hal/devices/net_00_13_d4_6f_13_f4_0
17:48:07 NetworkManager: <info>  (wlan0): device state change: 1 -> 2
17:48:07 NetworkManager: <info>  (wlan0): bringing up device.
17:48:07 kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready
17:48:07 NetworkManager: <info>  (wlan0): preparing device.
17:48:07 NetworkManager: <info>  (wlan0): deactivating device (reason: 2).
17:48:07 NetworkManager: <info>  (wlan0): device state change: 2 -> 3
17:48:07 NetworkManager: <info>  (wlan0): supplicant interface state:  starting
-> ready
17:48:07 NetworkManager: <info>  Activation (wlan0) starting connection 'Auto
BMGEN'
17:48:07 NetworkManager: <info>  (wlan0): device state change: 3 -> 4
17:48:07 NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device
Prepare) scheduled...
17:48:07 NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device
Prepare) started...
17:48:07 NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device
Configure) scheduled...
17:48:07 NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device
Prepare) complete.
17:48:07 NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device
Configure) starting...
17:48:07 NetworkManager: <info>  (wlan0): device state change: 4 -> 5
17:48:07 NetworkManager: <info>  Activation (wlan0/wireless): access point
'Auto BMGEN' has security, but secrets are required.
17:48:07 NetworkManager: <info>  (wlan0): device state change: 5 -> 6
17:48:07 NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device
Configure) complete.
17:48:12 NetworkManager: <info>  (wlan0): supplicant connection state: 
scanning -> inactive
17:48:27 NetworkManager: <info>  (wlan0): supplicant connection state: 
inactive -> scanning
17:48:32 NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device
Prepare) scheduled...
17:48:32 NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device
Prepare) started...
17:48:32 NetworkManager: <info>  (wlan0): device state change: 6 -> 4
17:48:32 NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device
Configure) scheduled...
17:48:32 NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device
Prepare) complete.
17:48:32 NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device
Configure) starting...
17:48:32 NetworkManager: <info>  (wlan0): device state change: 4 -> 5
17:48:32 NetworkManager: <info>  Activation (wlan0/wireless): connection 'Auto
BMGEN' has security, and secrets exist.  No new secrets needed.
17:48:32 NetworkManager: <info>  Config: added 'ssid' value 'BMGEN'
17:48:32 NetworkManager: <info>  Config: added 'scan_ssid' value '1'
17:48:32 NetworkManager: <info>  Config: added 'key_mgmt' value 'NONE'
17:48:32 NetworkManager: <info>  Config: added 'auth_alg' value 'OPEN'
17:48:32 NetworkManager: <info>  Config: added 'wep_key0' value '<omitted>'
17:48:32 NetworkManager: <info>  Config: added 'wep_tx_keyidx' value '0'
17:48:32 NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device
Configure) complete.
17:48:32 NetworkManager: <info>  Config: set interface ap_scan to 1
17:48:32 NetworkManager: <info>  (wlan0): supplicant connection state: 
scanning -> disconnected
17:48:33 NetworkManager: <info>  (wlan0): supplicant connection state: 
disconnected -> scanning
17:48:33 NetworkManager: <info>  (wlan0): supplicant connection state: 
scanning -> associating
17:48:47 NetworkManager: <info>  wlan0: link timed out.
17:48:53 NetworkManager: <info>  (wlan0): supplicant connection state: 
associating -> disconnected
17:48:53 NetworkManager: <info>  (wlan0): supplicant connection state: 
disconnected -> scanning
17:48:54 NetworkManager: <info>  (wlan0): supplicant connection state: 
scanning -> associating
17:48:57 NetworkManager: <info>  Activation (wlan0/wireless): association took
too long.
17:48:57 NetworkManager: <info>  (wlan0): device state change: 5 -> 9
17:48:57 NetworkManager: <info>  Activation (wlan0) failed for access point
(BMGEN)
17:48:57 NetworkManager: <info>  Marking connection 'Auto BMGEN' invalid.
17:48:57 NetworkManager: <info>  Activation (wlan0) failed.
17:48:57 NetworkManager: <info>  (wlan0): device state change: 9 -> 3
17:48:57 NetworkManager: <info>  (wlan0): deactivating device (reason: 0).
17:49:43 NetworkManager: <info>  Activation (wlan0) starting connection 'Auto
BMGEN'
17:49:43 NetworkManager: <info>  (wlan0): device state change: 3 -> 4
17:49:43 NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device
Prepare) scheduled...
17:49:43 NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device
Prepare) started...
17:49:43 NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device
Configure) scheduled...
17:49:43 NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device
Prepare) complete.
17:49:43 NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device
Configure) starting...
17:49:43 NetworkManager: <info>  (wlan0): device state change: 4 -> 5
17:49:43 NetworkManager: <info>  Activation (wlan0/wireless): access point
'Auto BMGEN' has security, but secrets are required.
17:49:43 NetworkManager: <info>  (wlan0): device state change: 5 -> 6
17:49:43 NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device
Configure) complete.
17:49:43 NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device
Prepare) scheduled...
17:49:43 NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device
Prepare) started...
17:49:43 NetworkManager: <info>  (wlan0): device state change: 6 -> 4
17:49:43 NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device
Configure) scheduled...
17:49:43 NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device
Prepare) complete.
17:49:43 NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device
Configure) starting...
17:49:43 NetworkManager: <info>  (wlan0): device state change: 4 -> 5
17:49:43 NetworkManager: <info>  Activation (wlan0/wireless): connection 'Auto
BMGEN' has security, and secrets exist.  No new secrets needed.
17:49:43 NetworkManager: <info>  Config: added 'ssid' value 'BMGEN'
17:49:43 NetworkManager: <info>  Config: added 'scan_ssid' value '1'
17:49:43 NetworkManager: <info>  Config: added 'key_mgmt' value 'NONE'
17:49:43 NetworkManager: <info>  Config: added 'auth_alg' value 'OPEN'
17:49:43 NetworkManager: <info>  Config: added 'wep_key0' value '<omitted>'
17:49:43 NetworkManager: <info>  Config: added 'wep_tx_keyidx' value '0'
17:49:43 NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device
Configure) complete.
17:49:43 NetworkManager: <info>  Config: set interface ap_scan to 1
17:49:43 NetworkManager: <info>  (wlan0): supplicant connection state: 
disconnected -> scanning
17:49:44 NetworkManager: <info>  (wlan0): supplicant connection state: 
scanning -> associating
17:50:04 NetworkManager: <info>  (wlan0): supplicant connection state: 
associating -> disconnected
17:50:04 NetworkManager: <info>  (wlan0): supplicant connection state: 
disconnected -> scanning
17:50:05 NetworkManager: <info>  (wlan0): supplicant connection state: 
scanning -> associating
17:50:08 NetworkManager: <info>  Activation (wlan0/wireless): association took
too long.
17:50:08 NetworkManager: <info>  (wlan0): device state change: 5 -> 6
17:50:08 NetworkManager: <info>  Activation (wlan0/wireless): asking for new
secrets
17:50:08 NetworkManager: <info>  (wlan0): supplicant connection state: 
associating -> disconnected
17:50:23 NetworkManager: <info>  wlan0: link timed out.
17:50:26 dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6
17:50:26 dhclient: send_packet: No such device or address
17:50:27 NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device
Prepare) scheduled...
17:50:27 NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device
Prepare) started...
17:50:27 NetworkManager: <info>  (wlan0): device state change: 6 -> 4
17:50:27 NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device
Configure) scheduled...
17:50:27 NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device
Prepare) complete.
17:50:27 NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device
Configure) starting...
17:50:27 NetworkManager: <info>  (wlan0): device state change: 4 -> 5
17:50:27 NetworkManager: <info>  Activation (wlan0/wireless): connection 'Auto
BMGEN' has security, and secrets exist.  No new secrets needed.
17:50:27 NetworkManager: <info>  Config: added 'ssid' value 'BMGEN'
17:50:27 NetworkManager: <info>  Config: added 'scan_ssid' value '1'
17:50:27 NetworkManager: <info>  Config: added 'key_mgmt' value 'NONE'
17:50:27 NetworkManager: <info>  Config: added 'auth_alg' value 'OPEN'
17:50:27 NetworkManager: <info>  Config: added 'wep_key0' value '<omitted>'
17:50:27 NetworkManager: <info>  Config: added 'wep_tx_keyidx' value '0'
17:50:27 NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device
Configure) complete.
17:50:27 NetworkManager: <info>  Config: set interface ap_scan to 1
17:50:27 NetworkManager: <info>  (wlan0): supplicant connection state: 
disconnected -> scanning
17:50:28 NetworkManager: <info>  (wlan0): supplicant connection state: 
scanning -> associating
17:50:32 dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14
17:50:32 dhclient: send_packet: No such device or address
17:50:46 dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
17:50:46 dhclient: send_packet: No such device or address
17:50:48 NetworkManager: <info>  (wlan0): supplicant connection state: 
associating -> disconnected
17:50:48 NetworkManager: <info>  (wlan0): supplicant connection state: 
disconnected -> scanning
17:50:49 NetworkManager: <info>  (wlan0): supplicant connection state: 
scanning -> associating
17:50:52 NetworkManager: <info>  Activation (wlan0/wireless): association took
too long.
17:50:52 NetworkManager: <info>  (wlan0): device state change: 5 -> 6
17:50:52 NetworkManager: <info>  Activation (wlan0/wireless): asking for new
secrets
17:50:52 NetworkManager: <info>  (wlan0): supplicant connection state: 
associating -> disconnected
17:50:57 dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 18
17:50:57 dhclient: send_packet: No such device or address
17:50:57 NetworkManager: <info>  (wlan0): supplicant connection state: 
disconnected -> scanning
17:51:07 NetworkManager: <info>  wlan0: link timed out.
17:51:09 NetworkManager: <info>  (wlan0): supplicant connection state: 
scanning -> disconnected
17:51:15 dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 12
17:51:15 dhclient: send_packet: No such device or address
17:51:24 NetworkManager: <info>  wlan0: link timed out.
17:51:27 dhclient: No DHCPOFFERS received.
17:51:27 dhclient: No working leases in persistent database - sleeping.
17:52:27 NetworkManager: <info>  (wlan0): supplicant connection state: 
disconnected -> scanning
Comment 11 John W. Linville 2009-01-21 20:27:43 UTC 
What is the latest kernel you have tried?  Are you still using Fedora 9?  Or have you moved to Fedora 10?
Comment 12 Jan Willies 2009-01-21 20:50:58 UTC 
Yes, my comment #8 is with F10. I see there is 2.6.28 in koji but unfortunately I don't have the laptop here until the end of februar.
Comment 13 Brent R Brian 2009-01-22 02:03:11 UTC 
Give me update info for koji and I will update to that kernel and try it ....
Comment 14 Brent R Brian 2009-01-22 02:04:34 UTC 
Is there even a fix in 2.6.28 for this bug ?
Comment 15 Jan Willies 2009-01-22 08:01:27 UTC 
install
http://kojipkgs.fedoraproject.org/packages/kernel/2.6.28.1/19.fc10/noarch/kernel-firmware-2.6.28.1-19.fc10.noarch.rpm
and then
http://kojipkgs.fedoraproject.org/packages/kernel/2.6.28.1/19.fc10/i686/kernel-2.6.28.1-19.fc10.i686.rpm
Comment 16 Florent Le Coz 2009-01-22 21:33:19 UTC 
I can't test these packages, because I can't boot with this kernel.

(see https://bugzilla.redhat.com/show_bug.cgi?id=481228)
Comment 17 Brent R Brian 2009-01-23 03:07:50 UTC 
Loaded kernel and kernel-firmware from kojipkgs, rebooted.

Asus WL-107G (rt2500pci), no good, won't authenticate.
TP-Link TL-WN310G, works fine, same authentication settings.
D-Link DWL-G650, works fine, same authentication settings.

One thing that seemed odd, lsmod shows:

rt2500pci              18688  0 
rt2x00pci              10112  1 rt2500pci
rt2x00lib              36224  2 rt2500pci,rt2x00pci
mac80211              174568  3 ath5k,rt2x00pci,rt2x00lib
eeprom_93cx6            5888  1 rt2500pci

I guess the rt2500pci is linking to code from the rt2x00pci module ...

Andy tests you would like me to run ?
Comment 18 John W. Linville 2009-01-23 14:51:28 UTC 
The lsmod seems fine -- the rt2x00 drivers are modular and share lots of code.

I'll copy Ivo (the rt2x00 maintainer) in case he has some insight.
Comment 19 Ivo van Doorn 2009-01-23 16:53:43 UTC 
Could you enable debugfs and use the script http://kernel.org/pub/linux/kernel/people/ivd/tools/rt2x00_regdump.sh
when using the last working kernel and a broken kernel (preferably the first known broken version)?

John: Is there an easy way to see what rt2x00 patches went in the FC kernel between kernel-2.6.25-14.fc9.x86_64 and kernel-2.6.25.11-97.fc9.x86_64?
Comment 20 John W. Linville 2009-02-13 20:34:03 UTC 
Ugh, that would be very difficult now.  My guess would be that would closely correspond to the patches that went upstream between 2.6.25 and 2.6.26.  Does that help at all?
Comment 21 Brent R Brian 2009-02-14 04:07:51 UTC 
What is the output of 'lspci -v' with
the device plugged-in to one of the boxes in question?

uname -a 2.6.28.1-19.fc10.i686 #1 SMP

00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 02)
	Flags: bus master, medium devsel, latency 64
	Memory at 40000000 (32-bit, prefetchable) [size=64M]
	Capabilities: [a0] AGP version 1.0
	Kernel driver in use: agpgart-intel

00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 02) (prog-if 00 [Normal decode])
	Flags: bus master, 66MHz, medium devsel, latency 168
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=176
	I/O behind bridge: 0000d000-0000dfff
	Memory behind bridge: 70000000-dfffffff
	Prefetchable memory behind bridge: e0000000-f7ffffff

00:02.0 CardBus bridge: Texas Instruments PCI1251A
	Subsystem: IBM Device 00eb
	Flags: bus master, medium devsel, latency 168, IRQ 11
	Memory at 50102000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
	Memory window 0: 20000000-23fff000 (prefetchable)
	Memory window 1: 24000000-27fff000
	I/O window 0: 00001000-000010ff
	I/O window 1: 00001400-000014ff
	16-bit legacy interface ports at 0001
	Kernel driver in use: yenta_cardbus
	Kernel modules: yenta_socket

00:02.1 CardBus bridge: Texas Instruments PCI1251A
	Subsystem: IBM Device 00eb
	Flags: bus master, medium devsel, latency 168, IRQ 11
	Memory at 50101000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=06, subordinate=09, sec-latency=176
	Memory window 0: 28000000-2bfff000 (prefetchable)
	Memory window 1: 2c000000-2ffff000
	I/O window 0: 00001800-000018ff
	I/O window 1: 00001c00-00001cff
	16-bit legacy interface ports at 0001
	Kernel driver in use: yenta_cardbus
	Kernel modules: yenta_socket

00:06.0 Multimedia audio controller: Cirrus Logic CS 4610/11 [CrystalClear SoundFusion Audio Accelerator] (rev 01)
	Subsystem: IBM CS4610 SoundFusion Audio Accelerator
	Flags: medium devsel, IRQ 11
	Memory at 50100000 (32-bit, non-prefetchable) [size=4K]
	Memory at 50000000 (32-bit, non-prefetchable) [size=1M]
	Kernel modules: snd-cs46xx

00:07.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02)
	Flags: bus master, medium devsel, latency 0

00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80 [Master])
	Flags: bus master, medium devsel, latency 48
	[virtual] Memory at 000001f0 (32-bit, non-prefetchable) [disabled] [size=8]
	[virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] [size=1]
	[virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] [size=8]
	[virtual] Memory at 00000370 (type 3, non-prefetchable) [disabled] [size=1]
	I/O ports at fcf0 [size=16]
	Kernel driver in use: ata_piix

00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 00 [UHCI])
	Flags: bus master, medium devsel, latency 48, IRQ 11
	I/O ports at 8400 [size=32]
	Kernel driver in use: uhci_hcd

00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02)
	Flags: medium devsel, IRQ 9
	Kernel modules: i2c-piix4

01:00.0 VGA compatible controller: Neomagic Corporation NM2200 [MagicGraph 256AV] (rev 12) (prog-if 00 [VGA controller])
	Subsystem: IBM ThinkPad 570
	Flags: bus master, medium devsel, latency 128, IRQ 11
	Memory at e0000000 (32-bit, prefetchable) [size=16M]
	Memory at 70000000 (32-bit, non-prefetchable) [size=4M]
	Memory at 70400000 (32-bit, non-prefetchable) [size=1M]
	Capabilities: [dc] Power Management version 1
	Kernel modules: neofb

02:00.0 Network controller: RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01)
	Subsystem: ASUSTeK Computer Inc. Device 107f
	Flags: bus master, slow devsel, latency 64, IRQ 11
	Memory at 24000000 (32-bit, non-prefetchable) [size=8K]
	Capabilities: [40] Power Management version 2
	Kernel driver in use: rt2500pci
	Kernel modules: rt2500pci
Comment 22 Brent R Brian 2009-02-14 04:13:41 UTC 
Created attachment 331896 [details]
wireshark dump from mon0
Comment 23 Ivo van Doorn 2009-02-14 14:09:31 UTC 
(In reply to comment #20)
> Ugh, that would be very difficult now.  My guess would be that would closely
> correspond to the patches that went upstream between 2.6.25 and 2.6.26.  Does
> that help at all?

Slightly, that would still be a very large amount of patches. ;)

Well I am going to find if I have any rt2500pci device somewhere, so I can run some tests myself as well.

In any case, I think that register dumps comparisons will have to do be sufficient for tracking this issue down.
Comment 24 Brent R Brian 2009-02-14 15:02:51 UTC 
OK, F9, we have a winner ..

kernel-2.6.25-14.fc9.i686     last released that works (F9 install ISO)
kernel-2.6.25.6-55.fc9.i686   first released that breaks 12-MAY-2008

I only checked the koji kernel rpms with the tag == dist-f9-update "green-check" icon, I tried a few others and quickly found out why the "trash can" icon was next to them ... OOPS ....

A point to note:

  * driver loads
  * activity led blinking
  * card finds the surrounding routers and lists them
  * credentials are provided
  * activity led blinking (only on working kernel)
  * successful link (only on working kernel)

It not a "corruption of configuration", I can boot back and forth between the two kernels above repeatedly and the results are the same.

I will leave the last working and first broken on the machine ... let me know what you need.
Comment 25 Ivo van Doorn 2009-02-14 15:41:27 UTC 
Excellent!
Could you make a register dump with above mentioned script to get a dump of both kernels?
thanks
Comment 26 Jan Skarvall 2009-02-14 16:19:18 UTC 
(In reply to comment #25)
> Excellent!
> Could you make a register dump with above mentioned script to get a dump of
> both kernels?
> thanks

Maybe my (not Brian) register dumps found at
http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=5&t=5184 could be of some
help. If you need something else, maybe I can be of some help.
Comment 27 Ivo van Doorn 2009-02-14 16:30:38 UTC 
The problem with those dumps is that it compares 2.6.25 with 2.6.28,
and I need something which is far more closer to eachother since the amount of rt2x00 differences between 2.6.25 and 2.6.28 is simply too big for me to handle.
Comment 28 Brent R Brian 2009-02-14 17:07:19 UTC 
Created attachment 331930 [details]
2_6_25_6_55_fc9.txt
Comment 29 Brent R Brian 2009-02-14 17:07:49 UTC 
Created attachment 331931 [details]
2_6_25_14_fc9.txt
Comment 30 Brent R Brian 2009-02-14 17:22:46 UTC 
*** Bug 473432 has been marked as a duplicate of this bug. ***
Comment 31 Brent R Brian 2009-02-14 17:42:18 UTC 
** this fix appears to be between the F9 ISO and the broken kernel **

https://bugzilla.redhat.com/show_bug.cgi?id=443203
Comment 32 Ivo van Doorn 2009-02-14 18:38:26 UTC 
Hmm, I have checked all rt2x00 patches between the 2 kernels, and I did discover the bug. Unfortunately that bug was already fixed in July 2008.
This seems to have messed up the best way to track this issue, since we have overlapping bugs.

I am going to recheck all register dumps (even with the more recent kernels Jan provided) and see if I have a rt2500pci device somewhere so I can do some experiments.
Comment 33 Brent R Brian 2009-02-14 18:48:40 UTC 
I have 3 laptops (F7, F9 F10 and I can have rawhide running in a few hours) and two rt2500pci cards ... what can I help you do ?
Comment 34 Ivo van Doorn 2009-02-14 19:06:38 UTC 
Using the latest kernel (should be rt2x00 2.2.x or 2.3.0)
please try to check the following things:
- Run wireshark on the second laptop, and check if rt2500pci is transmitting any frames
- Use http://kernel.org/pub/linux/kernel/people/ivd/tools/rt2x00_framedump.tar.bz2 and run it on the first laptop while attempting to make rt2500pci associate to an AP. Save the output into a text file, it will contain _all_ frames send and received by the hardware including all hardware descriptor information.

Thanks!
Comment 35 Ian Malone 2009-02-27 13:45:06 UTC 
I appear to have this bug (rt2500, does not get DHCP under F10, does on F9 live cd).

I do not have two rt2500, so from the instructions above I guess run wireshark on the computer without the rt2500 (while associated) and do the framedump while associating on the machine with rt2500.

Some observations:
ifconfig while network manager is trying to connect shows packets being sent and received (fewer received)
using static ip and DNS works okay.
Comment 36 John W. Linville 2009-02-27 19:00:40 UTC 
dhclient is prone to taking the link down and back up in short order.  Maybe something in the rt2500pci driver doesn't like that...?
Comment 37 Brent R Brian 2009-02-27 21:23:49 UTC 
Created attachment 333539 [details]
F10 wireshark dump, watching rt2500pci F11 (rawhide)
Comment 38 Brent R Brian 2009-02-27 21:24:38 UTC 
Created attachment 333540 [details]
F11 (rawhide) register dump of rt2500pci
Comment 39 Brent R Brian 2009-02-27 21:26:23 UTC 
Created attachment 333541 [details]
F11 (rawhide) debugfs frame dump rt2500pci (using rt2x00_framedump)
Comment 40 Brent R Brian 2009-02-27 21:34:47 UTC 
Test setup:

F10 running wireshark with ath5k pcmcia wireless card

F11 running rt2500 pcmcia, frame dump tool and register dump tool

Activate the rt2500pci card in the presents of a wireless router and record the over-the-air activity with wireshark (F10,ath5k) and the rt2x00_framedump utility.

(data attached #333539,333540,333541)
Comment 41 Mace Moneta 2009-04-08 09:02:45 UTC 
Having the problem with F11 rawhide, kernel 2.6.29.1-52.fc11.i586.  DCHP can't
get an address, manual ip configuration works.
Comment 42 Juhani Jaakola 2009-04-24 23:04:00 UTC 
I tried Fedora 11 Snap1 Live CD with kernel 2.6.29.1-54.fc11.i586 on a ThinkPad
600E and I have the same problem. I have WL-107g card. I can see the name of my
network in NetworkManager but connection always fails. WL-107g works with
Fedora 7. If I unplug the WL-107g card and try with XyZEL AG-220 then I can
connect to the network. The network does not have any encryption.

I have had similar problems with a rt2500 PCI card on a desktop machine as
well.
Comment 43 John W. Linville 2009-04-27 15:27:39 UTC 
*** Bug 497304 has been marked as a duplicate of this bug. ***
Comment 44 John W. Linville 2009-04-28 17:32:23 UTC 
Ivo, we still get a lot of reports of problems with this driver.  Is there more information the users can provide to illuminate this problem?
Comment 45 Ivo van Doorn 2009-04-28 18:22:57 UTC 
I'm sorry I know a lot of people are complaining about this, but I am having a hard time getting rt2800pci/usb to work as well. So I haven't looked at this issue recently.
Comment 46 Juhani Jaakola 2009-04-28 19:17:40 UTC 
The same problem exists with Fedora 11 Preview i686 Live CD (kernel 2.6.29.1-102.fc11.i586) on ThinkPad 600E. In /var/log/messages I can see 3..5 DHCPDISCOVER messages and then error "NetworkManager: <info>  Device 'wlan0' DHCP transaction took too long (>45s), stopping it".

The problem is with DHCP. If I set the address manually "ifconfig wlan0 192.168.1.45" while NetworkManager is trying to establish a connection, I was able to send the logs with scp to another machine! For some reason the DHCP does not work. There is no DHCPOFFER in /var/log/messages.

lspci -v shows for my WL-107g card:

02:00.0 Network controller: RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01)
	Subsystem: ASUSTeK Computer Inc. Device 107f
	Flags: bus master, slow devsel, latency 64, IRQ 11
	Memory at 24000000 (32-bit, non-prefetchable) [size=8K]
	Capabilities: [40] Power Management version 2
	Kernel driver in use: rt2500pci
	Kernel modules: rt2500pci
Comment 47 Juhani Jaakola 2009-04-29 10:23:32 UTC 
I continued my tests with Fedora 11 Preview i686 Live CD (kernel
2.6.29.1-102.fc11.i586) on ThinkPad 600E and WL-107G PCMCIA card. This time I sniffered the WLAN with wireshark on another laptop.

I could not see any DHCP Discover packets with Wireshark when I tried the WL-107G card. But when I used ZyXEL AG-220 on the ThinkPad 600E I could see DHCP Discover and DHCP Offer packets. So the WL-107G does not send any DHCP Discover packets despite of the DHCPDISCOVER lines in /var/log/messages!

While NetworkManager is getting the IP address, the ACT LED of the card blinks. But Wireshark doesn't hear anything!

Sometimes (but not every time) I got this message when I inserted the card:

  kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready
  ...
  NetworkManager: <info>  wlan0: link timed out.

But when I issued command "iwlist wlan0 scan" the card woke up and NetworkManager displayed my network in its menu.

If I configure a static IP address the card works! And I can see the traffic in Wireshark.
Comment 48 Juhani Jaakola 2009-05-06 07:27:19 UTC 
DHCP worked with my RT2500 card in kernel-2.6.25-14.fc9.i686. Because this problem has been there for about 9 months, can we simply take the rt2500pci module from kernel 2.6.25-14 and port it to the current kernels?
Comment 49 John W. Linville 2009-05-06 12:19:22 UTC 
No, I'm sorry -- that just isn't a realistic option.
Comment 50 Bug Zapper 2009-06-10 02:19:47 UTC 
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 51 Mace Moneta 2009-06-10 02:35:53 UTC 
This is still an issue with F11.
Comment 52 cornel panceac 2009-06-10 16:05:12 UTC 
indeed, it's not fixed on f11.
Comment 53 Alex Butcher 2009-07-26 10:05:41 UTC 
Still present in 2.6.29.6-213.fc11.

Interestingly, if one uses ifconfig to manually assign an IP address/netmask to the appropriate wlan? device, then attempt to use NetworkManager to connect to a WLAN, the WPA authentication will proceed and the device will work until the dhclient times out and NetworkManager shuts the connection down again.
Comment 54 Alex Butcher 2009-07-26 10:07:18 UTC 
Oh, the config was copied from a working config for a rt2561 card (using the rt61pci driver instead of rt2500pci). That rt2561 card works just fine on the same machine.
Comment 55 cornel panceac 2009-11-07 15:09:41 UTC 
the problem is still present on latest rawhide (20091106).
Comment 56 bob mckay 2009-12-02 09:46:13 UTC 
The problem also seems to be present in a fully-updated F12 (20091202):

kernel: 2.6.31.6-145.fc12.i686.PAE

lspci:
00:0b.0 Network controller: RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01)

/var/log/messages:
Dec  2 14:37:57 sclaptop NetworkManager: <info>  (wlan0): DHCP transaction took too long, stopping it.
Dec  2 14:37:57 sclaptop NetworkManager: <info>  (wlan0): canceled DHCP transaction, dhcp client pid 25666

There was some comment in (duplicate marked) Bug 473432 that and in Bug 443202 that this bug might be the same as Bug 443203, but comments there suggest that 443203 has been fixed in F12, so it seems unlikely. 

Is there any useful information I can supply?
Comment 57 bob mckay 2009-12-04 09:57:26 UTC 
Just confirming that I'm seeing the same behaviour as previously reported - logs and wireshark on this machine show DHCPDISCOVER packets, but wireshark on another machine listening on the same wireless network doesn't see the packets.
Comment 58 bob mckay 2009-12-04 10:01:41 UTC 
Created attachment 376045 [details]
Wireshark on another laptop watching this connection

wireshark dump from an F12 machine on the same wlan - will supply logs and wireshark dump from the target RT2500 machine immediately after.
Comment 59 bob mckay 2009-12-04 10:03:25 UTC 
Created attachment 376049 [details]
Wireshark on RT2500 machine

wireshark dump on RT2500 machine showing phantom DHCP discover packets
Comment 60 bob mckay 2009-12-04 10:07:52 UTC 
Created attachment 376051 [details]
/var/log/messages at time of wireshark dumps

Output in /var/log/messages covering period of wireshark dumps (from first request for wlan connection to deactivation after failed dhcp)
Comment 61 Adam Pribyl 2009-12-31 18:07:43 UTC 
Another bug worth to meantion related (dupe?) to this is bug 469120
Comment 62 Juhani Jaakola 2010-02-26 18:05:02 UTC 
The bug still exists in kernel-2.6.31.12-174.2.22.fc12.i686 with card WL-107G. The system has the latest fc12 packages. NetworkManager shows my network name but can not make a connection.
Comment 63 bob mckay 2010-06-08 01:17:38 UTC 
Seems to be fixed in the latest F13 kernel - my wifi started working once I upgraded. Thank you folks!
Comment 64 John W. Linville 2010-06-08 13:35:50 UTC 
Closing on the basis of comment 63...
Comment 65 Juhani Jaakola 2010-06-08 19:06:58 UTC 
Now my WL-107G card works! I'm using kernel-2.6.33.4-95.fc13.i686.

Thank you very much, I've waited for this for a long time!