Bug 481259 - ath9k - bit rate is always reported as 1 Mb/s
ath9k - bit rate is always reported as 1 Mb/s
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-23 01:11 EST by Michal Jaegermann
Modified: 2009-06-16 01:17 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-02 09:03:08 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)

  None (edit)
Description Michal Jaegermann 2009-01-23 01:11:45 EST
Description of problem:

'iwlist wlan0 rate' used with an Atheros device (PCI ID 168c:002a and using ath9k driver) always responds with:

wlan0     unknown bit-rate information.
          Current Bit Rate=1 Mb/s

That is clearly bogus.  scp on that connection reports transfer rates around 
2.8 MB/sec.  The same "1 Mb/s" shows in an output of iwconfig and a connection information panel as shown by NetworkManager.

'iwlist wlan0 scan' lists twelve possible bit rates for an AP in use.

Version-Release number of selected component (if applicable):
kernel-2.6.27.12-170.2.5.fc10.i686

How reproducible:
always and it was showing up the same with different kernels.
Comment 1 John W. Linville 2009-01-28 17:41:14 EST
Dan, is this a break-down between wireless-tools and the kernel?
Comment 2 John W. Linville 2009-02-04 15:24:26 EST
This is reported against rawhide, but the kernel version above is from F-10.  Can you try this with a rawhide kernel?
Comment 3 Michal Jaegermann 2009-02-04 16:46:53 EST
> This is reported against rawhide, but the kernel version above is from F-10.

Oops! Sorry.  Bugzilla interfaces strike again.

> Can you try this with a rawhide kernel?

Hm, this is really an F10 installation and there are limits to which I can mess with it.  If dependencies are not too onerous ...
Comment 4 Michal Jaegermann 2009-02-04 22:58:36 EST
> Can you try this with a rawhide kernel?

OK, I tried with kernel-2.6.29-0.78.rc3.git5.fc11.i686

'iwlist wlan0 rate' here prints

wlan0     unknown bit-rate information.
          Current Bit Rate=54 Mb/s

"Unknown" but I think that correct. :-)  Also iwconfig and NM information display report 54 Mb/s.

Unfortunately rfkill switch still does not work with this kernel.  Bummer, but this is another issue.  I guess that I will revert to f10 kernels for now.
Especially that I immediately got a number "possible circular locking dependency detected" traces.
Comment 5 Michal Jaegermann 2009-02-12 11:32:59 EST
That is back to 1 Mb/s with kernel 2.6.27.15-170.2.22.fc10.i686 from koji although it shows a correct 54 Mb/s with 2.6.29-0.22.rc4.git1.fc10.i686 from koji too.

Besides /sys/class/rfkill/ bits look definitely saner with the later kernel even if I cannot get rfkill working with any kernel so far. :-(
(eeepc 1002HA).
Comment 6 Michael Cronenworth 2009-02-28 02:13:10 EST
I can confirm this issue with 2.6.27 in F10. Fixed with 2.6.29-rc6 from koji. ASUS notebook.
Comment 7 John W. Linville 2009-03-04 14:49:07 EST
Can you try a 2.6.29-based F10 kernel?

   http://koji.fedoraproject.org/koji/buildinfo?buildID=92572
Comment 8 Michal Jaegermann 2009-03-04 15:37:13 EST
> Can you try a 2.6.29-based F10 kernel?

I did and reported results in comment #4 on 2009-02-04.  That worked fine
(as some other things which are broken in 2.6.27 - see bug 485322).
Comment 9 John W. Linville 2009-03-04 17:59:28 EST
Ok, I see...Michal, thanks...Michael, please try the kernel in comment 7... :-)
Comment 10 Michal Jaegermann 2009-03-04 22:00:41 EST
kernel 2.6.29-0.53.rc7.fc10.i686 adds a new twist to to game which I do not remember seeing with 2.6.29-0.22.rc4.git1.fc10.i686.

Namely when a wireless connection is established then bitrates reported by NM panel, 'iwconfig wlan0' or 'iwlist wlan0 rate' are correct although the last one prints that as:

wlan0     unknown bit-rate information.
          Current Bit Rate=54 Mb/s

OTOH with an ethernet cable connected too I will see after a while

wlan0     unknown bit-rate information.
          Current Bit Rate=1 Mb/s

and that means that a wireless connection really "dead", i.e. if I will unplug a cable then typing "on the other end" brings no reaction.  Still if left alone then after a short while this connection is back in action with a reported bit-rate again at 54 Mb/s.  No other indications anywhere else that something may be amiss beyond that bit-rate.  Maybe it was like that before but I simply failed to notics as "1 Mb/s" was reported always?  At least with 2.6.27 kernels.

With 2.6.29-0.53.rc7.fc10.i686 there also seem to be much more troublesome to restore a connection after, say, wifi antenna was turned off and on again. I may need to retype an AP password although it did not change at all and it would be accepted from a keyring if that would be after a reboot with antenna on.
Comment 11 Luis R. Rodriguez 2009-03-15 16:21:58 EDT
Please keep in mind using wireless-tools is the wrong utility for checking MCS rates, work now supports reporting MCS rates with mac80211 11n based drivers however right now ath9k reports its MCS rate index from an array and not the actual MCS rate. But you can use debugfs to check the actual rate list, including PER (packet error rate).

sudo mount -t debugfs debugfs /debug
cat /debug/ath9k/phy0/rcstat

Work to change the rate reported by ath9k is using nl80211 requires a bit more work, but wireless-tools won't ever get that information anyway. In order for Network Manager to make use of this new feature it would also have to start speaking nl80211.

You may want to try with the latest ath9k:

http://wireless.kernel.org/en/users/Drivers/ath9k#Getthelatestath9kdriver

Also be sure to check out and install iw:

http://wireless.kernel.org/en/users/Documentation/iw

Like I said then, if you are using an 802.11n AP then wireless-tools won't understand the rate used. What type of connection are you establishing with your AP?
Comment 12 Michal Jaegermann 2009-03-15 17:32:11 EDT
> Please keep in mind using wireless-tools is the wrong utility for checking MCS
> rates

The original report said "That is clearly bogus" and talked about different rate reports including NetworkManager information display.  OTOH, as already noted in  preceding comments, with 2.6.29-... kernels this "wrong utility", and NetworkManager too, display what looks like real rates which change depending on circumstances.

> if you are using an 802.11n AP ...

AP is a few years old and so predates 802.11n draft.  I do not think that it
is able to talk this way.
Comment 13 Luis R. Rodriguez 2009-03-15 18:14:17 EDT
My comment was about MCS rates which would only happen if you are using an 802.11n AP. But you are not.

What do you mean by "wifi antenna was turned off and on again".

If you connect an Ethernet cable I believe by default Network Manager will prefer that over wireless so at that point hopefully the last sent and received wireless frames will have been management frames to create a disassociation. 802.11 management frames are sent at the lowest supported bitrate which would be 1Mbit/s and would explain your observations.
Comment 14 Michal Jaegermann 2009-03-15 18:47:10 EDT
> What do you mean by "wifi antenna was turned off and on again".

There is a keyboard switch on then netbook in question.  It does not work "as a system installed" but it can be made to work.  It generates some event which allows to turn off and on wifi.  Another possibility is to echo 0 or 1 to
/sys/class/rfkill/rfkill0/state.

When wifi was switched off and later switched on again it appears that
there is a trouble to get an association going again.  You may see:

....
wlan0: direct probe to AP 00:13:10:1b:6f:68 try 1
wlan0: direct probe to AP 00:13:10:1b:6f:68 try 1
wlan0: direct probe to AP 00:13:10:1b:6f:68 try 2
wlan0: direct probe to AP 00:13:10:1b:6f:68 try 3
wlan0: direct probe to AP 00:13:10:1b:6f:68 timed out
wlan0: direct probe to AP 00:13:10:1b:6f:68 try 1
wlan0: direct probe to AP 00:13:10:1b:6f:68 try 1
wlan0: direct probe to AP 00:13:10:1b:6f:68 try 2
wlan0: direct probe to AP 00:13:10:1b:6f:68 try 3
wlan0: direct probe to AP 00:13:10:1b:6f:68 timed out
.....
and after a number of tries:

wlan0: direct probe to AP 00:13:10:1b:6f:68 timed out
wlan0: deauthenticating by local choice (reason=3)
ADDRCONF(NETDEV_UP): wlan0: link is not ready

or similar things.  Disabling wifi in NM, and enabling it again, usually allows to get out of this.

> If you connect an Ethernet cable I believe by default Network Manager will
> prefer that over wireless

It indeed used to behave that way.  It appears that it is somewhat ambiguous
in F10 and both connections can be active at the same time.  That can be
easily verified.

> ... and would explain your observations.

Not when an etherned cable is unplugged.  See, for example, a comment #4 and
comment #10.  With 2.6.27-... kernels this is _always_ 1 Mb/s.
Comment 15 Luis R. Rodriguez 2009-03-15 19:02:24 EDT
OK thanks -- that is called an rfkill switch, it will not disable your antennas, it will tell your hardware to kill your radio, to turn it off.

You may want to check to see if you see the same issues with using rfkill on newer FC kernels. If you want to stick to your current kernel and help debug issues on it please disable network manager, pkill wpa_supplicant and then simply try running things manually.

This may help too:

http://wireless.kernel.org/en/users/Documentation/Reporting_bugs

If you are using the latest and greatest (wireless-testing or compat-wireless) you can simply send your feedback on issues to the ath9k mailing list.

http://wireless.kernel.org/en/users/Drivers/ath9k#Mailinglist

Please be sure to use a subject like "won't reconnect after using rfkill"

It would certainly help if you help test this with wireless-testing.
Comment 16 Michal Jaegermann 2009-03-15 21:21:53 EDT
> OK thanks -- that is called an rfkill switch ...

Yes, I know how it is called.  If you are talking about turning on/off radio or antenna this comes to the same thing.

> You may want to check to see if you see the same issues with using rfkill on
> newer FC kernels.

A behaviour is the same in all 2.6.27...fc10 and 2.6.29...fc10 kernels, up to and
including 2.6.29-0.54.rc7.git3.fc10.i686, which I tried.  I mean here both a behaviour of rfkill and its effects on ath9k driver.

> This may help too:

See bug #485322.  Nothing changed there so far.  Moreover whatever one can find on http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html does not seem to be applicable  (but this is straying from the original bug report).

OK, I may look at filing another one about reconnection issues but with rfkill
on a funk I was not in a great hurry.
Comment 17 Luis R. Rodriguez 2009-06-01 13:39:40 EDT
This bug report was about bit rate reporting. Is this still an issue? Did you try wireless-testing?
Comment 18 Michal Jaegermann 2009-06-02 04:39:50 EDT
> Is this still an issue?

See comment #4.  It still applies, and subsequent ones, in full.  If I will use one of 2.6.29-... kernels from updates-testing then rates are showing up correctly.  If you will use released kernels, still at 2.6.27 level, then the only rate displayed is 1 Mb/sec.
Comment 19 Luis R. Rodriguez 2009-06-16 01:17:05 EDT
Please close this bug, even if we could fix it I don't think the patch would get merged as it wouldn't fix a bug report or oops, or regression.

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