On 2020-06-19 12:13, Adrian Chadd wrote: > If I can't keep it running can someone suggest a system test I can do to > decide that hostapd needs to be restarted? > > So, you shouldn't need to restart hostapd after a stuck beacon. It > should recover.
That was my understanding. > One thing I found was lots of log entries like this: > > ath0: stuck beacon; resetting (bmiss count 4) > > So there's plenty of reasons for a stuck beacon. I've mostly fixed the > programming problems and now it's typically really busy air. > > From reading up on that it seems that it is just a cosmetic warning. > Could this be an indication of something that is killing the hotspot? > > It's possible but it shouldn't be killing the interface. > > What you could try is forcing a full reset every time the NIC needs to > reset. > > sysctl dev.ath.0.hal.force_full_reset=1 I have done this. It still happened. Note that hostapd is still running when I restart it. > What I suggest you do is recompile your kernel/modules with the > following options: > > IEEE80211_DEBUG > ATH_DEBUG > AH_DEBUG > ATH_DIAGAPI > > Then you'll get access to a lot more debugging tools (ie, the stuff in > tools/tools/ath/) which we can use to diagnose what's going on. I like to run a generic kernel and use loadable modules so I don't compile my own kernel yet. I will try that if I can't fix it any other way. -- D'Arcy J.M. Cain <da...@druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 788 2246 (DoD#0082) (eNTP) | what's for dinner. IM: da...@vybenetworks.com, VoIP: sip:da...@druid.net
signature.asc
Description: OpenPGP digital signature
