hostapd loses connectivity on ath0

Adrian Chadd adrian.chadd at gmail.com
Tue Nov 3 19:06:02 UTC 2015


Hi,

The stable/10 code doesn't have all the fixes I did over the last two
years. Just disable 11n (ifconfig wlan0 -ht) and use that. :-)

Sorry!



-adrian


On 3 November 2015 at 07:19, Alban Hertroys <haramrae at gmail.com> wrote:
>
>> On 26 Oct 2015, at 22:10, Adrian Chadd <adrian.chadd at gmail.com> wrote:
>>
>> hiya,
>>
>> you should try -head.
>>
>> But there's some long standing issues hiding around in the AR9227 code
>> somewhere where they occasionally go deaf and I never figured out
>> why... :(
>
> Frankly, I'm not too eager attempting to run -head on my home gateway/firewall/wifi AP/file server, especially not if there is little chance that this issue is fixed there. I don't have a whole lot of spare time to mess with it and outside of that I need a working server.
>
> In the mean time, I noticed these messages in my daily security run output after several restarts of hostapd over the last couple of weeks:
> +ath0: ath_tx_default_comp: bf 0xfffffe0001359fc8: seqno 2659: bf_next not NULL!
> +ath0: ath_tx_default_comp: bf 0xfffffe00013407c8: seqno 2660: bf_next not NULL!
> +ath0: ath_tx_default_comp: bf 0xfffffe000135c2d8: seqno 2661: bf_next not NULL!
> +wlan0: ieee80211_new_state_locked: pending RUN -> SCAN transition lost
>
> (I'm guessing a lockup of the card is imminent again)
>
> Is that any help in getting closer to the cause? Is there any info I might be able to provide when it locks up again? If this isn't a hardware bug, I would like to see this fixed if possible in the current constraints.
>
> Or should I just swap my ath card for a different model (or brand)? If so, which are safe?
>
> Regards,
>
>
>> On 26 October 2015 at 13:27, Alban Hertroys <haramrae at gmail.com> wrote:
>>> At random times my devices suddenly fail to connect to Wifi on my ath0 device. Issueing /etc/rc.d/hostapd restart usually resolves the issue, but at some point that also hung.
>>>
>>> Shutting down to single user mode in the hung state only partially succeeded, in the sense that ifconfig, hostapd and a few other network-related processes kept "running" - I assume the hangup of hostapd was caused by a hung process somewhere in that tree.
>>>
>>> The system is:
>>>
>>> uname -a
>>> FreeBSD solfertje 10.2-PRERELEASE FreeBSD 10.2-PRERELEASE #19 r286718: Thu Aug 13 10:00:32 CEST 2015     dalroi at solfertje:/usr/obj/usr/src/sys/ANTELOPE  amd64
>>>
>>> It's quite possible that I've misconfigured something, so here's the relevant lines of my configs…
>>>
>>> rc.conf:
>>>
>>> # Outside interface
>>> ifconfig_fxp0="DHCP"
>>> ifconfig_fxp0_ipv6="inet6 accept_rtadv"
>>>
>>> # Wireless
>>> wlans_ath0="wlan0"
>>>
>>> create_args_wlan0="wlanmode hostap"
>>>
>>> ifconfig_wlan0="mode ng channel 9:ht/40"
>>> ifconfig_wlan0_ipv6="inet6 accept_rtadv"
>>>
>>> # Bridged interfaces (see example at man 4 bridge)
>>> cloned_interfaces="bridge0"
>>> ifconfig_bridge0="addm em0 stp em0 addm wlan0 stp wlan0 up"
>>> ifconfig_bridge0_alias0="inet 10.236.150.1/24"
>>> ifconfig_bridge0_ipv6_alias0="inet6 fe80::6efd:b9ff:fe68:db36%bridge0"
>>>
>>> # Internal wired ethernet (should that be above the bridge declaration?)
>>> ifconfig_em0="up"
>>> ifconfig_em0_ipv6="inet6 accept_rtadv"
>>>
>>> hostapd_enable="YES"
>>>
>>> #=============
>>>
>>> hostapd.conf:
>>>
>>> interface=wlan0
>>> driver=bsd
>>> debug=1
>>> ctrl_interface=/var/run/hostapd
>>> ctrl_interface_group=wheel
>>> ssid=foo
>>> country_code=NL
>>> ieee80211d=1
>>> hw_mode=g
>>> wpa=2
>>> wpa_passphrase=nonononono
>>> wpa_key_mgmt=WPA-PSK
>>> wpa_pairwise=CCMP
>>>
>>>
>>> The ath0 device is:
>>> pciconf -lv ath0
>>> ath0 at pci0:5:6:0:        class=0x028000 card=0x0300168c chip=0x002d168c rev=0x01 hdr=0x00
>>>    vendor     = 'Atheros Communications Inc.'
>>>    device     = 'AR9227 Wireless Network Adapter'
>>>    class      = network
>>>
>>> In case it's relevant: All connected devices get their IPv4 addresses through DHCP from this machine, the machine itself gets it's IPv4 external address from my upstream provider, the internal addresses are hardwired per interface. DHCP is configured to use hostnames (instead of IP's) that get looked up in Bind9 on the same machine.
>>>
>>>
>>> Google did find some people on the internet with apparently the same problem, but nobody seems to have found (or posted) a resolution.
>>>
>>> Am I doing something wrong? If not, is this a known issue? What's the next step?
>>>
>>> Alban Hertroys
>>> --
>>> If you can't see the forest for the trees,
>>> cut the trees and you'll find there is no forest.
>>>
>>> _______________________________________________
>>> freebsd-stable at freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>


More information about the freebsd-stable mailing list