Will getting a better router help?
How about Adblock and such? Maybe your device checks for internet connectivity by trying to connect to a domain that got recently blocked. When it can’t connect, it restarts its wifi.
You could capture 802.11 frames and you might see disassociation reason code. That might give you a hint.
1 Like
I don't have adblock and my device is a phone.
You could capture 802.11 frames and you might see disassociation reason code. That might give you a hint.
This is the reason for all captured packets: Reason code: Previous authentication no longer valid (0x0002)
A short web search points to issues with multiple APs. I'd try @psherman's advice and disable all 802.11r options (remove all below the key option). Roaming will still work, but might be slower. 802.11r doesn't make devices roam, but only can make it faster (tens of ms vs hundreds of ms). 802.11r is involved only after the device decides to roam.
Will buying a new router fix this issue? I saw another thread where the user had an older firmware with a simmilar problem.
Also I'm curious what the cause of this issue is, as I don't reckon it happening before.
Is this interfering with the ability to actually use the phone? Phones will disconnect when they have no traffic for the Internet because WiFi uses a lot of battery power. In many cases they will simply switch off the radio rather than using unnecessary battery power to send a formal disconnect request first. The AP then finds the device inactive or previous auth no longer valid.
2 Likes
It is disconnecting when I use the device, and pages don't load because of this.
Have you started the tuning process I recommended?
Yes, I adjusted the output power. I couldn't have done much more since the video you sent is for wired extenders, not wireless.
Well, especially if you are working with WDS, you can also experiment with the physical placement of your devices.
Do you have the option to use a wired backhaul?
And, if you just remove the problematic unit (WR940N), what happens?
If I remove the WR940N or disable 802.11r the problem ceases to exist, so I'm thinking it is a bug related to the 802.11r in that particular OpenWRT version. I hope upgrading the router will fix it. As for wired, I'm not sure that will fix anything, but I'll try.
This is why I recommended that way back here:
I don't think it's a bug with OpenWrt, though... I think it's more about the fact that not all devices (even the ones from major device/OS manufacturers) don't always play nice with 802.11r. It is quite common for the behavior to be worse with 802.11r enabled.
Just disable it and go from there.
Yeah, but if I disable 802.11r it won't connect to the other AP until the connection literally drops. This is apparently a common issue with Android 10 phones: https://www.reddit.com/r/openwrt/s/xmbCGDYdHm
This is more of an indictment of the phone and its wifi tuning and roaming algorithms than it does about OpenWrt.
1 Like
Maybe, but do you think replacing the TL-WR940N help?
Yes, I would recommend replacing the WR940N. You'll get much better performance with a modern AP.
1 Like
80211r only concerns the APs pre-loading encryption keys (and notifying the client that its keys have been pre-loaded) so that a client can connect immediately to a new AP without needing time to re-negotiate encryption. The decision of when to roam is still entirely by the client.
You can make clients drop to roam earlier by increasing the AP's minimum data rate. This is the cell_density setting.
1 Like
Thanks, but I still can't understand why the wifi disconnects & reconnects instead of staying connected. Here are some debug logs at the time of disconnection, maybe this would help find the cause:
TL-WR940N:
Sun Mar 24 15:30:05 2024 daemon.debug hostapd: wlan0-1: STA 88:11:96:cb:3a:d3 IEEE 802.11: binding station to interface 'wlan0-1'
Sun Mar 24 15:30:05 2024 daemon.debug hostapd: wlan0-1: STA 88:11:96:cb:3a:d3 IEEE 802.11: authentication OK (FT)
Sun Mar 24 15:30:05 2024 daemon.debug hostapd: wlan0-1: STA 88:11:96:cb:3a:d3 MLME: MLME-AUTHENTICATE.indication(88:11:96:cb:3a:d3, FT)
Sun Mar 24 15:30:05 2024 daemon.debug hostapd: wlan0-1: STA 88:11:96:cb:3a:d3 IEEE 802.11: association OK (aid 4)
Sun Mar 24 15:30:05 2024 daemon.info hostapd: wlan0-1: STA 88:11:96:cb:3a:d3 IEEE 802.11: associated (aid 4)
Sun Mar 24 15:30:05 2024 daemon.notice hostapd: wlan0-1: AP-STA-CONNECTED 88:11:96:cb:3a:d3
Sun Mar 24 15:30:05 2024 daemon.debug hostapd: wlan0-1: STA 88:11:96:cb:3a:d3 MLME: MLME-REASSOCIATE.indication(88:11:96:cb:3a:d3)
Sun Mar 24 15:30:05 2024 daemon.debug hostapd: wlan0-1: STA 88:11:96:cb:3a:d3 IEEE 802.11: binding station to interface 'wlan0-1'
Sun Mar 24 15:30:05 2024 daemon.debug hostapd: wlan0-1: STA 88:11:96:cb:3a:d3 WPA: event 6 notification
Sun Mar 24 15:30:05 2024 daemon.debug hostapd: wlan0-1: STA 88:11:96:cb:3a:d3 WPA: FT authentication already completed - do not start 4-way handshake
Sun Mar 24 15:30:15 2024 daemon.notice hostapd: wlan0-1: AP-STA-DISCONNECTED 88:11:96:cb:3a:d3
Sun Mar 24 15:30:15 2024 daemon.debug hostapd: wlan0-1: STA 88:11:96:cb:3a:d3 WPA: event 2 notification
Sun Mar 24 15:30:15 2024 daemon.debug hostapd: wlan0-1: STA 88:11:96:cb:3a:d3 IEEE 802.1X: unauthorizing port
Sun Mar 24 15:30:15 2024 daemon.info hostapd: wlan0-1: STA 88:11:96:cb:3a:d3 IEEE 802.11: disassociated
Sun Mar 24 15:30:15 2024 daemon.debug hostapd: wlan0-1: STA 88:11:96:cb:3a:d3 MLME: MLME-DISASSOCIATE.indication(88:11:96:cb:3a:d3, 8)
Sun Mar 24 15:30:15 2024 daemon.debug hostapd: wlan0-1: STA 88:11:96:cb:3a:d3 MLME: MLME-DELETEKEYS.request(88:11:96:cb:3a:d3)
Sun Mar 24 15:30:16 2024 daemon.info hostapd: wlan0-1: STA 88:11:96:cb:3a:d3 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Mar 24 15:30:16 2024 daemon.debug hostapd: wlan0-1: STA 88:11:96:cb:3a:d3 MLME: MLME-DEAUTHENTICATE.indication(88:11:96:cb:3a:d3, 2)
Sun Mar 24 15:30:16 2024 daemon.debug hostapd: wlan0-1: STA 88:11:96:cb:3a:d3 MLME: MLME-DELETEKEYS.request(88:11:96:cb:3a:d3)
Archer A6:
Sun Mar 24 17:37:06 2024 daemon.notice hostapd: phy1-ap0: AP-STA-DISCONNECTED 88:11:96:cb:3a:d3
Sun Mar 24 17:37:06 2024 daemon.info hostapd: phy1-ap0: STA 88:11:96:cb:3a:d3 IEEE 802.11: disassociated due to inactivity
Sun Mar 24 17:37:06 2024 daemon.debug hostapd: phy1-ap0: STA 88:11:96:cb:3a:d3 MLME: MLME-DISASSOCIATE.indication(88:11:96:cb:3a:d3, 4)
Sun Mar 24 17:37:06 2024 daemon.debug hostapd: phy1-ap0: STA 88:11:96:cb:3a:d3 MLME: MLME-DELETEKEYS.request(88:11:96:cb:3a:d3)
Sun Mar 24 17:37:07 2024 daemon.info hostapd: phy1-ap0: STA 88:11:96:cb:3a:d3 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Mar 24 17:37:07 2024 daemon.debug hostapd: phy1-ap0: STA 88:11:96:cb:3a:d3 MLME: MLME-DEAUTHENTICATE.indication(88:11:96:cb:3a:d3, 2)
Sun Mar 24 17:37:07 2024 daemon.debug hostapd: phy1-ap0: STA 88:11:96:cb:3a:d3 MLME: MLME-DELETEKEYS.request(88:11:96:cb:3a:d3)
Sure you can:
Forget both and join the one at the top of the list or add a letter or number to the last character of one.
Honestly, just forgetting both and connecting to only one (regardless if you know which) will provide useful information if it gets flaky (the flaky one will show the login and the errors). If it is flaky alone, join the other and forget the first you joined. Check for disconnects.
This will route out one bad actor.
1 Like