netdev - Re: WARNING at net/mac80211/rate.c:513 ieee80211_get_tx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 28 Jan 2016 11:01:36 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	David Miller <davem@...emloft.net>,
	Linux Wireless List <linux-wireless@...r.kernel.org>,
	Network Development <netdev@...r.kernel.org>
Subject: Re: WARNING at net/mac80211/rate.c:513 ieee80211_get_tx_rates [mac80211]

On Thu, Jan 28, 2016 at 4:13 AM, Johannes Berg
<johannes@...solutions.net> wrote:
> On Wed, 2016-01-27 at 21:34 -0800, Linus Torvalds wrote:
>
>> .. except now I upgraded the nearest access point, and now wireless
>> on that machine no longer works.
>
> Can you describe the upgrade a bit more, just for background?

I used to have the basic original UniFi UAP. I've replaced them with
the newer "AC Lite" version:

    https://www.ubnt.com/unifi/unifi-ap-ac-lite/

so it's a fairly big jump from a 2.4GHz-only network to a dual-band one.

The old 2.4GHz-only AP's showed the problem with minstrel-ht
incorrectly starting off at the highest rate (on a totally different
machine). So the Unifi AP's have shown problems in the kernel wireless
before, but so far it's always been the fault of the kernel wireless,
not the AP.

> Could you print out the entire table there when the warning happens?

This is the best I can come up with: printing out the index, and the
rate and bitrate tables:

  rates[i].idx (9) >= sband->n_bitrates (8)
  Rates:
      0: idx 9 count 1 flags a0
      1: idx 8 count 1 flags a0
      2: idx 7 count 2 flags a0
      3: idx 6 count 3 flags a0
  Bitrates:
      0: flags 00000002 bitrate 60 (hw: 0004 0000)
      1: flags 00000000 bitrate 90 (hw: 0005 0000)
      2: flags 00000002 bitrate 120 (hw: 0006 0000)
      3: flags 00000000 bitrate 180 (hw: 0007 0000)
      4: flags 00000002 bitrate 240 (hw: 0008 0000)
      5: flags 00000000 bitrate 360 (hw: 0009 0000)
      6: flags 00000000 bitrate 480 (hw: 000a 0000)
      7: flags 00000000 bitrate 540 (hw: 000b 0000)

So it's the very first rate that has index 9, but the bitrate table
only goes from 0-7.

So I suspect that once the first index has been marked invalid, it now
will never even look at the later indices, so it has no transmit rates
at all.  Or something.

That bitrate table does seem to match:

   static struct ieee80211_rate rtl_ratetable_5g[] = {

in drivers/net/wireless/realtek/rtlwifi/base.c

Does this give you any ideas?

              Linus