This is interesting. I didn’t see any benefits to running 9.3.2.6 on my master build with iOS. Granted my rate of issue occurrence was different than yours, as it took over a day to reliably encounter the issue, not several minutes.
I’m experimenting with some setting tweaks (as well as just restarting hostapd) to see if it improves things.
Was working fine all day with 21.02 master snapshot and 9.3.2.6. Picked up the phone and went out to the back patio. Says connected but lagged for about 60 seconds then failed over to mobile data. Last log entries:
Android stats: 866 Mbs / connected, RSSI=-60.
Tue Aug 17 16:46:21 2021 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED d4:4d:XX:XX:XX:XX
Tue Aug 17 16:46:21 2021 daemon.info hostapd: wlan0: STA d4:4d:XX:XX:XX:XX IEEE 802.11: disassociated due to inactivity
Tue Aug 17 16:46:22 2021 daemon.info hostapd: wlan0: STA d4:4d:XX:XX:XX:XX IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Tue Aug 17 16:46:22 2021 kern.debug kernel: [53496.183338] ieee80211 phy0: staid 2 deleted
Tue Aug 17 16:46:23 2021 daemon.info hostapd: wlan0: STA d4:4d:XX:XX:XX:XX IEEE 802.11: associated (aid 2)
Tue Aug 17 16:46:23 2021 daemon.notice hostapd: wlan0: AP-STA-CONNECTED d4:4d:XX:XX:XX:XX
Tue Aug 17 16:46:23 2021 daemon.info hostapd: wlan0: STA d4:4d:XX:XX:XX:XX WPA: pairwise key handshake completed (RSN)
Tue Aug 17 16:46:23 2021 daemon.notice hostapd: wlan0: EAPOL-4WAY-HS-COMPLETED d4:4d:XX:XX:XX:XX
Tue Aug 17 16:46:23 2021 daemon.info hostapd: wlan0: STA d4:4d:XX:XX:XX:XX IEEE 802.11: authenticated
Tue Aug 17 16:46:24 2021 daemon.info dnsmasq-dhcp[3248]: DHCPREQUEST(br-lan) 192.168.1.225 d4:4d:XX:XX:XX:XX
Tue Aug 17 16:46:24 2021 daemon.info dnsmasq-dhcp[3248]: DHCPACK(br-lan) 192.168.1.225 d4:4d:XX:XX:XX:XX S10e
I'm currently testing the use of skip_inactivity_poll=1 to see if it has any effect. Over the past 48 hours on my wireless N device, I've had zero data drops for my wifi-connected sensor when using the following:
uci set wireless.default_radio1.skip_inactivity_poll='1'
(Also available in Luci under the Wireless radio config -> Interface Configuration -> Advanced Settings -> Disable Inactivity Polling (checked))
More testing time is needed. I was away from home for a bit, so my network traffic patterns changed over the course of this test.
It could also be that simply restarting hostapd "solves" the issue, not sure yet.
I just activated this on my AC wireless device as well, so both networks are running with "skip_inactivity_poll=1" now. We'll see how things are with my phone over the next 48 hours, as well as continuing to track the historical data with my wifi-connected sensor.
Edit: current results suggest this doesn’t fix the issue. My sensor is starting to report periods of missing data again. I’ll try other settings to see if the behavior changes. I haven’t experienced any issue on my phone yet though, so I’ll wait until I see the issue again before trying a new setting.
I tried :
option disassoc_low_ack '0'
option max_inactivity '43200'
option skip_inactivity_poll '1'
And still have two main issues: 1) clients, in particular Apple devices, loose internet access despite being connected to wifi, and 2) the 5GHz AP disappears after some time. Workarounds are 1) disconnnect and reconnect on wifi on client (slightly annoying), and 2) restart AP on router (very annoying). Here is the last few lines of syslog on rc4.
Fri Aug 20 05:57:45 2021 kern.debug kernel: [ 5180.556805] ieee80211 phy0: Mac80211 start BA XX:XX:XX:XX:XX:X1
Fri Aug 20 05:57:45 2021 kern.debug kernel: [ 5180.613409] ieee80211 phy0: Mac80211 start BA XX:XX:XX:XX:XX:X1
Fri Aug 20 05:57:45 2021 kern.debug kernel: [ 5180.666808] ieee80211 phy0: Mac80211 start BA XX:XX:XX:XX:XX:X1
Fri Aug 20 05:57:45 2021 kern.debug kernel: [ 5180.706817] ieee80211 phy0: Mac80211 start BA XX:XX:XX:XX:XX:X1
Fri Aug 20 05:59:25 2021 daemon.warn odhcpd[2067]: A default route is present but there is no public prefix on lan thus we don't announce a default route!
Fri Aug 20 06:02:18 2021 daemon.info hostapd: wlan1-1: STA XX:XX:XX:XX:XX:X3 IEEE 802.11: authenticated
Fri Aug 20 06:02:18 2021 daemon.info hostapd: wlan1-1: STA XX:XX:XX:XX:XX:X3 IEEE 802.11: associated (aid 1)
Fri Aug 20 06:02:19 2021 daemon.notice hostapd: wlan1-1: AP-STA-CONNECTED XX:XX:XX:XX:XX:X3
Fri Aug 20 06:02:19 2021 daemon.info hostapd: wlan1-1: STA XX:XX:XX:XX:XX:X3 WPA: pairwise key handshake completed (RSN)
Fri Aug 20 06:02:22 2021 daemon.info dnsmasq-dhcp[8834]: DHCPDISCOVER(br-GuestLan) XX:XX:XX:XX:XX:X3
Fri Aug 20 06:02:22 2021 daemon.info dnsmasq-dhcp[8834]: DHCPOFFER(br-GuestLan) 192.168.X.X XX:XX:XX:XX:XX:X3
Fri Aug 20 06:02:22 2021 daemon.info dnsmasq-dhcp[8834]: DHCPDISCOVER(br-GuestLan) XX:XX:XX:XX:XX:X3
Fri Aug 20 06:02:22 2021 daemon.info dnsmasq-dhcp[8834]: DHCPOFFER(br-GuestLan) 192.168.X.X XX:XX:XX:XX:XX:X3
Fri Aug 20 06:02:22 2021 daemon.info dnsmasq-dhcp[8834]: DHCPREQUEST(br-GuestLan) 192.168.X.X XX:XX:XX:XX:XX:X3
Fri Aug 20 06:02:22 2021 daemon.info dnsmasq-dhcp[8834]: DHCPACK(br-GuestLan) 192.168.X.X XX:XX:XX:XX:XX:X3 Galaxy-AX-20XX
Fri Aug 20 06:02:37 2021 kern.debug kernel: [ 5472.903552] ieee80211 phy1: Mac80211 start BA XX:XX:XX:XX:XX:X3
Fri Aug 20 06:02:38 2021 kern.debug kernel: [ 5474.334050] ieee80211 phy1: Stop BA XX:XX:XX:XX:XX:X2
Fri Aug 20 06:03:26 2021 kern.debug kernel: [ 5521.661524] ieee80211 phy1: Mac80211 start BA XX:XX:XX:XX:XX:X3
Fri Aug 20 06:03:27 2021 kern.debug kernel: [ 5522.473467] ieee80211 phy1: Stop BA XX:XX:XX:XX:XX:X3
Fri Aug 20 06:08:25 2021 daemon.warn odhcpd[2067]: A default route is present but there is no public prefix on lan thus we don't announce a default route!
Fri Aug 20 06:09:27 2021 kern.debug kernel: [ 5883.422663] ieee80211 phy0: Mac80211 start BA XX:XX:XX:XX:XX:X1
Fri Aug 20 06:12:03 2021 daemon.err uhttpd[2187]: luci: accepted login on /admin/status/syslog for root from 192.168.X.X
Due to numerous Mrs complaints I moved to 19.7.8 2h ago, and so far no issues.
Yeah. Same as my logs. No clues as to what is happening. I'm thinking there is an interoperability problem between the older driver and the newer mac stuff in the Linux kernel. I tried to turn on as much debug as possible. I also found that some messaging has been removed from some of the software stack to reduce file size at which point I kind of threw up my hands and bought a new router (RT-AX88U).
Well, I've been considering moving to ax for a while, but my WRT1900ACS works fine for my current needs, so I'll try to stick to 19.7.8 for the moment...
plus the RT-AX88U is closed-source Broadcom so has no OpenWRT support,,,,which means you have to trust Asusto do regular upgrades and generally manage security
This is exactly my problem, same thing happening in the logs and seems to mainly affect Apple devices.
Wait - @petersmith this is happening to you with a WRT1900ACS?
I ask, because the WRT1900ACS uses a different firmware than the WRT3200ACM and WRT32X, which is what @arinc9 originally opened this thread for.
If you can reproduce it on a WRT1900ACS, then that seems to indicate either it's an issue with all of the older firmware, or perhaps it's a bug with hostapd/wpad/etc?
Yes, I have a WRT1900ACS and facing the same issues y’all are describing with the 3200. Almost a day now on the 19.7.8 and no issues so far.
Exactly. Will wait until enough ax routers are supported on OpenWRT and that they are long enough on the market to ensure proper testing (I’ve given up on early adoption long ago!)
Same. In the meantime I'd like to point out running my WRT32X on a Master snapshot and wifi is dramatically better, no drop outs at all. 21.02-rc is not reliable for wifi right now.
Good to know: looking forward to a future stable 21! In the mean time I'll keep the 19 or else the Mrs will have me sleep on the couch if I continue the failed experiments 
FWIW running the 19.7.8 for over 24h now. No issues of AP disappearing nor disconnect on Apple devices. Also realized that the latency is much better too.
AX88U source
Ahhh, that might make sense re: 1900ACS issues - I see that Divested disables this by default: https://divested.dev/unofficial-openwrt-builds/mvebu-linksys/patches/0006-mwlwifi-Disable-tx_amsdu.patch
Yea saw that too but that's apparently not a fix on the WRT32X / WRT3200ACM. The only thing I've personally have fix it is just switching to a Master snapshot which I did last week and it's been perfectly stable with no issues. It's the best OpenWrt has ever been for me (flawless with everything I use honestly) so I'm tempted to just stay here a while, or at least until the recent gcc 10 switch gets more testing.
I’m using a WRT32X on master and still have exactly the same issues with WiFi drop outs. It’s not any better from my experience.
Think I’m going to go back to 19.07
One test I completed was switching from 5.10 and 5.4 kernel in master and both had the problem.
Yeah this kind of boggles my mind, as I’m effectively running snapshot on my 3200acm, only with divested’s hardening/optimization patches, and I’m still seeing WiFi dropouts on my iPhone.
Seems like @Nick01 is in the same boat.
So how is it that one person running master is fine and two others running master is not fine?
@phinn I’m pretty sure in the 21 rc threads the same comments were made. That it was working great for you, no problem etc etc?
It’s definitely not any better in master and my iPhone 12 seems to be worse.