I am on OpenWrt SNAPSHOT r18777-1847382456 i have not stumbled yet on that issue yet, the wlan0 went completely down if I get it correctly ...
I got also a phew "unknown event 139" but wifi did not not went down.
Which snapshot are you using ?
Ι have not tested extensively the 5G band, occasionally some of my phone connect to 5G but not for a long time.
For both bands I had all short of issues until I applied the disconnected due inactivity fix as i said before. I am testing it for a phew days now , my android's S8 and S9 phones was always been able to connect to wifi successfully mostly at the 2.4G band.
I have narrowed the problem down to the support HE160 mode in the CH36-64 band. When using HE80 everything works fine. I really don't know when that happened, but for sure HE160 mode (160MHz channel) was properly supported in the past. Tested and validated in SNAPSHOT r18646-3869ccbcc8 but fails in SNAPSHOT r19040-247eaa4416
Well I got hit by the "no connectivity" issue once again after couple days this time, similar to the @ilshatms.
From dmesg:
[543156.909270] br-lan: port 1(lan1) entered disabled state
[543156.922398] mt7530 mdio-bus:00 lan1: Link is Down
[543179.791306] mt7530 mdio-bus:00 lan1: Link is Up - 100Mbps/Full - flow control off
[543179.798928] br-lan: port 1(lan1) entered blocking state
[543179.804235] br-lan: port 1(lan1) entered forwarding state
[543189.158624] br-lan: port 1(lan1) entered disabled state
[543189.164827] mt7530 mdio-bus:00 lan1: Link is Down
[543191.231516] mt7530 mdio-bus:00 lan1: Link is Up - 100Mbps/Full - flow control rx/tx
[543191.239306] br-lan: port 1(lan1) entered blocking state
[543191.244615] br-lan: port 1(lan1) entered forwarding state
From logread:
Mon Mar 7 05:34:16 2022 daemon.debug hostapd: wlan0: STA 08:c5:e1:61:0d:b0 IEEE 802.11: binding station to interface 'wlan0'
Mon Mar 7 05:34:16 2022 daemon.debug hostapd: wlan0: STA 08:c5:e1:61:0d:b0 IEEE 802.11: authentication OK (FT)
Mon Mar 7 05:34:16 2022 daemon.debug hostapd: wlan0: STA 08:c5:e1:61:0d:b0 MLME: MLME-AUTHENTICATE.indication(08:c5:e1:61:0d:b0, FT)
Mon Mar 7 05:34:16 2022 daemon.debug hostapd: wlan0: STA 08:c5:e1:61:0d:b0 IEEE 802.11: association OK (aid 4)
Mon Mar 7 05:34:16 2022 daemon.info hostapd: wlan0: STA 08:c5:e1:61:0d:b0 IEEE 802.11: associated (aid 4)
Mon Mar 7 05:34:16 2022 daemon.notice hostapd: wlan0: AP-STA-CONNECTED 08:c5:e1:61:0d:b0
Mon Mar 7 05:34:16 2022 daemon.debug hostapd: wlan0: STA 08:c5:e1:61:0d:b0 MLME: MLME-REASSOCIATE.indication(08:c5:e1:61:0d:b0)
Mon Mar 7 05:34:16 2022 daemon.debug hostapd: wlan0: STA 08:c5:e1:61:0d:b0 IEEE 802.11: binding station to interface 'wlan0'
Mon Mar 7 05:34:16 2022 daemon.debug hostapd: wlan0: STA 08:c5:e1:61:0d:b0 WPA: event 6 notification
Mon Mar 7 05:34:16 2022 daemon.notice hostapd: wlan1: Prune association for 08:c5:e1:61:0d:b0
Mon Mar 7 05:34:16 2022 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 08:c5:e1:61:0d:b0
Mon Mar 7 05:34:16 2022 daemon.debug hostapd: wlan0: STA 08:c5:e1:61:0d:b0 WPA: FT authentication already completed - do not start 4-way handshake
Mon Mar 7 05:34:18 2022 daemon.debug hostapd: wlan1: STA 08:c5:e1:61:0d:b0 MLME: MLME-DISASSOCIATE.indication(08:c5:e1:61:0d:b0, 1)
Mon Mar 7 05:34:18 2022 daemon.debug hostapd: wlan1: STA 08:c5:e1:61:0d:b0 MLME: MLME-DELETEKEYS.request(08:c5:e1:61:0d:b0)
Mon Mar 7 05:34:46 2022 daemon.info hostapd: wlan1: STA 08:c5:e1:61:0d:b0 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mon Mar 7 05:34:46 2022 daemon.debug hostapd: wlan1: STA 08:c5:e1:61:0d:b0 MLME: MLME-DEAUTHENTICATE.indication(08:c5:e1:61:0d:b0, 2)
Mon Mar 7 05:34:46 2022 daemon.debug hostapd: wlan1: STA 08:c5:e1:61:0d:b0 MLME: MLME-DELETEKEYS.request(08:c5:e1:61:0d:b0)
I checked if the phone was still connected with :
iw dev wlan0 station dump
It was still connected (unfortunately I forgot to copy the output).
And I got connectivity back without needing to restart wifi or reboot the router , we may need to apply one of the workaround scripts suggested on that forum posts to apply the scan every time an event 60 occurs.
I tried the same solution & yes it works, but because the unknown event 60 occurs every 30 seconds to 3 minutes, the script runs iw dev wlan0 scan trigger freq 2447 flush every 30ish seconds.
I'm not sure what's the performance implications of the above, but just wanted to highlight that.
BTW this is just FYI, the ath9k-watchdog.sh script only triggers the scan when 2.4GHz encounters event 60, but I have more event 60s on 5GHz & it works w/o a problem.
@Lynx - I disabled cell density coverage option cell_density '0' and she hasn't complained to me about her phone dropping since doing that... but if I look in my log, I see tons of entries indicating the drop occurred to this day.
It's not just the mac address corresponding to her iPhone X, my 13 is present there as well as an iPad too.
Below, xx:xx:xx:xx:xx:xx is the mac address of the iPhone X which happened dozens of times. I just show one representative example:
I think there may be separate issues here. I have 3x RT3200's connected via WDS (one guest WiFi WDS AP on 2.4 and another normal Wifi WDS on 5) and. I have FT. All works fine for all devices save for the iPhone. So I wonder if there may be something broken with your config?
@darksky are you seeing this only for Apple type devices?