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
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
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.
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.
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!
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)
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?
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.
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.