On Sat, Oct 14, 2017 at 11:30:39AM +0200, Stefan Sperling wrote: > On Sat, Oct 14, 2017 at 11:16:38AM +0200, Stefan Sperling wrote: > > On Fri, Oct 13, 2017 at 09:12:05PM -0400, Andre Smagin wrote: > > > After testing extensively for two days, I cannot reproduce this issue > > > at all, the firewall is as stable as it was for some years. > > > > > > Are there any debugging printf-s I can add > > > > What is bs.bs_bmissthreshold set to before and after the change? > > > > Actually, nevermind. The problem must be somewhere else. > > This ath(4) driver code bmissthreshold change only affects client > mode, but you're running ath(4) in access point mode. So I suppose > the culprit is somewhere inside net80211 code changes. >
I have looked through the entire kernel tree diff obtained with: cd /usr/src/sys; cvs -R diff -D "2017-05-30" -D "2017-06-01" . Nothing obvious stands out. It is possible that this bug has always been present but happens only because of some side effect which we don't control yet. A 'ath0: device timeout' message means the AP failed to dispatch a frame to a client. The driver will always reset the device when this happens, and that is considered normal operation. If such a reset is causing a hard system hang, that is a separate issue. The reason for the transmission failure isn't obvious. If we knew why it failed, we might be able to solve this. You mentioned that you can only trigger the hang with a tablet but not with an OpenBSD wifi client. Are the 'device timeouts' related to the tablet's wifi interface entering power save mode? The ath(4) driver does not support power saving clients and I don't know what (mis)behaviours can be expected when a client uses power saving regardless.
