I’ve had an issue with the Wi-Fi on my 12th gen Intel Framework since I got it a few months ago. I’ve been busy so I’ve mostly just been using an ethernet cable and avoiding the issue, but I need to get this sorted now.
I dual boot Ubuntu 22.04.2 and Windows 11 but I only use Windows very occasionally. I followed all the steps in the Ubuntu 22.04 setup guide, including the bit about /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf.
I tried some different kernel versions in the hope that it would solve the issue. It didn’t help so I’ve now removed them and gone back to the recommended OEM kernel.
Kernel version:
uname -r
5.17.0-1028-oem
Wifi stuff during boot:
sudo dmesg | grep iw
[ 8.034435] iwlwifi 0000:a6:00.0: enabling device (0000 -> 0002)
[ 8.041560] iwlwifi 0000:a6:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-69.ucode failed with error -2
[ 8.043057] iwlwifi 0000:a6:00.0: api flags index 2 larger than supported by driver
[ 8.043072] iwlwifi 0000:a6:00.0: TLV_FW_FSEQ_VERSION: FSEQ Version: 0.0.2.36
[ 8.043347] iwlwifi 0000:a6:00.0: loaded firmware version 68.01d30b0c.0 ty-a0-gf-a0-68.ucode op_mode iwlmvm
[ 8.375633] iwlwifi 0000:a6:00.0: Detected Intel(R) Wi-Fi 6 AX210 160MHz, REV=0x420
[ 8.568216] iwlwifi 0000:a6:00.0: loaded PNVM version 05a8dfca
[ 8.582725] iwlwifi 0000:a6:00.0: Detected RF GF, rfid=0x10d000
[ 8.656697] iwlwifi 0000:a6:00.0: base HW address: bc:09:1b:f3:a5:e3
[ 8.697358] iwlwifi 0000:a6:00.0 wlp166s0: renamed from wlan0
When I’m on a 5GHz network, the connection drops quite frequently and dmesg gets flooded with this happening in a loop:
[ +4.317827] wlp166s0: authenticate with 14:49:bc:51:94:69
[ +0.013615] wlp166s0: send auth to 14:49:bc:51:94:69 (try 1/3)
[ +0.097003] wlp166s0: authenticate with 14:49:bc:51:94:69
[ +0.000014] wlp166s0: send auth to 14:49:bc:51:94:69 (try 1/3)
[ +0.105452] wlp166s0: authenticated
[ +0.001477] wlp166s0: associate with 14:49:bc:51:94:69 (try 1/3)
[ +0.039381] wlp166s0: RX AssocResp from 14:49:bc:51:94:69 (capab=0x111 status=0 aid=3)
[ +0.006123] wlp166s0: associated
[ +0.149235] IPv6: ADDRCONF(NETDEV_CHANGE): wlp166s0: link becomes ready
[ +0.022263] wlp166s0: Limiting TX power to 30 (30 - 0) dBm as advertised by 14:49:bc:51:94:69
[ +24.387599] wlp166s0: Connection to AP 14:49:bc:51:94:69 lost
[ +2.560136] wlp166s0: authenticate with 14:49:bc:51:94:69
[ +0.012979] wlp166s0: send auth to 14:49:bc:51:94:69 (try 1/3)
[ +0.040378] wlp166s0: authenticated
[ +0.001395] wlp166s0: associate with 14:49:bc:51:94:69 (try 1/3)
[ +0.033559] wlp166s0: RX AssocResp from 14:49:bc:51:94:69 (capab=0x111 status=0 aid=3)
[ +0.005645] wlp166s0: associated
[ +0.094938] wlp166s0: Limiting TX power to 30 (30 - 0) dBm as advertised by 14:49:bc:51:94:69
[Mar10 14:35] wlp166s0: Connection to AP 14:49:bc:51:94:69 lost
[ +2.798838] wlp166s0: authenticate with 14:49:bc:51:94:69
[ +0.011536] wlp166s0: send auth to 14:49:bc:51:94:69 (try 1/3)
[ +0.040228] wlp166s0: authenticated
[ +0.001537] wlp166s0: associate with 14:49:bc:51:94:69 (try 1/3)
[ +0.029250] wlp166s0: RX AssocResp from 14:49:bc:51:94:69 (capab=0x111 status=0 aid=3)
[ +0.011219] wlp166s0: associated
[ +0.062081] wlp166s0: Limiting TX power to 30 (30 - 0) dBm as advertised by 14:49:bc:51:94:69
[Mar10 14:36] wlp166s0: Connection to AP 14:49:bc:51:94:69 lost
[ +2.991269] wlp166s0: authenticate with 14:49:bc:51:94:69
[ +0.011711] wlp166s0: send auth to 14:49:bc:51:94:69 (try 1/3)
[ +0.040760] wlp166s0: authenticated
[ +0.007739] wlp166s0: associate with 14:49:bc:51:94:69 (try 1/3)
[ +0.031819] wlp166s0: RX AssocResp from 14:49:bc:51:94:69 (capab=0x111 status=0 aid=3)
[ +0.005636] wlp166s0: associated
[ +0.069804] wlp166s0: Limiting TX power to 30 (30 - 0) dBm as advertised by 14:49:bc:51:94:69
[ +0.042000] iwlwifi 0000:a6:00.0: Unhandled alg: 0x707
[ +0.009509] iwlwifi 0000:a6:00.0: Unhandled alg: 0x707
On 2.4GHz I see more of the above, with the addition of some lines about ‘session protection’:
[Mar10 15:18] wlp166s0: authenticate with 16:49:bc:41:94:69
[ +0.000044] wlp166s0: 80 MHz not supported, disabling VHT
[ +0.010499] wlp166s0: send auth to 16:49:bc:41:94:69 (try 1/3)
[ +0.030554] wlp166s0: authenticated
[ +0.005736] wlp166s0: associate with 16:49:bc:41:94:69 (try 1/3)
[ +0.005434] wlp166s0: RX AssocResp from 16:49:bc:41:94:69 (capab=0x411 status=30 aid=2895)
[ +0.000031] wlp166s0: 16:49:bc:41:94:69 rejected association temporarily; comeback duration 1024 TU (1048 ms)
[ +0.000846] iwlwifi 0000:a6:00.0: Unhandled alg: 0x707
[ +1.077699] wlp166s0: associate with 16:49:bc:41:94:69 (try 2/3)
[ +0.107889] wlp166s0: associate with 16:49:bc:41:94:69 (try 3/3)
[ +0.104052] wlp166s0: association with 16:49:bc:41:94:69 timed out
[ +2.837358] wlp166s0: authenticate with 16:49:bc:41:87:60
[ +0.000033] wlp166s0: 80 MHz not supported, disabling VHT
[ +0.006301] wlp166s0: send auth to 16:49:bc:41:87:60 (try 1/3)
[ +0.899069] iwlwifi 0000:a6:00.0: Not associated and the session protection is over already...
[ +0.000073] wlp166s0: Connection to AP 16:49:bc:41:87:60 lost
[ +1.162321] wlp166s0: send auth to 16:49:bc:41:87:60 (try 2/3)
[ +0.898955] iwlwifi 0000:a6:00.0: Not associated and the session protection is over already...
[ +0.000073] wlp166s0: Connection to AP 16:49:bc:41:87:60 lost
[ +1.116593] wlp166s0: send auth to 16:49:bc:41:87:60 (try 3/3)
[ +0.899123] iwlwifi 0000:a6:00.0: Not associated and the session protection is over already...
[ +0.000081] wlp166s0: Connection to AP 16:49:bc:41:87:60 lost
[ +0.024041] wlp166s0: aborting authentication with 16:49:bc:41:87:60 by local choice (Reason: 3=DEAUTH_LEAVING)
[ +3.767852] wlp166s0: authenticate with 16:49:bc:41:94:69
[ +0.000024] wlp166s0: 80 MHz not supported, disabling VHT
[ +0.006352] wlp166s0: send auth to 16:49:bc:41:94:69 (try 1/3)
[ +0.037856] wlp166s0: authenticated
[ +0.007792] wlp166s0: associate with 16:49:bc:41:94:69 (try 1/3)
[ +0.005390] wlp166s0: RX AssocResp from 16:49:bc:41:94:69 (capab=0x411 status=53 aid=6)
[ +0.000016] wlp166s0: 16:49:bc:41:94:69 denied association (code=53)
[ +0.044146] wlp166s0: authenticate with 16:49:bc:41:94:69
[ +0.000039] wlp166s0: 80 MHz not supported, disabling VHT
[ +0.005724] wlp166s0: send auth to 16:49:bc:41:94:69 (try 1/3)
[ +0.108466] wlp166s0: authenticate with 16:49:bc:41:94:69
[ +0.000016] wlp166s0: send auth to 16:49:bc:41:94:69 (try 1/3)
[ +0.106286] wlp166s0: authenticated
[ +0.001999] wlp166s0: associate with 16:49:bc:41:94:69 (try 1/3)
[ +0.013888] wlp166s0: RX AssocResp from 16:49:bc:41:94:69 (capab=0x411 status=0 aid=6)
[ +0.006902] wlp166s0: associated
[ +12.745241] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
Do the Limiting TX power to 30 (30 - 0) dBm as advertised by ... lines mean that powersaving hasn’t been disabled?
Scroll to If you’re dealing with lag or speed issues and paste the entire block of code into a terminal, press enter. Then please shot or copy paste the results.
Ignore wifi fixer script as it wouldn’t apply in this situation.
If you’re dual booting, heard Windows can do weird things to wifi state. But let’s start here first.
That code will give us a lot of helpful environmental background info on how your wifi card is behaving.
To check power saving state, drop this into a terminal.
Thanks for getting back to me. I didn’t know about that troubleshooting guide!
Is it normal to see Direct firmware load for iwlwifi-ty-a0-gf-a0-69.ucode failed with error -2 from dmesg during boot?
On 2.4GHz:
Interface: wlp166s0
Signal strength: -20
Signal quality: Mbit/s
Signal bars: ▂▄▆█
Wi-Fi Speed: 270 Mbit/s
Wi-Fi Channel: 1
Wi-Fi Noise, Link and Quality Level: Link: 70. Level: -20. Noise: -256
On 5GHz:
Interface: wlp166s0
Signal strength: -31
Signal quality: 270
Signal bars: ▂▄▆█
Wi-Fi Speed: 270 Mbit/s
Wi-Fi Channel: 36
Wi-Fi Noise, Link and Quality Level: Link: 70. Level: -30. Noise: -256
This is when the computer is less than a meter from this access point - VigorAP 903 | DrayTek
Speed tests are always very good, but the connection drops out roughly every 5-10 minutes which causes pings to fail. It seems to be more likely to occur when the connection is under more load.
I think it’s slightly more frequent on 5GHz but not by much. Most of the AP’s settings are on default: on 2.4GHz, channel width is auto (20/40MHz) but it always uses 20MHz with my computer; on 5GHz, channel width is auto (20/40/80MHz) and it always uses 80MHz with my computer.
sudo dmesg | grep microcode
Place your right index finger on the fingerprint reader
[ 0.000000] microcode: microcode updated early to revision 0x429, date = 2023-01-11
[ 1.761367] microcode: sig=0x906a3, pf=0x80, revision=0x429
[ 1.762014] microcode: Microcode Update Driver: v2.2
ls /lib/firmware | grep iwlwifi-ty-a0-gf-a0-69.ucode is empty
A couple of weeks ago I tried installing the linux-generic-hwe-22.04 and linux-modules-iwlwifi-generic-hwe-22.04 packages in the hope that it would help, but when it made no difference I removed them and went back to the OEM kernel. I haven’t installed any backports per see and haven’t installed any firmware directly.
I don’t know if this is related at all, but when I first got the computer I had a bizarre issue where the screen would flicker rapidly when the wifi card was under load, but only on Windows (never on Ubuntu), and only the internal screen (rather than one on HDMI).
On the recommendation of someone on the Framework support team, I reseated the wifi card and re-connected the antennas and connections and shielding around the monitor panel. This seemed to solve the flickering issue, but I wonder if there is something still underlying?
linux-oem-22.04 is already the newest version (5.17.0.1028.26)
In the first post on this thread I said
I tried some different kernel versions in the hope that it would solve the issue. It didn’t help so I’ve now removed them and gone back to the recommended OEM kernel.
Re-reading this, I don’t believe this would be the direct issue. With wifi, usually it’s either there or it’s not. Wifi drops, etc, are usually OS/power settings related.
In your case, your reported speed and signal strength looks fine. Visually speaking in terms of the reported output.
Your set up with power save being off, which should prevent drop off.
At this point, the next two things I’d do if this was my own system are:
I’d do speed testing on a completely unrelated network, to make sure there isn’t something else locally happening. This will feel silly, but I can tell you I’ve seen instances where every single device in a home works great, one doesn’t. Take said problem device to a new network, poof, problem isn’t there and the network was to blame. Causes varied in my experience from QoS to vlan stuff.
I’d also like to see this tested with a vanilla, standard uninstalled Live USB of Ubuntu. Just for a comparable. I’d like to see this tested on the existing network and also tested on literally any other network.
The goal here is to say whether or not this is a bad card, bad card connection, or something with the existing OS config.
Hi @Vilasamuni, just chiming in to try narrow down the issue, you said this is a dual boot setup? have you had the chance to use windows for 2 days or more to see if no dropouts happening on that side? Also have you tried other access points other than the ones you’re using now? Is it reproduceable when say, you’re using a mobile hotspot?
Thanks - I appreciate having some guidance to narrow down the variables. I’ve done testing on several different networks with a second laptop alongside my Framework. I was going in circles a bit because the issue is intermittent and only happens with particular combinations of hardware, software and AP.
Computer hardware
Operating System
Router/AP
WiFi stable?
Framework - 12th gen Intel CPU; Intel Wi-Fi 6 AX210
Ubuntu 22.04.2 - kernel 5.17.0-1028-oem
Draytek VigorAP 903
N
Framework - 12th gen Intel CPU; Intel Wi-Fi 6 AX210
Ubuntu 22.04.2 booted from Live USB - kernel 5.19.0-32-generic
Draytek VigorAP 903
N
Framework - 12th gen Intel CPU; Intel Wi-Fi 6 AX210
Windows 11
Draytek VigorAP 903
Y
Framework - 12th gen Intel CPU; Intel Wi-Fi 6 AX210
Ubuntu 22.04.2 - kernel 5.17.0-1028-oem
BT Hub 5
Y
Framework - 12th gen Intel CPU; Intel Wi-Fi 6 AX210
Ubuntu 22.04.2 booted from Live USB - kernel 5.19.0-32-generic
BT Hub 5
Y
Framework - 12th gen Intel CPU; Intel Wi-Fi 6 AX210
Windows 11
BT Hub 5
Y
Framework - 12th gen Intel CPU; Intel Wi-Fi 6 AX210
Ubuntu 22.04.2 - kernel 5.17.0-1028-oem
BT Hub 6
Y
Framework - 12th gen Intel CPU; Intel Wi-Fi 6 AX210
Ubuntu 22.04.2 booted from Live USB - kernel 5.19.0-32-generic
BT Hub 6
Y
Framework - 12th gen Intel CPU; Intel Wi-Fi 6 AX210
Windows 11
BT Hub 6
Y
Framework - 12th gen Intel CPU; Intel Wi-Fi 6 AX210
Ubuntu 22.04.2 - kernel 5.17.0-1028-oem
Netgear DGND3700v2
Y
Framework - 12th gen Intel CPU; Intel Wi-Fi 6 AX210
Ubuntu 22.04.2 booted from Live USB - kernel 5.19.0-32-generic
Netgear DGND3700v2
Y
Framework - 12th gen Intel CPU; Intel Wi-Fi 6 AX210
Windows 11
Netgear DGND3700v2
Y
Novatech Nspire - 11th gen Intel CPU; Intel Wireless-AC 9462
Ubuntu 22.04.2 - kernel
Draytek VigorAP 903
N
Novatech Nspire - 11th gen Intel CPU; Intel Wireless-AC 9462
Windows 11
Draytek VigorAP 903
Y
Novatech Nspire - 11th gen Intel CPU; Intel Wireless-AC 9462
Ubuntu 22.04.2 - kernel
BT Hub 5
Y
Novatech Nspire - 11th gen Intel CPU; Intel Wireless-AC 9462
Yeah that’s right. So it’s not an issue with only Framework hardware, but something to do with the combination of VigorAP 903 + Ubuntu (+ Intel WiFi card?). I opened a ticket with Draytek last week to see if they can help. They asked for more detail from me, but no solution yet.
Today I saw this in dmesg when I was doing a speed test over WiFi. This makes me wonder if there’s an issue with the firmware or the Intel WiFi driver in addition to something on the Draytek AP’s end. Have you seen anything like this before?
I’ve been in contact with an engineer from Draytek and we’ve identified that there’s an issue in the firmware on the VigorAP 903 which triggers when they’re set up in a particular way. We’ve found a workaround so it’s no longer a problem for me, and they’re probably going to release a firmware fix at some point. I think the Linux Intel driver/firmware could still do with some improvement though.
These APs support designating one of them as a ‘root’ AP to allow centralised management of up to 20 others without needing a stand-alone AP controller. All of the ‘child’ APs were disconnecting all their end users when AP management messages were being sent.
Other devices were being disconnected regularly as well - not just Framework and other Ubuntu machines - it’s just that the Windows and Mac machines were reconnecting much more gracefully whereas the Intel firmware/driver on Ubuntu was taking longer to reconnect, and sometimes giving up and trying other APs, and sometimes throwing errors like the one above.
How would I go about reporting this? Should it be reported to Canonical, Intel, or somewhere else?
Glad you found the solution to your AP issues, if it’s particularly an Ubuntu bug and you want to report it, you may want to do it on launchpad more info [here]
most likely report it against the kernel package, thank you for this effort.