Bug 275481 - rt61pci doesn't work for me
Summary: rt61pci doesn't work for me
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 7
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-09-03 18:58 UTC by W Agtail
Modified: 2007-11-30 22:12 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-02 19:30:19 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
dmesg extract showing assocation / denial (1.06 KB, text/plain)
2007-10-28 11:57 UTC, Patrick Sefton
no flags Details

Description W Agtail 2007-09-03 18:58:06 UTC
Description of problem:
Hi there.
I have the following wlan PCI card which uses the rt61pci kernel module:

01:07.0 Network controller: RaLink RT2561/RT61 802.11g PCI
        Subsystem: RaLink Unknown device 2561
        Flags: bus master, slow devsel, latency 32, IRQ 19
        Memory at f1000000 (32-bit, non-prefetchable) [size=32K]
        Capabilities: [40] Power Management version 2

and when trying to configure the card, i get this error message:
ifconfig wlan0 inet netmask
SIOCSIFFLAGS: No buffer space available

Version-Release number of selected component (if applicable):
uname -a
Linux tux #1 SMP Tue Aug 21 21:50:50 EDT 2007 x86_64 x86_64
x86_64 GNU/Linux

How reproducible:

Steps to Reproduce:
1. Inserted card
2. Booted system and card is detected via rt61pci (see above).
3. ifconfig wlan0 inet netmask
Actual results:
SIOCSIFFLAGS: No buffer space available
Unable to configure wlan card

Expected results:
A working wlan card :)

Additional info:
As a work a round, i'm currently using rt61 from serialmonkey:
modinfo rt61

filename:       /lib/modules/
license:        GPL
description:    Ralink RT61 802.11abg WLAN Driver 1.1.0 CVS 2007090312
author:         http://rt2x00.serialmonkey.com
srcversion:     499FD4EBE64CDF5FB9FF05F
alias:          pci:v00001814d00000401sv*sd*bc*sc*i*
alias:          pci:v00001814d00000302sv*sd*bc*sc*i*
alias:          pci:v00001814d00000301sv*sd*bc*sc*i*
vermagic: SMP mod_unload 
parm:           debug:Debug mask: n selects filter, 0 for none (int)
parm:           ifname:Network device name (default wlan%d) (charp)

I had to use this CVS build as the b1 & b2 versions failed to compile.

Many thanks.
W Agatil

Comment 1 John W. Linville 2007-09-28 14:14:05 UTC
Please try the test kernels here:


These have recent rt2x00 updates.  Do they work any better for you?

Comment 2 W Agtail 2007-09-29 16:31:34 UTC
Hi there and thank you very much for your help on this.

I've just installed kernel: (x86_64) and I am now able to use
the rt61pci (version 2.0.8) kernel module to configure wlan0 :)

However, I see this issue as reported in dmesg:
 dmesg | grep wlan0
ADDRCONF(NETDEV_UP): wlan0: link is not ready
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:18:4d:c4:34:66
wlan0: RX authentication from 00:18:4d:c4:34:66 (alg=0 transaction=2 status=0)
wlan0: authenticated
wlan0: associate with AP 00:18:4d:c4:34:66
wlan0: RX AssocResp from 00:18:4d:c4:34:66 (capab=0x431 status=0 aid=2)
wlan0: associated
wlan0: CTS protection enabled (BSSID=00:18:4d:c4:34:66)
wlan0: switched to short barker preamble (BSSID=00:18:4d:c4:34:66)
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
wlan0: CTS protection disabled (BSSID=00:18:4d:c4:34:66)
wlan0: CTS protection enabled (BSSID=00:18:4d:c4:34:66)
wlan0: CTS protection disabled (BSSID=00:18:4d:c4:34:66)
wlan0: CTS protection enabled (BSSID=00:18:4d:c4:34:66)
wlan0: CTS protection disabled (BSSID=00:18:4d:c4:34:66)

and /var/log/messages (lots of printk):
Sep 29 17:21:31 owl kernel: printk: 4 messages suppressed.
Sep 29 17:21:39 owl kernel: printk: 1 messages suppressed.
Sep 29 17:21:43 owl kernel: printk: 1 messages suppressed.
Sep 29 17:21:49 owl kernel: printk: 8 messages suppressed.
Sep 29 17:21:52 owl kernel: printk: 1 messages suppressed.
Sep 29 17:22:02 owl kernel: printk: 3 messages suppressed.
Sep 29 17:22:07 owl kernel: printk: 3 messages suppressed.
Sep 29 17:22:12 owl kernel: printk: 2 messages suppressed.

I'll see how things go :)
Thanks, W Agtail

Comment 3 W Agtail 2007-09-29 16:49:28 UTC

FYI, every fews minutes or so I lose internet connection via wlan0 (as though
the kernel module just hangs?).

Running "ifdown wlan0; ifup wlan0" wakes wlan0 up again.

No additional info captured in dmesg or messages.

Comment 4 John W. Linville 2007-10-16 17:48:45 UTC
Are you using NM or wpa_supplicant?  Or just iwconfig?

Occasional connection drops are not necessarily unusual depending on the 
environment.  NM and wpa_supplicant should take care of reconnecting, but if 
you are simply using iwconfig then there mac80211 may not be smart enough to 
reconnect on its own.

Comment 5 Patrick Sefton 2007-10-28 11:53:45 UTC

I have the same problem (on similar hardware).

Wireless card hardware:
06:0d.0 Network controller: RaLink RT2561/RT61 rev B 802.11g
        Subsystem: D-Link System Inc DWL-G510 Rev C
        Flags: bus master, slow devsel, latency 64, IRQ 17
        Memory at ddcf8000 (32-bit, non-prefetchable) [size=32K]
        Capabilities: [40] Power Management version 2

Currently using: f8test3 with kernel, including version 2.0.8 of
rt2x00pci, which (subject to the dropout problem below) works fine.

The problem is that if I don't use the connection for a few minutes (maybe 5-10
minutes) then it silently disconnects.  Maybe it's going into a power saving
mode?  It will re-connect when I do "ifdown wlan0; ifup wlan0" as noted by the
original reporter above.  It will also re-connect if I do "iwconfig wlan0 essid

I'm not using wpa_supplicant, and if NM=Network Manager, then I'm not using that

I do get some messages about association / denied association in dmesg, so I'll
attach an extract.


Comment 6 Patrick Sefton 2007-10-28 11:57:53 UTC
Created attachment 240861 [details]
dmesg extract showing assocation / denial

Comment 7 Patrick Sefton 2007-10-29 08:16:43 UTC
Having looked up the reason and status codes in the 802.11 spec, this seems to 
be an AP problem/bug?
disassociation reason=4: "Disassociated due to inactivity."
association status=17: "Association denied because AP is unable to handle 
additional associated stations."
For what it's worth, the AP is a D-Link DI-524.

Comment 8 John W. Linville 2007-10-29 13:01:20 UTC
Patrick, good "legwork"...hopefully it is clear that the issue originates with 
your AP.  It is not at all obvious to me that we can do anything about that in 
the wireless stack.

I might suggest in your case that you try using NM or wpa_supplicant as they 
should try automatic reassociations.  You might also try running a ping or 
some other "keep alive" hack in the background to keep the AP from timing you 

W Agtail, if you are not satisfied that this covers what you are experiencing, 
then please post the contents of /var/log/messages after you have been 
disconnected a few times.  It has been a month since my last request for info 
from you -- please respond promptly or I'll have to close this bug.

Comment 9 W Agtail 2007-11-01 20:53:23 UTC
Hi there all.
I don't believe I'm using either NM or wpa_supplicant. Just ifconfig / ipconfig.
Also rebooted with just a /etc/sysconfig/network-scripts/ifcfg-wlan0 in place
and use a WEP key.
Apologies for not getting back sooner.
Strange thing is, I haven't had any printk /var/log/messages (or dmesg messages)
since Oct/08.
Also, I haven't applied any updates since reporting this.

I see a new kernel.x86_64 ( has been released, so I will update
my system within the next few days? and see how things go?

Comment 10 John W. Linville 2007-11-02 19:30:19 UTC
It seems like maybe your AP quit kicking you off the link? :-)

I'm going to go ahead and close this as CURRENTRELEASE.  Please feel free to 
open a new bug if you have further problems, or to reopen this one if the 
disconnection problems return.

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