iOS devices deauthenticated due to inactivity

Hello, OpenWrt newbie here. My issue is several of my iOS devices regularly (several times a day) get into a 'zombie link' state where they still show they have decent wifi signal, but they have no actual connectivity for an extended period of time (minutes or more). Toggling wifi on the device off and on will resolve it for a little while. In the Openwrt logs around the same time, I'll see a message for the device MAC something like this:

daemon.info hostapd: phy1-ap0: STA [device_mac] IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

Combing the logs, those DEAUTH messages mostly affect only iOS devices (e.g. iPhone 15 Pro, or older iPads), but occasionally I'll see a DEAUTH for the wifi address of a newish Windows machine or a Mac Mini, and rarely for an iRobot Roomba or a Yale smartlock. I haven't noticed the 'zombie link' state on the non-iOS devices, though it's quite possible it's present and just harder to notice since they get lighter usage. Inactivity DEAUTHs happen for iOS devices connected to both APs, so it's not an issue with just one AP's hardware.

My setup is a Banana Pi R4 running a recent OpenWrt snapshot (about a week old) acting as router and Wifi AP, with a 1 Gbps ethernet connection to a GL.iNet "Beryl AX" GL-MT3000 running OpenWrt 23.05.5 that is acting as a separate AP. Both devices are configured to act broadcast my primary SSID, and the Banana Pi also broadcasts a guest SSID. The two APs configured to use non-overlapping channels. I'm in a rural area so wifi interference from neighbors is minimal.

I've read through quite a few posts about similar issues others have experienced (usually with iOS devices), and haven't had any luck with the suggested solutions. Below is some additional info in case relevant.
/etc/config/wireless from the primary AP/router (config is similar on the other, minus the guest network):


config wifi-device 'radio0'
	option type 'mac80211'
	option path 'soc/11300000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
	option band '2g'
	option channel '1'
	option htmode 'HE20'
	option cell_density '0'
	option country 'AU'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'MYSSID'
	option encryption 'sae-mixed'
	option key 'mypassword'
	option disassoc_low_ack '0'
	option max_inactivity '3600'
	option ocv '0'
	option dtim_period '3'
	option wpa_group_rekey '86400'
	option ft_over_ds '0'
	option ieee80211r '0'

config wifi-device 'radio1'
	option type 'mac80211'
	option path 'soc/11300000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0+1'
	option band '5g'
	option channel '36'
	option htmode 'HE80'
	option country 'AU'
	option cell_density '0'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'MYSSID'
	option encryption 'sae-mixed'
	option key 'mypassword'
	option ocv '0'
	option disassoc_low_ack '0'
	option max_inactivity '3600'
	option dtim_period '3'
	option wpa_group_rekey '86400'
	option ft_over_ds '0'
	option ieee80211r '0'

config wifi-device 'radio2'
	option type 'mac80211'
	option path 'soc/11300000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0+2'
	option band '6g'
	option channel '33'
	option htmode 'HE160'
	option country 'AU'
	option cell_density '0'
	option txpower '23'

config wifi-iface 'default_radio2'
	option device 'radio2'
	option network 'lan'
	option mode 'ap'
	option ssid 'MYSSID'
	option encryption 'sae'
	option key 'mypassword'
	option ocv '0'
	option ieee80211w '2'
	option ieee80211r '0'
	option nasid '22475cbbafb1'
	option ft_over_ds '0'
	option disassoc_low_ack '0'
	option max_inactivity '3600'
	option dtim_period '3'
	option wpa_group_rekey '86400'

config wifi-iface 'wifinet3'
	option device 'radio0'
	option mode 'ap'
	option ssid 'MYSSID-Guest'
	option encryption 'psk2'
	option key 'myguestpassword'
	option network 'guestlan'

config wifi-iface 'wifinet4'
	option device 'radio1'
	option mode 'ap'
	option ssid 'MYSSID-Guest'
	option encryption 'psk2'
	option key 'myguestpassword'
	option ocv '0'
	option network 'guestlan'

"ubus call system board" on Banana Pi R4:

{
	"kernel": "6.6.59",
	"hostname": "OpenWrtPrimaryAP",
	"system": "ARMv8 Processor rev 0",
	"model": "Bananapi BPI-R4",
	"board_name": "bananapi,bpi-r4",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "SNAPSHOT",
		"revision": "r28034-ca53f2d430",
		"target": "mediatek/filogic",
		"description": "OpenWrt SNAPSHOT r28034-ca53f2d430",
		"builddate": "1731082951"
	}
}

"ubus call system board" on GL.iNet:

{
	"kernel": "5.15.167",
	"hostname": "GLiNETmt3000",
	"system": "ARMv8 Processor rev 4",
	"model": "GL.iNet GL-MT3000",
	"board_name": "glinet,gl-mt3000",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "23.05.5",
		"revision": "r24106-10cc5fcd00",
		"target": "mediatek/filogic",
		"description": "OpenWrt 23.05.5 r24106-10cc5fcd00"
	}
}

This is not the only issue with my setup -- there's a Sony GoogleTV device that won't connect to my secondary AP but will connect to my primary AP's guest network, and some Nanoleaf Shapes devices that won't complete HomeKit setup, but most devices are working OK, and the issue with iOS devices is the most serious problem. I'm still holding out hope there's some setting somewhere that will make OpenWrt play nice with my family's iOS devices, but I'm pretty stuck. If I can't solve it, I will unfortunately have to bail on OpenWrt and try Ubiquiti or Ruckus gear (as this guy also eventually did when faced with the same issue). Any help would be much appreciated.

That is perfectly normal occurence in logs. Apples has problems with your 11R attempt and probably other parametritis.

	option mode 'ap'
	option ssid 'MYSSID'
	option encryption 'sae'
	option key 'mypassword'
-	option ocv '0'
-	option ieee80211w '2'
-	option ieee80211r '0'
-	option nasid '22475cbbafb1'
-	option ft_over_ds '0'
-	option disassoc_low_ack '0'
-	option max_inactivity '3600'
-	option dtim_period '3'
-	option wpa_group_rekey '86400'
1 Like

is probably what your other devices don't like...

2 Likes

Thank you for the suggestions. For diagnostic purposes, I've turned off the 6 GHz radio (which requires 'sae'), set encryption to 'psk2', and removed the options brada4 flagged. I'll report back in a few days once I have a decent amount of observations.

Just in a few hours of testing, I still see the "deauthenticated due to inactivity (timer DEAUTH..." message for the iPhone that most frequently experiences the issue, but it seems to mostly be happening as part of an orderly handoff from one radio to another (e.g. client connects to phy1-ap0, disconnects from phy0-ap0, and then 30 s later there's a "timer DEAUTH" message for phy0. Before, I'd see the "timer DEAUTH" from one radio without a connection to the other radio right before.

It's an encouraging sign, but only a few hours of data, and I don't have a ton of hope, as most of those options were either set to default values (e.g. ocv, ieee80211r) or were recent experiments to try to resolve the problem (i.e. I spent at least a week without the last four options). Also, ieee80211w '2' was only set on the 6 GHz radio, as it appears to be required for that radio to function. Still, there's some chance that ā€” as brada4 suggests ā€” the nasid or ft_over_ds options (which are both for 80211r) have caused some problems despite 802.11r being disabled.

Anything else I should be looking at, e.g. in terms of logging or diagnostics?

You can read on options in generated /var/run/hostapd*.conf here:
https://w1.fi/cgit/hostap/tree/hostapd/hostapd.conf

Is there a chance this happened on a series of recent Apple updates?
I don't have an iOS device, but an M2 MacBook Pro, which shows the same symptoms for a couple of weeks now.

Every 30 minutes (pretty much exactly) I get a 4 to 5 seconds disconnect. The AP shows the same error message the OP has and video calls via e.g. MS Teams hang for that time. I'm pretty sure I this started only a view weeks ago.

So, maybe an apple thing caused by the latest update? I don't always install macOS updates right away, so I can't say if there was an macOS update two weeks ago or if I just installed an older one at that time.

I just googled for a solution myself, and I'm under the impression there's multiple people having similar issues lately.

As for my current state of debugging, I turned wpa_group_rekey='300' and max_inactivity='240', and while I see rekeying log lines every five minutes on one side and have a constant ping once per second on the other side, after 30 minutes, there's an unwarranted "disconnect due to inactivity".

wpa_group_rekey seems pretty low compared to the default of 3600 s. Iā€™d recommend to remove all customizations, like the other person did, and see what happens. If you have multiple APs do the same or even consider turning them off to avoid back and forth roaming issues.

The default for wpa_group_rekey is not 3600 (one hour) but rather 600 (10 minutes). The default for max_inactivity is 300 (5 minutes). I just did this during debugging and basically while I tried to figure out if the clients get that value somehow beforehand, which could make them "more considerate" (for the lack of a propper word for that) in terms of protocol conformity.

But potentially something I'm not going to keep for the long run, since that fills syslog pretty quickly.

The thing is: I had the previous setting for years over the course of multiple OpenWRT versions. Up to the point where I had some settings that aren't supported since long ago. No problems until a couple of weeks ago, where the thing I changed, if my memory serves me right, was an macOS updated.

Getting rid of obsolete settings didn't change a thing, but I recognized hostapd complaining about insufficient buffer space while booting. So I changed the net.core arguments for rmem_default, rmem_max, wmem_default and wmem_max. Not to solve my disconnections, but just for getting rid of any error message in general. I'm not prepared for calling this the solution, but the number of unwarranted disconnects went down by a factor of 20 so far.

I didn't want to take over this thread, however. I'm rather suggesting the faulty situation might have worsened just recently and might be caused by changes made by Apple.

Strange, I haven't observed any issues and I'm running up to date iOS/macOS with 23.05.5, pesa1234 and some recent shapshot at the same time on 2 x GL-MT6000 and 1 x GL-MT3000. Perhaps this is some kind of a device-specific issue. What device are you using?

You could try observing various WiFi-related events in macOS Console.app. Maybe something would give you a clue what might be happening.

Did you try to set log_level to 0 so that hostapd logs everything it can?

Sometimes there could be additional information in dmesg output on your access point/router and in macOS.

As a last resort, I'd recommend setting channel width to 20 MHz, setting up WiFi monitoring and then analyzing what happend in Wireshark.

Better Level 1, level 0 would log data packets and their interpretations.

Ok, I have to check this again. I think I have it on 0 and I don't see data packets in syslog.

I'm running a couple of Belkin RT3200, a couple of Zyxel WSM 20 and one Cudy AX3000. Due to physical device locations, the MacBook doesn't like to stay on one of the Belkins or Zyxels and keeps switching to the Cudy. Hard to tell if that's a thing related to the Cudy, but seems like the Belkin is only a little bit better, if anything.

I don't debug macOS networking very often. Have you any suggestions on which logs I should look for on my MacBook? Thanks for the hint though, I haven't thought about this at all.

I let my current setup sit for at least half a week and observe. Setting an aggressive log_level is on my list for the future, but since syslog is already cluttered as is and I don't intend to keep a constant eye on it for the days, I'm not doing this right away. The same goes for Wireshark. Will do as a last resort, but digging through that amount of data is nothing I have the time for right now.

Too much roaming could be resolved by reducing TX power on access points in 5 GHz to something like 12-15, maybe 18 dBm if you have blind spots. In 2.4 GHz you might even try going as low as 9 dBm.

Also you could setup additional separate SSIDs for each AP and try using your MacBook with these to exclude roaming. That could help with understanding if this is a network-wide problem or only related to a specific AP.

Open Console.app, click Start, type "airportd" into the search box and press enter. When you encounter the problem, click Pause. It is daunting, but there's not much you can do with weirdness.

I'm surprised iOS works at all.

Try WPA3 or WPA2; not both.

1 Like

Try setting DTIM Interval to 2

I had this issue with iPhones and that was the solution