[RESPONDED] FW13 Intel 13th Gen Linux 6.x Wifi Issue

Received my FW13, DIY 13th Gen Intel in Jul 23, installed Ubuntu 23.04 as per the recommended instructions, added my desired additional software. Every thing worked as expected, i was impressed, it is a “neat” unit. Took it on a touring holiday during Aug/Sep 23 where it was connected to numerous Hotel Wifi’s and my phone data hotspot when I required a more secure connection. Did NOT have any issues, and was impressed with the performance.
I used the laptop up until mid Dec 23 at home connecting to my home Wifi (2.4G only) without any problems. Over Xmas had family visiting and so did not use the laptop until mid Jan 24, as usual it notified me of pending updates which I promptly applied. This when I had the 1st Wifi connection delay of about 10 minutes when booting up the laptop. Over the next week the Wifi would delay connecting for anywhere between 5 minutes and 2 hours on bootup.
So I think is time to check is it HW or SW issue:

  • Wifi AP unit serves several mobile phones and 3 smart TV’s, none of which are having any issue, eliminate this as cause.
  • Try other OS:
    Using the SD card reader with a RescueZilla imaged SD card + USB hard drive I backed up the laptop and then fully installed and tested the following supported OS’s
  • Fedora 39 (Linux 6.7), Wifi connection delay varied between 2 and 17 minutes,
  • Ubuntu 22.04 LTS (Linux 6.1), aborted this test when Wifi had not connected after 30 minutes,
  • Upgraded the original Ubuntu 23.04 (Linux 6.1) to 23.10 (Linux 6.5), Wifi connection delay varied between 5 and over 30 minutes,
  • LinuxMint 21.2 (Linux 5.15), I tested before installing OEM kernel and did NOT have any delays over numerous reboots (I did backup of this install), I then installed the OEM kernel as per the recommended instructions (Linux 6.1) and immediately had delays from 4 to 15 minutes. From here I restored the backup I made (Linux 5.15) and did not have any further delays on bootup.
  • restore Ubuntu 23.10 setup, reboot, 6 minute delay, reboot, after 1 hour delay shutdown.

From the above I surmise this is a SW issue related to Linux 6.x versions as I could not replicate this problem when running LinuxMint with Linux 5.15, but did get the issue with ALL the Linux 6.x versions.
During the above testing I also ran packet captures on my LAN gateway/firewall server, during each of the connection delays the laptop was sending numerous DNS requests to the gateway which was responding to each DNS request with the appropriate info followed by several re-transmits. This behaviour looked like the laptop was sending DNS request and then ignoring the responses.

To recap:

  • this issue started after update in mid Jan 2024
  • Does NOT occur when running LinuxMint 21.2 (Linux 5.15)
  • Does occur for all Linux 6.x versions tested

My prefered OS at the moment is Ubuntu 23.10, but this is unusable with this issue.
I can use LinuxMint without the OEM kernel for basic stuff (eg email) and not have the screen brightness keys functioning.

Is anyone aware of a work around or fix, or even experienced similar?

Welcome to the community!

This is definitely feeling like there is a common theme among the distros/kernels tested. As you indicated, this could be a firmware issue…but, to see this happen on the OEM C kernel, which does work, indicates something else.

What wifi card are you using? I can see if I can replicate this. There may be a new firmware bug happening.

Just to chime in on here Issues with Linux Kernel 6.7.3 and 6.7.4 - Fedora Discussion I started this topic in the Fedora forums. I have been poking around, and trying to see if there are related issues. Wifi, and bluetooth seem to be frequently associated so far with the issues. The only reason I bring it up here is because Ubuntu backports a lot of stuff to their OEM kernels, which is why you could easily see changes to the 6.7 kernel filter back into the rest of the 6.* series on an Ubuntu or Ubuntu derivative.

In short I suspect this is more likely a kernel regressiion, and not a firmware issue. I will be concentrating on the 6.7 kernel when I dig into it, but if @Matt_Hartley is going to dedicate any effort into it I figured linking to the topic I created on the Fedora forums might be helpful as I am getting some hits over there from users experiencing some issues with it.

Note I experience no issues on older 6.* kernels but as noted Fedora does not backport. I am on Fedora 39 12th gen i7-1260p and using the stock AX210 Wireles Adapter. I do have some automation using tlp to turn bluetooth on or off and will play around with that to see if I can narror down the behavior as several bugs have already been filed regarding bluetooth.

Anyway not tryinig to clutter this thread with a different problem…but I suspect they are the same root cause. No linux-firmware updates on Fedora since January 24, but yesterdays kernel update definitely broke things. (FYI: I detailed my specific event on the Fedora forum, if @Matt_Hartley thinks it should either have it’s own topic here or add the details to this thread, please do so.)

Hi Mat
on LinuxMint the issue does NOT occur prior to installing the OEM C kernel, but does occur after installing the OEM C kernel.

New development, have reinstalled Ubuntu 23.10 saved image.
Was running for approx 1 hour without connection and using (or learning) the nmcli command options.
When i ran

> nmcli device wifi list

the wifi became responsive, my thought was WTF!
So retested, rebooted and retried, wifi responded after 3rd run of the above command.
Turned Wifi off, wait 30 seconds, Wifi On, retry Wifi respond after 2nd run.
Power down laptop, wait 30 seconds, startup, wait 5 minutes of no Wifi response, run above command, 4th try Wifi responds.
Turn Wifi Off, 30 seconds, Wifi On, retry command, Wifi responds after 2nd run.

I will now try this “trick” on the other OS images I have saved, I will report results in a few hours…

Hi Mat

The Wifi card is a AX210NGW, had to find the screw driver and lift the lid to see the card as I could not see any way to tell in SW.
Can’t tell if if its vPro or not, the market place images are identical and there is no indication on the card.
The laptop is FW13, 13th Gen Intel DIY unit, Batch 2. My “paper work” from Framework does not indicate which Wifi was included.

had to find the screw driver and lift the lid to see the card as I could not see any way to tell in SW.

For future reference, I think you should be able to use lspci, like this:

lspci -k | grep -A3 Network

The -k shows information about kernel modules.

If this doesn’t work for you, I’d be interested to know about that.

Thanks Aaron

lspci -k | grep -A3 Network


Intel Corporation Wi-Fi 6 AX210/AX211/AX411 160MHz (rev 1a)

No indication if vPro or not

1 Like

Further update
Original testing was done at about 8m from Wifi unit, with signal level around 90.
Testing at desk at about 3m from Wifi unit (signal level 95 to 97) I could NOT get the command

nmcli device wifi list

to trigger the Wifi to become responsive, I moved back to the prior location (at 8m) and the command worked on the 2nd attempt.
Next test, go to other end of house where signal strength is about 50, the Wifi connects immediately without running the nmcli command.

Could the signal strength be a cause inthis issue?

As promised earlier, I have tested this issue with other OS’s, and in consideration to my previous update I have included the Wifi Signal strength influence in my testing.
OS’s tested are:

  • Fedora 39 (Linux 6.7)
  • Ubuntu 22.04 LTS (Linux 6.1)
  • Ubuntu 23.10 (Linux 6.5), this is my preferred working system
  • LinuxMint 21.2 (Linux 5.15), WITHOUT the linux-oem-22.04c update
  • LinuxMint 21.2 with linux-oem-22.04c update (Linux 6.1)

Each OS was fully installed as per Framework guides, all had been backed up to USB hardrive and restored to the laptop using RescueZilla to eliminate any “Live” image influence.


  • LinuxMint with Linux 5.15 kernel
    This system had NO issues connecting the wifi, All attempts to connect did so without any delays, attempts where made in areas where the wifi signal strength was at (approx) 95%, 80% and 50%.
  • ALL the other OS’s tested that included Linux 6.x where consistant in their results in that the wifi signal strength was the main influence, as per:
    Above 90% - no connection was obtained irrelevant of any physical or SW actions.
    Around 80% - connection was made when laptop orientation was changed, eg physically rotated.
    Around 50% - connection was immediate, ie NO delay

Appologies for earlier suggestion about the nmcli command, I had the laptop on a board on a cushion on my knees when this was being tested and the movement when pressing the up arrow and enter key was sometimes adequate to change the orientation enough to initiate the connection.

To confirm my results I restored the Ubuntu 23.10 image onto the laptop and retested:

  • At 95% signal strength, I could not get the wifi to fully connect, several full slow rotations with up and down tilting had NO affect.
  • While moving to the 80% signal strength area the wifi connected, turn wifi off and then back on, the wifi did not connect until i performed a slow rotation, repeated this twice with the same result.
  • While moving to the 50% signal strength area the wifi connected, turned wifi off and then back on, the wifi connected immediately without any movement, repeated this twice with same result.

In all cases, once the wifi was connected I could return to the 95% signal strength area and the wifi would operate with out any problem.

So, until there is a solution to this issue, if I am at my desk and want wifi on the laptop I must take it to the other end of the room and dance with it OR take it to the other end of the house.

I’ll add this for some (?) context - on 13 AMD system, I’ve been seeing what I can best describe as WiFi throughput drop to about 10% of what other devices in the same vicinity report… (Ubuntu 22.04)… Going into settings and toggling “Airplaine Mode” on WiFi briefly restores throughput… This happens fairly regularly, often (when I notice it, I’d guess every hour or 2 of operation - it might be more frequently…)

And that is a completely different WiFi hardware set. FYI.

01:00.0 Network controller: MEDIATEK Corp. Device 0616
Subsystem: MEDIATEK Corp. Device e616
Kernel driver in use: mt7921e
Kernel modules: mt7921e

Hi Yarko
Did you note what the WiFi signal strength was when you have the issue, and does the behaviour change in areas with higher or lower signal strength (eg: 50%, 75%, 90+%)?

Today, it literally stopped working (no apparent WiFi connection) early after boot.
As usual, toggling “Airplane” mode briefly restores full operation. But how it degrades is unclear. Here’s just as I was replying:

yarko@yarko-ryzen-7040:~$ cat /proc/net/wireless
Inter-| sta-|   Quality        |   Discarded packets               | Missed | WE
 face | tus | link level noise |  nwid  crypt   frag  retry   misc | beacon | 22
wlp1s0: 0000   45.  -65.  -256        0      0      0      0     29        0

and here is immediately after toggling “Airplane” to restore full throughput:

arko@yarko-ryzen-7040:~$ cat /proc/net/wireless
Inter-| sta-|   Quality        |   Discarded packets               | Missed | WE
 face | tus | link level noise |  nwid  crypt   frag  retry   misc | beacon | 22
wlp1s0: 0000   70.  -39.  -256        0      0      0      0      0        0

This is at home. I’m on a mesh network - TP-Link Deco X60.
I notice (from iwconfig) that I seem to randomly connect to the 5GHz or 2.4GHz channels.

yarko@yarko-ryzen-7040:~$ iwconfig
lo        no wireless extensions.

wlp1s0    IEEE 802.11  ESSID:"xxxxxxx"  
          Mode:Managed  Frequency:5.18 GHz  Access Point: 40:3F:8C:75:57:BF   
          Bit Rate=1.2009 Gb/s   Tx-Power=3 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=68/70  Signal level=-42 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

Other devices in the same room (a windows HP laptop; a TV; a stereo amplifier; 2 smart phones) experience no such fluctuations (I often check my laptop’s behavior by looking at my iPhone, and running throughput and tests there - throughput fluctuation is not at the mesh network).

Also - signal strength checks do not reflect throughput tests.

Here’s a speed-tests:

and the corresponding command line indicators:

yarko@yarko-ryzen-7040:~$ iwconfig
lo        no wireless extensions.

wlp1s0    IEEE 802.11  ESSID:"xxxxxx"  
          Mode:Managed  Frequency:2.417 GHz  Access Point: 40:3F:8C:75:57:BE   
          Bit Rate=229.4 Mb/s   Tx-Power=3 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=69/70  Signal level=-41 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:6   Missed beacon:0

Toggling “Airplane mode” in WiFi settings results in this:

and this from the shell:

yarko@yarko-ryzen-7040:~$ iwconfig
lo        no wireless extensions.

wlp1s0    IEEE 802.11  ESSID:"xxxxxx"  
          Mode:Managed  Frequency:5.18 GHz  Access Point: 40:3F:8C:75:57:BF   
          Bit Rate=1.2009 Gb/s   Tx-Power=3 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=66/70  Signal level=-44 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:1   Missed beacon:0

that is, a shift from 2.4GHz to 5GHz connection, slightly worse and lower power signal (i.e. doesn’t make too much sense).

The reference speed from the same test site on iPhone produces:

which is roughly comperable (but with the AMD13 laptop slower > 20%).

I suppose I need to start this as a standalone problem report… Not sure if to do that here (community pages) or on a linux github page…

I’ll start here… (will repost my last replies here in a new thread this afternoon)…

Hi Yarko
I not sure your issue is the same as I have, I only have 2.4Ghz WiFi AP, so I can’t test for any band swapping, and I only have the problem when close (within 4-5m clear view) of the AP.

All, for our supported distros (Ubuntu LTS and Fedora 39) new firmware is available and addresses a known issue with some routers (specifically WiFi6E Drops).

UPDATED: For MediaTek on AMD only

Mint users, sorry, it’s ill-advised to try to use proposed repos on Mint - you will break stuff. Eventually, this firmware will make its way into Mint updates officially.

Fedora 39 users, just update, reboot.

Ubuntu 22.04.3 users, click the link above and use the oneliner provided, then reboot - reminder you should be on the OEM D kernel. Ideally OEM D, but OEM C is also fine.

Ubuntu 24.04 LTS will have this fix out of the box.

Intel users: 11th gen does not support 6E at this moment, but a fix is being looked into. 13th gen does, but if a card is not playing ball, we’d need to nail down which firmware is likely the culprit. Easiest thing to do at this stage is to test against Fedora 39 and see if the issue happens there. Same goes for testing against Ubuntu 24.04 dailies - this will have the bleeding edge firmware updates.

Hi Matt
The linked “fix” looks like it is only for the Mediatek hardware, can you please confirm.

I have converted to Debian 12 after learning of its availability and that others had successful installs on the FW13. I have had no issues other than similar results with the WiFi as per the other Linux flavours.

One slight improvement, I now also connect to a bluetooth sound system and on a cold boot the WiFi sometimes fully connects immediately. On a WiFi off/on cycle I still have to carry the laptop to the other end of the room to get full connection (full connection is confirmed by pinging the gateway/firewall server).

It is, yes, sorry, realizing now that we are talking Intel here (too many tabs open).

Updated this: [RESPONDED] FW13 Intel 13th Gen Linux 6.x Wifi Issue - #17

Reimaged laptop back to Ubuntu 23.10 (ready for Ubuntu 24.04 LTS release in April) and have WiFi connection problem worse than it was on Debian 12, I had to move to where the WiFi signal strength was around 50% before a full connection would occur.

I have just purchased a WiFi 6 Extender/AP/Router unit and set it up in AP mode, the laptop connects to this AP in 5G mode without any Issues. It seems like the January 2024 update only affected the connection process to older 2.4G WiFi AP units.