Arch Linux

hhschen

Member

Registered: 2025-07-10

Posts: 5

Frequent Wi-Fi Disconnections (Deauthentication reason 4)

Hello everyone,

I'm currently using iwd combined with systemd-resolved to manage my Wi-Fi connection on Arch Linux.

# systemctl list-units --type=service | grep -E 'network|dhcp|wpa|iwd|NetworkManager|resolved'
  iwd.service                                          loaded active running Wireless service
  systemd-resolved.service                             loaded active running Network Name Resolution

However, I encounter frequent disconnections every 1-2 hours. Below are some relevant log entries from journalctl showing repeated "Received Deauthentication event, reason: 4, from_ap: false":

 7月 10 15:18:39 chxun-tp iwd[462]: Received Deauthentication event, reason: 4, from_ap: false
 7月 10 15:18:39 chxun-tp iwd[462]: event: disconnect-info, reason: 4
 7月 10 15:18:39 chxun-tp iwd[462]: event: state, old: connected, new: disconnected
 7月 10 15:18:39 chxun-tp iwd[462]: event: state, old: disconnected, new: autoconnect_quick
 7月 10 15:18:40 chxun-tp iwd[462]: event: connect-info, ssid: 76_3, bss: xx:xx:xx:xx:xx:xx, signal: -32, load: 0/255
 7月 10 15:18:40 chxun-tp iwd[462]: event: state, old: autoconnect_quick, new: connecting (auto)
 7月 10 15:18:40 chxun-tp iwd[462]: event: state, old: connecting (auto), new: connecting (netconfig)
 7月 10 15:18:40 chxun-tp iwd[462]: event: state, old: connecting (netconfig), new: connected

I have also tried disabling power saving on my wireless interface with:

iw dev wlan0 set power_save off

My connection automatically reconnects but the frequent drops are quite disruptive. From what I understand, reason code 4 means "Disassociated because sending STA is leaving (or has left) BSS," but I'm not sure why this is triggered so often or why from_ap: false.

Could anyone help me understand what might cause these deauth events? Are there specific iwd or systemd-resolved configurations I should check or tweak? Also, if there are recommended debugging steps, I would appreciate your advice.

Thank you very much in advance!

More journal log

Last edited by hhschen (2025-07-10 07:47:48)

-thc

Member

Registered: 2017-03-15

Posts: 934

Re: Frequent Wi-Fi Disconnections (Deauthentication reason 4)

Your WiFi adapter misses too many beacons from the AP and disconnects:

 7月 10 15:18:09 chxun-tp kernel: iwlwifi 0000:02:00.0: missed beacons exceeds threshold, but receiving data. Stay connected, Expect bugs.
 7月 10 15:18:09 chxun-tp kernel: iwlwifi 0000:02:00.0: missed_beacons:19, missed_beacons_since_rx:2
 7月 10 15:18:09 chxun-tp kernel: iwlwifi 0000:02:00.0: missed beacons exceeds threshold, but receiving data. Stay connected, Expect bugs.
 7月 10 15:18:09 chxun-tp kernel: iwlwifi 0000:02:00.0: missed_beacons:20, missed_beacons_since_rx:1
 7月 10 15:18:09 chxun-tp kernel: iwlwifi 0000:02:00.0: missed beacons exceeds threshold, but receiving data. Stay connected, Expect bugs.
 7月 10 15:18:09 chxun-tp kernel: iwlwifi 0000:02:00.0: missed_beacons:21, missed_beacons_since_rx:2
 7月 10 15:18:09 chxun-tp kernel: iwlwifi 0000:02:00.0: missed beacons exceeds threshold, but receiving data. Stay connected, Expect bugs.
 7月 10 15:18:09 chxun-tp kernel: iwlwifi 0000:02:00.0: missed_beacons:22, missed_beacons_since_rx:3
 7月 10 15:18:10 chxun-tp kernel: wlan0: Connection to AP 1c:3b:f3:d6:bc:f7 lost
 7月 10 15:18:10 chxun-tp iwd[462]: Received Deauthentication event, reason: 4, from_ap: false

Another user solved this by applying these options:

# cat /etc/modprobe.d/iwlwifi.conf 
options iwlwifi 11n_disable=8 led_mode=1 power_save=0 bt_coex_active=N
options iwlmvm power_scheme=1

hhschen

Member

Registered: 2025-07-10

Posts: 5

Re: Frequent Wi-Fi Disconnections (Deauthentication reason 4)

Your WiFi adapter misses too many beacons from the AP and disconnects:

 7月 10 15:18:09 chxun-tp kernel: iwlwifi 0000:02:00.0: missed beacons exceeds threshold, but receiving data. Stay connected, Expect bugs.
 7月 10 15:18:09 chxun-tp kernel: iwlwifi 0000:02:00.0: missed_beacons:19, missed_beacons_since_rx:2
 7月 10 15:18:09 chxun-tp kernel: iwlwifi 0000:02:00.0: missed beacons exceeds threshold, but receiving data. Stay connected, Expect bugs.
 7月 10 15:18:09 chxun-tp kernel: iwlwifi 0000:02:00.0: missed_beacons:20, missed_beacons_since_rx:1
 7月 10 15:18:09 chxun-tp kernel: iwlwifi 0000:02:00.0: missed beacons exceeds threshold, but receiving data. Stay connected, Expect bugs.
 7月 10 15:18:09 chxun-tp kernel: iwlwifi 0000:02:00.0: missed_beacons:21, missed_beacons_since_rx:2
 7月 10 15:18:09 chxun-tp kernel: iwlwifi 0000:02:00.0: missed beacons exceeds threshold, but receiving data. Stay connected, Expect bugs.
 7月 10 15:18:09 chxun-tp kernel: iwlwifi 0000:02:00.0: missed_beacons:22, missed_beacons_since_rx:3
 7月 10 15:18:10 chxun-tp kernel: wlan0: Connection to AP 1c:3b:f3:d6:bc:f7 lost
 7月 10 15:18:10 chxun-tp iwd[462]: Received Deauthentication event, reason: 4, from_ap: false

Another user solved this by applying these options:

# cat /etc/modprobe.d/iwlwifi.conf 
options iwlwifi 11n_disable=8 led_mode=1 power_save=0 bt_coex_active=N
options iwlmvm power_scheme=1

I've already tried that, but the connection still gets deauthenticated after about 40 mins.
It seems to be something specific to iwd — I didn't encounter the same issue on another machine running wpa_supplicant.

mithrial

Member

Registered: 2017-03-05

Posts: 101

Re: Frequent Wi-Fi Disconnections (Deauthentication reason 4)

You could change to wpa_supplicant relatively easily and test it there.
Install it, stop iwd, start wpa-supplicant@wlan0, and authenticate your ssid.

hhschen

Member

Registered: 2025-07-10

Posts: 5

Re: Frequent Wi-Fi Disconnections (Deauthentication reason 4)

You could change to wpa_supplicant relatively easily and test it there.
Install it, stop iwd, start wpa-supplicant@wlan0, and authenticate your ssid.

Alright... I guess I’ll temporarily switch from plain iwd to a setup with systemd-networkd, wpa_supplicant, and systemd-resolved, and see if that works any better. Maybe one day the situation with iwd will improve.

seth

Member

Registered: 2012-09-03

Posts: 66,041

Re: Frequent Wi-Fi Disconnections (Deauthentication reason 4)

still gets deauthenticated after about 40 mins.

However

7月 10 12:48:44 chxun-tp iwd[462]: event: state, old: connecting (netconfig), new: connected
…
7月 10 15:18:09 chxun-tp kernel: iwlwifi 0000:02:00.0: missed beacons exceeds threshold, but receiving data. Stay connected, Expect bugs.

are 150 minutes, updated journal?

1. how long is the lease time on the AP?
2. What if you use dhcpcd instead of https://wiki.archlinux.org/title/Iwd#En … figuration ?
3. do you have the opportunity to connect to a different AP (phone hotspot?)
4. yuo're blocking traffic w/ the gateway in ufw  excempt the entire LAN segment if it's not a hostile environment (starbucks) and at least the gateway (192.168.68.1)
Actually it seems you're exclusively blocking local and multicast traffic??
If you're in a friendly NAT'ing LAN with a consumer router and a firewall there, just completely disable UFW

---

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

hhschen

Member

Registered: 2025-07-10

Posts: 5

Re: Frequent Wi-Fi Disconnections (Deauthentication reason 4)

still gets deauthenticated after about 40 mins.

However

7月 10 12:48:44 chxun-tp iwd[462]: event: state, old: connecting (netconfig), new: connected
…
7月 10 15:18:09 chxun-tp kernel: iwlwifi 0000:02:00.0: missed beacons exceeds threshold, but receiving data. Stay connected, Expect bugs.

are 150 minutes, updated journal?

Roughly 40 minutes after adding iwlwifi module options for testing, I received another Deauthentication event, reason: 4, from_ap: false.
The error messages I’m receiving are basically the same, so I didn’t post them.

1. how long is the lease time on the AP?
2. What if you use dhcpcd instead of https://wiki.archlinux.org/title/Iwd#En … figuration ?
3. do you have the opportunity to connect to a different AP (phone hotspot?)
4. yuo're blocking traffic w/ the gateway in ufw  excempt the entire LAN segment if it's not a hostile environment (starbucks) and at least the gateway (192.168.68.1)
Actually it seems you're exclusively blocking local and multicast traffic??
If you're in a friendly NAT'ing LAN with a consumer router and a firewall there, just completely disable UFW

1. In the file /run/systemd/netif/lease, the DHCP lease parameters are set as follows:

T1  = 1 hour
T2  = 1 hour 45 minutes
Lease lifetime = 2 hours

Not sure whether this is what you want.

2. Will try.
3. Of course.
4. Honestly, I'm not really sure why I set this up — maybe I followed some random shxt tutorial and forgot about it. I'll just disable it for now.

seth

Member

Registered: 2012-09-03

Posts: 66,041

Re: Frequent Wi-Fi Disconnections (Deauthentication reason 4)

1. Idk whether iwd records leases there, but you're mostly interested in the setting at the AP (if you've access to/control over it)
3. Ok, check the connection stability against a different AP as well please.

---

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

hhschen

Member

Registered: 2025-07-10

Posts: 5

Re: Frequent Wi-Fi Disconnections (Deauthentication reason 4)

1. Idk whether iwd records leases there, but you're mostly interested in the setting at the AP (if you've access to/control over it)
3. Ok, check the connection stability against a different AP as well please.

Unfortunately, I'm not the administrator of the Wi-Fi network, so I don't have access to the access point to check its DHCP lease settings.

That said, the mobile hotspot seems to be more stable than the original Wi-Fi. I've been testing the connection for about two hours now without any disconnections, which is a noticeable improvement compared to before, when the connection would drop frequently.

At this point, I'm still not sure whether the issue lies with iwd or the Wi-Fi access point—it might just need more time to confirm.

Edit: Regardless of whether wpa_supplicant or iwd is used, iwlwifi consistently experiences beacon loss.
If the root cause lies in the driver itself, there's likely little that can be done from the user side until Intel releases a proper fix. :(

Last edited by hhschen (2025-07-11 13:42:22)