[Help]: Fixing regular deauth by local choice with newer adapters

[geeksmith]

Checklist

• I acknowledge that support is provided on a best-effort basis.
• I acknowledge that the authors and contributors to this repository cannot be held responsible for the results of my use of any information contained in or linked from this repository.

uname

Linux pyfi 6.11.0-9-generic #9-Ubuntu SMP PREEMPT_DYNAMIC Mon Oct 14 13:19:59 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

lsusb

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 004: ID 8087:0aa7 Intel Corp. Wireless-AC 3168 Bluetooth Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 002: ID 0e8d:7961 MediaTek Inc. Wireless_Device

rfkill

0: hci0: Bluetooth Soft blocked: no Hard blocked: no 1: phy0: Wireless LAN Soft blocked: no Hard blocked: no 4: phy3: Wireless LAN Soft blocked: no Hard blocked: no

dkms

sudo: dkms: command not found

iw

phy#3
        Interface wlx90de80486487
                ifindex 9
                wdev 0x300000001
                addr 90:de:80:48:64:87
                ssid g33k-starlink-2
                type managed
                channel 6 (2437 MHz), width: 20 MHz, center1: 2437 MHz
                txpower 3.00 dBm
                multicast TXQ:
                        qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
                        0       0       0       0       0       0       0       0               0
phy#0
        Unnamed/non-netdev interface
                wdev 0x2
                addr 40:a3:cc:2f:5d:b4
                type P2P-device
        Interface wlp2s0
                ifindex 3
                wdev 0x1
                addr 4a:54:cc:1b:e9:f2
                type managed
                multicast TXQ:
                        qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
                        0       0       0       0       0       0       0       0               0

What happened?

I'm writing this issue for posterity's sake, and for anybody that may run into the same issues I've been fighting. I've been using an Intel mini-pc NUC6CAYH as my home router (not Wi-Fi AP, an IP router) with an 802.11 uplink connection for a while. It's currently connected to a Starlink AP/router. The onboard Intel 802.11 adapter bit the dust, so I started using the USB 802.11 adapters I had sitting in a drawer. Then those started to bite the dust over the years, so I bought some new adapters. That's when the fun started.

My old 802.11n adapters worked just fine with occasional lock-ups, requiring me to either disconnect/reconnect or unload and reload the driver. When I tried any adapter supporting 802.11ac or newer it would stop working after 1-5 minutes with kernel logs like this:

2024-10-13T00:08:05.681711-07:00 pyfi kernel: wlx6ccdd6abac95: deauthenticating from b2:c8:41:29:92:1a by local choice (Reason: 3=DEAUTH_LEAVING)
2024-10-13T00:08:13.807591-07:00 pyfi kernel: wlx6ccdd6abac95: 80 MHz not supported, disabling VHT
2024-10-13T00:08:14.307071-07:00 pyfi kernel: wlx6ccdd6abac95: authenticate with b2:c8:41:29:92:1a (local address=f2:9c:9a:f2:95:d8)
2024-10-13T00:08:14.307107-07:00 pyfi kernel: wlx6ccdd6abac95: send auth to b2:c8:41:29:92:1a (try 1/3)
2024-10-13T00:08:19.341599-07:00 pyfi kernel: wlx6ccdd6abac95: aborting authentication with b2:c8:41:29:92:1a by local choice (Reason: 3=DEAUTH_LEAVING)
2024-10-13T00:08:27.697625-07:00 pyfi kernel: wlx6ccdd6abac95: 80 MHz not supported, disabling VHT
2024-10-13T00:08:27.875581-07:00 pyfi kernel: wlx6ccdd6abac95: authenticate with b2:c8:41:29:92:1a (local address=f2:9c:9a:f2:95:d8)
2024-10-13T00:08:27.875627-07:00 pyfi kernel: wlx6ccdd6abac95: send auth to b2:c8:41:29:92:1a (try 1/3)
2024-10-13T00:08:28.965649-07:00 pyfi kernel: wlx6ccdd6abac95: send auth to b2:c8:41:29:92:1a (try 2/3)
2024-10-13T00:08:28.967603-07:00 pyfi kernel: wlx6ccdd6abac95: authenticated
2024-10-13T00:08:28.967633-07:00 pyfi kernel: wlx6ccdd6abac95: associate with b2:c8:41:29:92:1a (try 1/3)
2024-10-13T00:08:28.977685-07:00 pyfi kernel: wlx6ccdd6abac95: RX AssocResp from b2:c8:41:29:92:1a (capab=0x1431 status=0 aid=1)
2024-10-13T00:08:28.979586-07:00 pyfi kernel: wlx6ccdd6abac95: associated
2024-10-13T00:08:29.060683-07:00 pyfi kernel: wlx6ccdd6abac95: Limiting TX power to 27 (27 - 0) dBm as advertised by b2:c8:41:29:92:1a
2024-10-13T00:13:05.692604-07:00 pyfi kernel: wlx6ccdd6abac95: deauthenticating from b2:c8:41:29:92:1a by local choice (Reason: 3=DEAUTH_LEAVING)
2024-10-13T00:13:20.681578-07:00 pyfi kernel: wlx6ccdd6abac95: 80 MHz not supported, disabling VHT
2024-10-13T00:13:20.743571-07:00 pyfi kernel: wlx6ccdd6abac95: authenticate with b2:c8:41:29:92:1a (local address=1e:b1:42:a7:1c:3f)
2024-10-13T00:13:20.743607-07:00 pyfi kernel: wlx6ccdd6abac95: send auth to b2:c8:41:29:92:1a (try 1/3)
2024-10-13T00:13:25.746615-07:00 pyfi kernel: wlx6ccdd6abac95: aborting authentication with b2:c8:41:29:92:1a by local choice (Reason: 3=DEAUTH_LEAVING)

This happened no matter what type of adapter or chipset I used. I tried the latest adapter firmware. I updated the BIOS of the NUC to the latest version. I upgraded from Ubuntu 24.04.1 to 24.10. I tried new adapters with the following chipsets:

• rt5572
• rtl8812bu
• mt7612un using this workaround
• mt7921au

These adapters worked much better on my Thinkpad T15. Though I saw the DEAUTH_LEAVING log maybe once a day, it recovered gracefully. The NUC would stop working after 1-3 deauths, requiring manual intervention.

As I searched for a solution, many sources I found focused on the channel width message. Based on the behavior I was convinced that channel width was not a factor. Because it happened across chipsets, but only with newer adapters, I figured it was in the common 802.11 code. Searching for this log in the kernel (it's in net/mac80211/mlme.c), I found that this code is only called when CONFIG_PM is enabled. I looked into disabling sleep and suspend operations globally on the system, but that didn't seem right and didn't help when I tried it.

In the end, what fixed it for me was disabling powersave via the methods prescribed in other issues and discussions found in this git repo.

• set wifi.powersave = 2 in /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf and restarting NetworkManager
• add post-up sudo iw dev $IFACE set power_save off to /etc/network/interfaces entries

Since making those adjustments, the adapter with the mt7921au chipset has been up for several hours without any problems. I hope this solution finds a frustrated user in the near future.