Date: Tue, 3 Nov 2015 11:06:01 -0800 From: Adrian Chadd <adrian.chadd@gmail.com> To: Alban Hertroys <haramrae@gmail.com> Cc: freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: hostapd loses connectivity on ath0 Message-ID: <CAJ-Vmoki_Z4OL8r9cnDVJb4L5zwMga22XrZ4=%2BoYku=6dF=5Dw@mail.gmail.com> In-Reply-To: <A4E3CF1C-AF60-4B4A-863B-E37A243A6B22@gmail.com> References: <61705059-E85C-4887-BBCD-D2690D27D24A@gmail.com> <CAJ-Vmo=w3K0F_dS2G5JT9BQ8FxcSHA6iz86sj0Kn6=iLyjJmpA@mail.gmail.com> <A4E3CF1C-AF60-4B4A-863B-E37A243A6B22@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@gmail.com> wrote: > >> On 26 Oct 2015, at 22:10, Adrian Chadd <adrian.chadd@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/fir= ewall/wifi AP/file server, especially not if there is little chance that th= is issue is fixed there. I don't have a whole lot of spare time to mess wit= h it and outside of that I need a working server. > > In the mean time, I noticed these messages in my daily security run outpu= t after several restarts of hostapd over the last couple of weeks: > +ath0: ath_tx_default_comp: bf 0xfffffe0001359fc8: seqno 2659: bf_next no= t NULL! > +ath0: ath_tx_default_comp: bf 0xfffffe00013407c8: seqno 2660: bf_next no= t NULL! > +ath0: ath_tx_default_comp: bf 0xfffffe000135c2d8: seqno 2661: bf_next no= t 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 migh= t 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. >>> >>> Shutting down to single user mode in the hung state only partially succ= eeded, 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 h= ung 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@solfertje:/usr/obj/usr/src/sys/ANT= ELOPE amd64 >>> >>> It's quite possible that I've misconfigured something, so here's the re= levant lines of my configs=E2=80=A6 >>> >>> rc.conf: >>> >>> # Outside interface >>> ifconfig_fxp0=3D"DHCP" >>> ifconfig_fxp0_ipv6=3D"inet6 accept_rtadv" >>> >>> # Wireless >>> wlans_ath0=3D"wlan0" >>> >>> create_args_wlan0=3D"wlanmode hostap" >>> >>> ifconfig_wlan0=3D"mode ng channel 9:ht/40" >>> ifconfig_wlan0_ipv6=3D"inet6 accept_rtadv" >>> >>> # 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= " >>> >>> # Internal wired ethernet (should that be above the bridge declaration?= ) >>> ifconfig_em0=3D"up" >>> ifconfig_em0_ipv6=3D"inet6 accept_rtadv" >>> >>> hostapd_enable=3D"YES" >>> >>> #=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> hostapd.conf: >>> >>> 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 >>> >>> >>> The ath0 device is: >>> pciconf -lv ath0 >>> ath0@pci0:5:6:0: class=3D0x028000 card=3D0x0300168c chip=3D0x002= d168c rev=3D0x01 hdr=3D0x00 >>> vendor =3D 'Atheros Communications Inc.' >>> device =3D 'AR9227 Wireless Network Adapter' >>> class =3D network >>> >>> In case it's relevant: All connected devices get their IPv4 addresses t= hrough DHCP from this machine, the machine itself gets it's IPv4 external a= ddress from my upstream provider, the internal addresses are hardwired per = interface. DHCP is configured to use hostnames (instead of IP's) that get l= ooked up in Bind9 on the same machine. >>> >>> >>> Google did find some people on the internet with apparently the same pr= oblem, 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 n= ext 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@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.or= g" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmoki_Z4OL8r9cnDVJb4L5zwMga22XrZ4=%2BoYku=6dF=5Dw>