Bug after one of the latest updates -- no WLAN after resume

My E-OS install was working perfect over several months, but now, a real annoying bug has crept in. When the system goes to sleep and I wake it up, I cannot find my own WLAN anymore.

The weird thing is that the WLAN chooser (KDE) shows me all the other APs in the vicinity, just not my own. An ip addr shows that the interface is down (why does it show the other APs then?).

A reboot is needed to fix this, switching WLAN off and on doesn’t help.

However, when I switch to airplane mode before the system goes to sleep and switch airplane mode off after the system is back up, my AP is found and I have internet connectivity.

I don’t even know where to start debugging this.

Any ideas?

I had a vaguely similar problem recently.
Seems like I actually was just too impatient, since after waiting a few seconds more my wlan appeared again.

Your issue may be different. I guess since it worked several months, waiting for some new update should help.
In the meantime you could try the LTS kernel.

Perhaps details on your motherboard and network adaptors could assist initially.

inxi -Mnx --za

Details for this configuration:

Machine:
  Type: Laptop System: Dell product: Precision M4800 v: 00 serial: <filter>
  Mobo: Dell model: 077KCT v: A00 serial: <filter> UEFI: Dell v: A26
    date: 06/13/2019
Network:
  Device-1: Intel Ethernet I217-LM vendor: Dell driver: e1000e v: kernel
    port: f040 bus-ID: 00:19.0
  IF: eno1 state: down mac: <filter>
  Device-2: Intel Wi-Fi 6E AX210/AX1675 2x2 [Typhoon Peak] driver: iwlwifi
    v: kernel bus-ID: 03:00.0
  IF: wlan0 state: up mac: <filter>

Here the results of sudo dmesg | grep iwlwifi:

[    6.773333] iwlwifi 0000:03:00.0: enabling device (0000 -> 0002)
[    6.775720] iwlwifi 0000:03:00.0: Detected crf-id 0x400410, cnv-id 0x400410 wfpm id 0x80000000
[    6.775742] iwlwifi 0000:03:00.0: PCI dev 2725/0024, rev=0x420, rfid=0x10d000
[    6.775747] iwlwifi 0000:03:00.0: Detected Intel(R) Wi-Fi 6 AX210 160MHz
[    6.792041] iwlwifi 0000:03:00.0: TLV_FW_FSEQ_VERSION: FSEQ Version: 0.0.2.42
[    6.792773] iwlwifi 0000:03:00.0: loaded firmware version 89.6b44fa0b.0 ty-a0-gf-a0-89.ucode op_mode iwlmvm
[    7.236648] iwlwifi 0000:03:00.0: WFPM_UMAC_PD_NOTIFICATION: 0x20
[    7.236669] iwlwifi 0000:03:00.0: WFPM_LMAC2_PD_NOTIFICATION: 0x1f
[    7.236680] iwlwifi 0000:03:00.0: WFPM_AUTH_KEY_0: 0x90
[    7.236691] iwlwifi 0000:03:00.0: CNVI_SCU_SEQ_DATA_DW9: 0x0
[    7.237644] iwlwifi 0000:03:00.0: loaded PNVM version 16611aa6
[    7.252784] iwlwifi 0000:03:00.0: Detected RF GF, rfid=0x10d000
[    7.321230] iwlwifi 0000:03:00.0: base HW address: 38:87:d5:62:c4:d3
[    8.245014] iwlwifi 0000:03:00.0: WFPM_UMAC_PD_NOTIFICATION: 0x20
[    8.245035] iwlwifi 0000:03:00.0: WFPM_LMAC2_PD_NOTIFICATION: 0x1f
[    8.245046] iwlwifi 0000:03:00.0: WFPM_AUTH_KEY_0: 0x90
[    8.245061] iwlwifi 0000:03:00.0: CNVI_SCU_SEQ_DATA_DW9: 0x0
[    8.333097] iwlwifi 0000:03:00.0: Registered PHC clock: iwlwifi-PTP, with index: 1
[    8.560284] iwlwifi 0000:03:00.0: WFPM_UMAC_PD_NOTIFICATION: 0x20
[    8.560381] iwlwifi 0000:03:00.0: WFPM_LMAC2_PD_NOTIFICATION: 0x1f
[    8.560405] iwlwifi 0000:03:00.0: WFPM_AUTH_KEY_0: 0x90
[    8.560418] iwlwifi 0000:03:00.0: CNVI_SCU_SEQ_DATA_DW9: 0x0

I saw a linux firmware update among the latest updates. Maybe it makes sense to test an earlier firmware for the AX210. How do I force a specific firmware to be loaded?

This is an interesting thread:
[GUIDE] Possible solution for AX210 issues

It touches on two possible solutions to issues such as WiFi failure after resuming from suspend. The first is one from the Arch Wiki:

The second is an alternative solution, which is presented as a better option in the OP’s experience. If I understand the solution, you would edit /etc/modprobe.d/iwlwifi.conf, and insert the line:

options iwlwifi amsdu_size=4

Restart and see how it goes?

This has also fixed in the meantime, maybe the firmware update from Nov 18 was involved (the one before was only one week earlier).

The fix happened without any intervention besides the regular updates, which included the firmware update.

Closing this, it works now.

Sorry, can you clarify what fixed it? You’ve marked your last reply as the “Solution”. It fixed itself, post recent update?

The issue fixed itself without any intervention on my side. Most likely, the second firmware update was responsible. I didn’t apply the proposed solutions since they didn’t fit my specific issue – the WLAN in general was working, just not with the previously chosen AP.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.