Date: Tue, 3 Nov 2015 16:19:58 +0100 From: Alban Hertroys <haramrae@gmail.com> To: Adrian Chadd <adrian.chadd@gmail.com> Cc: freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: hostapd loses connectivity on ath0 Message-ID: <A4E3CF1C-AF60-4B4A-863B-E37A243A6B22@gmail.com> In-Reply-To: <CAJ-Vmo=w3K0F_dS2G5JT9BQ8FxcSHA6iz86sj0Kn6=iLyjJmpA@mail.gmail.com> References: <61705059-E85C-4887-BBCD-D2690D27D24A@gmail.com> <CAJ-Vmo=w3K0F_dS2G5JT9BQ8FxcSHA6iz86sj0Kn6=iLyjJmpA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 26 Oct 2015, at 22:10, Adrian Chadd <adrian.chadd@gmail.com> wrote: >=20 > hiya, >=20 > you should try -head. >=20 > 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@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. >>=20 >> 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. >>=20 >> The system is: >>=20 >> uname -a >> FreeBSD solfertje 10.2-PRERELEASE FreeBSD 10.2-PRERELEASE #19 = r286718: Thu Aug 13 10:00:32 CEST 2015 = dalroi@solfertje:/usr/obj/usr/src/sys/ANTELOPE amd64 >>=20 >> It's quite possible that I've misconfigured something, so here's the = relevant lines of my configs=E2=80=A6 >>=20 >> rc.conf: >>=20 >> # Outside interface >> ifconfig_fxp0=3D"DHCP" >> ifconfig_fxp0_ipv6=3D"inet6 accept_rtadv" >>=20 >> # Wireless >> wlans_ath0=3D"wlan0" >>=20 >> create_args_wlan0=3D"wlanmode hostap" >>=20 >> ifconfig_wlan0=3D"mode ng channel 9:ht/40" >> ifconfig_wlan0_ipv6=3D"inet6 accept_rtadv" >>=20 >> # Bridged interfaces (see example at man 4 bridge) >> cloned_interfaces=3D"bridge0" >> ifconfig_bridge0=3D"addm em0 stp em0 addm wlan0 stp wlan0 up" >> ifconfig_bridge0_alias0=3D"inet 10.236.150.1/24" >> ifconfig_bridge0_ipv6_alias0=3D"inet6 = fe80::6efd:b9ff:fe68:db36%bridge0" >>=20 >> # Internal wired ethernet (should that be above the bridge = declaration?) >> ifconfig_em0=3D"up" >> ifconfig_em0_ipv6=3D"inet6 accept_rtadv" >>=20 >> hostapd_enable=3D"YES" >>=20 >> #=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> hostapd.conf: >>=20 >> interface=3Dwlan0 >> driver=3Dbsd >> debug=3D1 >> ctrl_interface=3D/var/run/hostapd >> ctrl_interface_group=3Dwheel >> ssid=3Dfoo >> country_code=3DNL >> ieee80211d=3D1 >> hw_mode=3Dg >> wpa=3D2 >> wpa_passphrase=3Dnonononono >> wpa_key_mgmt=3DWPA-PSK >> wpa_pairwise=3DCCMP >>=20 >>=20 >> The ath0 device is: >> pciconf -lv ath0 >> ath0@pci0:5:6:0: class=3D0x028000 card=3D0x0300168c = chip=3D0x002d168c rev=3D0x01 hdr=3D0x00 >> vendor =3D 'Atheros Communications Inc.' >> device =3D 'AR9227 Wireless Network Adapter' >> class =3D network >>=20 >> 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. >>=20 >>=20 >> Google did find some people on the internet with apparently the same = problem, but nobody seems to have found (or posted) a resolution. >>=20 >> Am I doing something wrong? If not, is this a known issue? What's the = next step? >>=20 >> Alban Hertroys >> -- >> If you can't see the forest for the trees, >> cut the trees and you'll find there is no forest. >>=20 >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A4E3CF1C-AF60-4B4A-863B-E37A243A6B22>