Bug 192423 - FreeBSD-10 with AR9220, console spam and reboot with both hostap and client wlan-s on the same ath0
Summary: FreeBSD-10 with AR9220, console spam and reboot with both hostap and client w...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: 10.0-STABLE
Hardware: i386 Any
: --- Affects Some People
Assignee: freebsd-wireless (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-06 08:39 UTC by Nikolay Denev
Modified: 2018-05-28 19:49 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nikolay Denev 2014-08-06 08:39:11 UTC
I have a Soekris Net5501 on which I've recently installed an AR9220 based mini-PCI card (MikroTik R52Hn) with both antenna ports used.

I'm trying to use it to both connect to an AP, and at the same time setup as a AP.

The AP I'm connecting to is 802.11g, while I'm setting up the AP wlan as 802.11n (not sure if this is relevant).

And at the moment both wlan0 and wlan1 are enabled the machine slows down, possibly due to excessive kernel printfs like these :

  ath0: ath_rate_findrate: currates != sc_currates!

And eventually reboots (possibly due to watchdog kicking in).

rc.conf :

  wlans_ath0="wlan0 wlan1"
  ifconfig_ath0="up"
  ifconfig_wlan0="ssid WISP wepkey 1:0xdeadbeef weptxkey 1 wepmode on deftxkey 1 DHCP"
  create_args_wlan1="wlanmode hostap"
  ifconfig_wlan1="mode 11ng channel 9:ht/40"
  ifconfig_bridge0="addm wlan1 addm vr0"

hostapd.conf :
  interface=wlan1
  logger_syslog=-1
  logger_syslog_level=0
  logger_stdout=-1
  logger_stdout_level=0
  debug=3
  dump_file=/tmp/hostapd.dump
  ctrl_interface=/var/run/hostapd
  ctrl_interface_group=wheel
  ssid=my-home-wi-fi
  macaddr_acl=0
  auth_algs=1
  ieee8021x=0
  wpa=2
  wpa_passphrase=********
  wpa_key_mgmt=WPA-PSK
  wpa_pairwise=CCMP
Comment 1 Nikolay Denev 2014-08-06 08:40:40 UTC
OS is : FreeBSD mars 10.0-STABLE FreeBSD 10.0-STABLE #20 r262664: Mon Mar  3 02:24:37 UTC 2014     root@mars:/usr/obj/usr/src/sys/MARS  i386
Comment 2 Adrian Chadd freebsd_committer 2014-08-06 08:46:19 UTC
What channel is it associating on?

Typically when that happens it's because the rate control code found that the rate table was changing very frequently from underneath it and a lot of the wifi driver code assumed the rate table wouldn't change that frequently.

Is ath0 the AP or STA?

So there's two parts:

* figure out why your rate table keeps changing;
* figure out a better way to handle that in the rate table code.
Comment 3 Nikolay Denev 2014-08-06 08:51:51 UTC
Both wlan0 and wlan1 are on the same ath0 device.

So, wlan0 is STA, associated on channel 9 (2452 MHz 11g).
Currently is at DS/11Mbps, however it fluctuates a lot between DS1/Mbps, 5.5Mbps,
sometimes it goes as high as OFDM/48Mbps.

wlan1 is the AP wlan, it is now configured on Channel 6, however I've tried to start it also on channel 9 with the same result.
Comment 4 Nikolay Denev 2014-08-11 10:15:42 UTC
So, just for the experiment, I've commented out the "currrates != sc_currates!" device_printf line and recompiled.

Now, when I crete both wlan devices one, AP one STA, they seem to work, but after a while (a few minutes) of iperf traffic over wlan1 (the AP) I see a lot of these on the console and
wifi clients lose IP connectivity while still show "associated":

Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39fbbc0: seqno 2434: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39eaef0: seqno 2435: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39e9f00: seqno 2436: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39ecdc0: seqno 2437: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39f4d40: seqno 2438: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39f0d80: seqno 2439: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39e8e00: seqno 2440: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39e7150: seqno 2441: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39fa790: seqno 2442: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39e0820: seqno 2443: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39eb660: seqno 2444: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39e89c0: seqno 2445: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39e8470: seqno 2446: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39f8f20: seqno 2447: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39f21b0: seqno 2428: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39f01d0: seqno 2453: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39da550: seqno 2454: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39ea780: seqno 2455: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39eeeb0: seqno 2456: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39eced0: seqno 2458: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39e3c30: seqno 2459: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39dda70: seqno 2460: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39ea670: seqno 2461: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39f6170: seqno 2462: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39f5f50: seqno 2463: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39dffa0: seqno 2464: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39f1930: seqno 2465: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39dc860: seqno 2466: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39f23d0: seqno 2467: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39f78d0: seqno 2468: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39f02e0: seqno 2469: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39f4e50: seqno 2470: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39f14f0: seqno 2471: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39eea70: seqno 2472: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39e4180: seqno 2473: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39e3190: seqno 2474: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39edec0: seqno 2475: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39e26f0: seqno 2476: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39f3f70: seqno 2477: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39dca80: seqno 2478: bf_next not NULL!
Aug 11 07:33:25 mars kernel: ath0: ath_tx_default_comp: bf 0xc39fa9b0: seqno 2479: bf_next not NULL!
Comment 5 Nikolay Denev 2014-08-11 10:18:08 UTC
So, I'm absolutely not familiar with the inner workings of the 80211 layer,
but if the ""currrates != sc_currates!"" condition is not something really weird in my case, maybe I can try to turn this into a counter, so that the console is not spammed to a livelock of the machine. (offtopic, but ideally kernel printf should have had some rate limiting)
Comment 6 Adrian Chadd freebsd_committer 2014-08-11 17:17:30 UTC
Ah, I only noticed just now that you're using it as STA and AP.

So, the only supported (read: tested) setup with a STA + AP VAP on the same device is when running it as a wireless extension using WDS.

Also, I think I fixed that bf_next issue in -HEAD. Would you consider running that instead for ath+11n?
Comment 7 Nikolay Denev 2014-08-11 18:14:30 UTC
I will give it a try (running CURRENT) if time permits, as the full rebuild will take me some time (I don't have a separate build env setup correctly, and rebuilding on the Soekris itslef takes a few days :D )

Anyways, I've just tried a shortcut and manually applied a bf_next fix I've found : http://svnweb.freebsd.org/base?view=revision&revision=264710
And not I no longer see these messages.
Apart from having to do a "ifconfig wlan1 down && ifconfig wlan1 up" after reboot[1] it seems to work and I just pushed a 60 secs of iperf over the AP wlan :

[  5] local 10.0.0.1 port 5001 connected with 10.0.0.173 port 61317
[  5]  0.0-60.0 sec   615 MBytes  86.0 Mbits/sec


[1]: after reboot I see wlan1 as "no carrier", while it is UP and hostapd is runing. If I do down/up if starts working.
Comment 8 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:49:23 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.