Created attachment 283993 [details]
journal excerpt for intel 8265 NIC on iwd/networkd, iwlwifi debug=0x20

I am experiencing what seems to be the same issue on the intel 8265.

```
$ lspci -kvnn | sed -n '/Network/,/^$/ p'
02:00.0 Network controller [0280]: Intel Corporation Wireless 8265 / 8275 [8086:24fd] (rev 78)
	Subsystem: Intel Corporation Dual Band Wireless-AC 8265 [8086:1010]
	Flags: bus master, fast devsel, latency 0, IRQ 141
	Memory at edc00000 (64-bit, non-prefetchable) [size=8K]
	Capabilities: <access denied>
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi
```
In my experience the interface can remain stable for a long time, but occasionally will disconnect and then struggles to reassociate/authenticate for a while before becoming stable again. It sometimes records the 'no beacon heard' message and always disconnects with reason 4, being inactivity.

I'm using a different network stack, so I'll leave journal excerpts in case the iwd logging is more helpful. I've got some debugging set for iwlwifi as I was trying to debug my issue.

$ printf %#x\n $(cat /sys/module/iwlwifi/parameters/debug)
0x20

$ journalctl --boot=517d350fbd224b28a65e491ff95036db _KERNEL_DEVICE=+pci:0000:02:00.0 + _SYSTEMD_UNIT={iwd,systemd-network}.service
(attached)

forgot to mention -- in my case,

$ uname -r
5.2.2-arch1-1-ARCH

Can see this occuring Intel Corporation Wireless 7260 as well on `5.1.15-arch1-1-ARCH`.

It's happening also on my Intel 3165, even on Linux 5.0.

This could be related to TX-AMSDU, which we unfortunately had to disable for older devices.  Can you try this and see if it helps you with stability?

https://patchwork.kernel.org/patch/11029027/

Already used that patch compiling the kernel, but I had same issues.

If I'm not mistaken, patch 11029027 has been backported to the Arch core/linux since the release of version 5.2.arch2.

See here for the first appearance of the patch in Arch linux.git (v5.2, since 07/09): https://git.archlinux.org/linux.git/commit/?h=v5.2-arch2&id=f6f6b798c7330d7851fee4bbe835c3954886fc3f

Additionally see here for the inclusion of the patch in Arch linux.git (v5.2.2):  https://git.archlinux.org/linux.git/commit/?h=v5.2.2-arch1&id=d426d34276c9f17081179be6497cddd74154556a

Which means that the TX-AMSDU patch had already been applied when I encountered the error as I described above, and applied for the boot where my journal excerpt was taken and attached above.

Additionally, I have examples in my journal of what appears to be the same error (cycling disconnect with iwlwifi time event over already error) in 5.1.15-arch1, which predates the application of that patch, and another isolated example all the way back in 5.1.4-arch1 (a different AP as well), which predates the authorship of that patch. I can attach more logs if you would like.

So I have examples of the error with and without the patch.

For better or for worse, this error has somehow become much less common for me. The most recent example of the iwlwifi error for me was one spurious disconnect 1 week ago, in 5.2.7-arch1, even though I use this laptop every day.

Thanks kurmikon@libero.it! But your device is very different from Denis' and Ronan's... I think it would be best to create a new bug report here and provide all the logs we recommend in our wiki[1]

[1] https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging

Thanks for all the info, Ronan!

Can you also provide trace-cmd logs as explained in the wiki I linked in comment 9?

Okay, If I get the error again, I'll trace it.

I don't have a reliable way to reproduce atm, so if anyone experiencing this issue knows of a method that may trigger it, please let me know.

I've tried the patch suggested in comment 6 on top of vanilla 5.2.9 and the bug seems to be still there. Anything else to try? Should I provide the trace-cmd trace too?

Thanks for testing, Denis.

So, if the issue is not related, we could use some traces as mentioned in comment #9.

Created attachment 284575 [details]
iwlwifi trace (5.2.9 w/patch from comment 6)

I've generated a short trace during which there were a number of lost ICMP packets and messages from wpa_supplicant in the log. The kernel was 5.2.9 + patch from comment 6. The command used was

trace-cmd record -e iwlwifi -e mac80211 -e cfg80211 -e iwlwifi_msg

Thanks again.  We will assign someone internally to look into this.

Created attachment 284643 [details]
trace-cmd: Intel Corporation Wireless 7260 (rev 83)

Trace from Intel 7260 in ThinkPad T440s attached!

Created attachment 284645 [details]
Intel 7260 syslog accompanying the trace

This may help correlate timestamps in the trace.

Intel 7260 seems to be affected.

Linux version 5.2.9-arch1-1-ARCH (builduser@heftig-119803) (gcc version 9.1.0 (GCC)) #1 SMP PREEMPT Fri Aug 16 11:29:43 UTC 2019

Confirmed likely a software issue. Just installed another 7260 in same machine. Same issue.

The problem is still present in 5.3.0.

Maybe they're independent, but I've also seen multiple firmware errors in GEO_TX_POWER_LIMIT (looking like https://bugzilla.kernel.org/show_bug.cgi?id=204151) on 5.3 while checking for this bug.

The issue is that beacons are not received at the driver level.
Please provide the fw traces.
  
https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging#firmware_debugging

I've provided one for kernel 5.2.9 in comment 14. Anything that needs to be done differently, or just do the same on 5.3.latest?

Created attachment 285861 [details]
Core dump and syslog on Intel 7260

Here is a core dump from right after the issue occurred. Also includes a syslog from boot. 


Kernel 5.3.10 Arch Linux

Hopes this helps. Let me know if something is off with the dump as this is the first time I have done this.

This bug is still present in Linux 5.4.

I'm attaching a trace recorded on 5.4 with

trace-cmd record -e iwlwifi -e mac80211 -e cfg80211 -e iwlwifi_msg

The trace includes connecting to the WiFi network, staying on it for some time (with a few visible instances of this bug) and disconnecting.

Created attachment 286063 [details]
5.4.0: trace-cmd record -e iwlwifi -e mac80211 -e cfg80211 -e iwlwifi_msg

Ping. Is anything else I can help with?

Same problem here on a ThinkPad T470s (intel 8265). Latest checked kernel version was 5.5-rc3 on Opensuse Tumbleweed.

The same machine has a perfectly stable Wifi connection with Debian and kernel 4.19 (0.02% Packetloss during a 24h ping test) and had a stable connection on Tumbleweed with older kernels as well.

@Denis: it looks like we can't hear beacons at regular intervals.
We disconnected because we couldn't hear beacons from almost a second and then we couldn't re-connect because we couldn't hear beacons during the connection phase.
If you have the possibility to put another Intel Wifi device as an air sniffer, it'd allow us to know what's going on there.

@Nathaniel: thank you for providing the firmware dump, please re-do this with a debug version of the firmware:
https://wireless.wiki.kernel.org/_media/en/users/drivers/iwlwifi/iwlwifi-7260-17.ucode.gz

Thanks.

PS: if someone can reproduce this with an AX200 device it'd be interesting.
PS2: people who don't have AX200 can try to apply this and let me know how it goes:

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/time-event.c b/drivers/net/wireless/intel/iwlwifi/mvm/time-event.c
index 1babc4bb5194..02a38b9a3126 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/time-event.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/time-event.c
@@ -600,7 +600,7 @@ void iwl_mvm_protect_session(struct iwl_mvm *mvm,
        time_cmd.action = cpu_to_le32(FW_CTXT_ACTION_ADD);
        time_cmd.id_and_color =
                cpu_to_le32(FW_CMD_ID_AND_COLOR(mvmvif->id, mvmvif->color));
-       time_cmd.id = cpu_to_le32(TE_BSS_STA_AGGRESSIVE_ASSOC);
+       time_cmd.id = cpu_to_le32(TE_BSS_STA_ASSOC);
 
        time_cmd.apply_time = cpu_to_le32(0);
 
@@ -608,7 +608,7 @@ void iwl_mvm_protect_session(struct iwl_mvm *mvm,
        time_cmd.max_delay = cpu_to_le32(max_delay);
        /* TODO: why do we need to interval = bi if it is not periodic? */
        time_cmd.interval = cpu_to_le32(1);
-       time_cmd.duration = cpu_to_le32(duration);
+       time_cmd.duration = cpu_to_le32(1000);
        time_cmd.repeat = 1;
        time_cmd.policy = cpu_to_le16(TE_V2_NOTIF_HOST_EVENT_START |
                                      TE_V2_NOTIF_HOST_EVENT_END |

AX200 here.
I replaced my 8265ngw with an AX200ngw hoping it would solve the problem.

It happens less frequently now with the AX200, and it is always able to reconnect within a few seconds. But it still happens.



>Jan 21 08:17:08 kernel: iwlwifi 0000:04:00.0: No beacon heard and the time
>event is over already...
>Jan 21 08:17:08 kernel: wlan0: Connection to AP XXX lost
>Jan 21 08:17:08  iwd[680]: Received Deauthentication event, reason: 4,
>from_ap: XXX false
>Jan 21 08:17:08 kernel: wlan0: authenticate with XXX
>Jan 21 08:17:08 kernel: wlan0: send auth to XXX (try 1/3)
>Jan 21 08:17:08 kernel: wlan0: authenticated
>Jan 21 08:17:08 kernel: wlan0: associate with XXX (try 1/3)
>Jan 21 08:17:08 kernel: wlan0: RX AssocResp from XXX (capab=0x811 status=0
>aid=3)
>Jan 21 08:17:08 kernel: wlan0: associated
>Jan 21 08:17:09 kernel: iwlwifi 0000:04:00.0: No beacon heard and the time
>event is over already...
>Jan 21 08:17:09 kernel: wlan0: Connection to AP XXX lost
>Jan 21 08:17:09 iwd[680]: Received Deauthentication event, reason: 4, from_ap:
>false
>Jan 21 08:17:09 kernel: wlan0: authenticate with XXX
>Jan 21 08:17:09 kernel: wlan0: send auth to XXX (try 1/3)
...
...

Hi,

What firmware version do you use?

iwlwifi 0000:04:00.0: loaded firmware version 50.3e391d3e.0 op_mode iwlmvm
iwlwifi 0000:04:00.0: Detected Intel(R) Wi-Fi 6 AX200 160MHz, REV=0x340

Ok, this doesn't include our new flow in the firmware that can help.

Can you try the patch I attached to simulate this in the driver?

Thanks.

Hi,

did you have a chance to test the patch?

I'm trying to establish some kind of baseline behaviour so that I'll know whether the patch worked or not. The bug hasn't reappeared in several days. I'm wondering if there is some kind of stress I can apply that might trigger it.

What's the simplest way to apply the patch on my Arch Linux system?

I guess the easiest may be to install our backport based driver. Then you can use our latest firmware.

You can take the master branch of:
https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/core_release

Let me know if you want to do this.

I don't understand the reason, but at the moment I'm unable to reliably reproduce this problem on any of the kernels that used to display it. Will stay on mainline kernels for now and report when (if) the problem reproduces itself.

My bet is that this problem is more related to the AP than to our device. But I can't prove this obviously. I do would like to get some testing on the patch.
For AX200 this code has been moved to the firmware and newest firmware (not publicly available) includes this new behavior.

May be the case. However, when 5.1 came, it really felt like a regression, so I'd say that this particular problem was something that 5.0 handled better than 5.1.

That would be really strange..
Still no luck on reproduction ?

Hi,

I've been observing similar error messages with "Intel Corporation Wireless 7265 (rev 59)" since Linux 5.1. The behavior is similar to comment #2, it can work for hours and then enters a sequence of rapid disconnects.

I'll try to provide firmware logs later, but for now I've found that changing "Beacon Interval" from the default 100 ms to 50 ms on my OpenWrt AP fixes the problem. Perhaps this information is useful.

Hi Andrey,

do you have additional system with Linux and an Intel WiFi device?

If set, I'd like you to try to record an air sniffer capture of the connection.

You shouldn't have to reduce the beacon interval.
Have you tried my patch from comment #28?

In my case the patch helped a lot. However: the first time I've tried it I observed quite bad ping times (sometimes up to 20 seconds when pinging the AP) but as soon as I plugged-in the power supply it went down to 0.8ms...

Maybe either a PM or an electrical grounding issue, who knows... Never happened again since then.

@pirmin, do you have an additional Intel Wifi device on a Linux machine?
I'd like to get an Air sniffer of the connection.
Typically, it should work properly without my patch. I'd like to understand *why* it is needed.

@Emmanuel

unfortunatelly not, no.

@Emmanuel I believe I'm experiencing this issue and I have multiple linux machines with Intel Wifi adapters. I'm happy to help if you can walk me through sniffing traffic to collect the data you're looking for.

@Mike, great.
First we need to determine the channel of your AP, for this, do:
iw <iface name> link.

Then you can refer to https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging#air_sniffing
Try to collect a pcap file on your AP's channel just to see that things are working.
You can send me the file or attach it here.

Next step will be to do an air capture while the bug is happening.

(In reply to Emmanuel Grumbach from comment #41)

Unfortunately, I have only one such machine.

I restored Beacon Interval to 100 ms on my AP, and successfully reproduced the problem with Linux 5.5.2 and firmware version 29.163394017.0 on Intel 7265 card.

Then I applied the patch from comment #28, and within a day could still reproduce the problem. In the logs I noticed also a few new "Time Event [start|end] notification failure" messages, which sometimes occurred between "No beacon heard" messages.

[  +0,820074] wlan0: authenticate with b0:48:7a:c2:7f:16
[  +0,005267] wlan0: send auth to b0:48:7a:c2:7f:16 (try 1/3)
[  +0,003479] wlan0: authenticated
[  +0,004186] wlan0: associate with b0:48:7a:c2:7f:16 (try 1/3)
[  +0,003872] wlan0: RX AssocResp from b0:48:7a:c2:7f:16 (capab=0x431 status=0 aid=2)
[  +0,001171] wlan0: associated
[  +0,008698] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  +0,282995] iwlwifi 0000:02:00.0: Time Event end notification failure
[  +0,000026] wlan0: Connection to AP b0:48:7a:c2:7f:16 lost
[  +0,120978] iwlwifi 0000:02:00.0: Time Event start notification failure
[  +0,158990] wlan0: Connection to AP 00:00:00:00:00:00 lost
[  +1,032228] wlan0: authenticate with b0:48:7a:c2:7f:16
[  +0,004169] wlan0: send auth to b0:48:7a:c2:7f:16 (try 1/3)
[  +0,001163] iwlwifi 0000:02:00.0: Time Event end notification failure
[  +0,000023] wlan0: Connection to AP b0:48:7a:c2:7f:16 lost
[  +1,204168] wlan0: send auth to b0:48:7a:c2:7f:16 (try 2/3)
[  +0,001942] wlan0: authenticated
[  +0,002892] wlan0: associate with b0:48:7a:c2:7f:16 (try 1/3)
[  +0,001817] wlan0: RX AssocResp from b0:48:7a:c2:7f:16 (capab=0x431 status=0 aid=2)
[  +0,001030] wlan0: associated
[  +0,009735] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  +1,006093] iwlwifi 0000:02:00.0: No beacon heard and the time event is over already...
[  +0,000083] wlan0: Connection to AP b0:48:7a:c2:7f:16 lost

Note that now the "No beacon heard" message occurs around 1 s after the initial connection, I suppose in accordance with the patch.

I have a Samsung laptop with an Intel 8260 card. I run Arch Linux. Since Arch upgraded to kernel 5.5 I have no wifi, unless I boot into the LTS kernel. 

dmesg info is available at https://pastebin.com/LY771WXg

Additional information: 

┌─[cribari @ darwin5r ~]
└─╼ uname -a
Linux darwin5r 5.5.2-arch2-2 #1 SMP PREEMPT Wed, 05 Feb 2020 22:01:13 +0000 x86_64 GNU/Linux

┌─[cribari @ darwin5r ~]
└─╼ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 98:83:89:ca:d7:fc brd ff:ff:ff:ff:ff:ff
┌─[cribari @ darwin5r ~]
└─╼ 

┌─[cribari @ darwin5r ~]
└─╼ inxi -N
Network:
  Device-1: Intel Wireless 8260 driver: iwlwifi 
  Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet 
  driver: r8169

This is absolutely not related to this bug.

Created attachment 287507 [details]
log of AX200

Having the same here with an AX200.

Linux Helena 5.5.4-arch1-1 #1 SMP PREEMPT
05:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a)
iwlwifi 0000:05:00.0: loaded firmware version 50.3e391d3e.0 op_mode iwlmvm
CISCO based infrastructure, EAP-TLS with FT-EAP enabled. 5GHz

Strangely it startet at 00:00:09. System might have been a little busy as logrotate and some other things happen at 00:00? Uptime was roundabout ~14h till it happened.

Kept continuing till someone restarted the system but re-appeared 2:30 later


===

Feb 19 00:00:08 Helena kernel: wlp5s0: associate with 00:a7:42:ea:25:cf (try 1/3)
Feb 19 00:00:08 Helena kernel: wlp5s0: RX ReassocResp from 00:a7:42:ea:25:cf (capab=0x1111 status=0 aid=31)
Feb 19 00:00:08 Helena kernel: wlp5s0: associated 
Feb 19 00:00:09 Helena kernel: iwlwifi 0000:05:00.0: No beacon heard and the time event is over already...
Feb 19 00:00:09 Helena kernel: wlp5s0: Connection to AP 00:a7:42:ea:25:cf lost
Feb 19 00:00:09 Helena kernel: iwlwifi 0000:05:00.0: expected hw-decrypted unicast frame for station
Feb 19 00:00:09 Helena kernel: iwlwifi 0000:05:00.0: expected hw-decrypted unicast frame for station
Feb 19 00:00:09 Helena kernel: iwlwifi 0000:05:00.0: expected hw-decrypted unicast frame for station

I've seen some channel-freq-change stuff in wpa_supplicant debug log, while that error occured. Maybe it's somehow related:


1582110704.979768: nl80211: Ignored event 110 (NL80211_CMD_UNKNOWN) for foreign interface (ifindex 8 wdev 0x0)
1582110704.979778: nl80211: Drv Event 110 (NL80211_CMD_UNKNOWN) received for wlp5s0
1582110704.979784: nl80211: Channel switch started event
1582110704.979796: wlp5s0: Event CH_SWITCH_STARTED (39) received
1582110704.979813: wlp5s0: CTRL-EVENT-STARTED-CHANNEL-SWITCH freq=5220 ht_enabled=1 ch_offset=1 ch_width=80 MHz cf1=5210 cf2=0
1582110706.596660: nl80211: Event message available
1582110706.596714: nl80211: Ignored event 64 (NL80211_CMD_NOTIFY_CQM) for foreign interface (ifindex 8 wdev 0x0)
1582110706.596723: nl80211: Drv Event 64 (NL80211_CMD_NOTIFY_CQM) received for wlp5s0
1582110706.596729: nl80211: Beacon loss event
1582110706.596738: wlp5s0: Event BEACON_LOSS (53) received
1582110706.596750: wlp5s0: CTRL-EVENT-BEACON-LOSS 

...

1582110711.238897: BSS: 6c:8b:d3:61:7b:4f changed freq 5220 --> 5200
1582110711.238910: BSS: 6c:8b:d3:61:7b:4f has multiple entries in the scan results - select the most current one

Same here on Fedora 31.

~ $ uname -a
Linux hp-spectre-x360 5.4.19-200.fc31.x86_64 #1 SMP Wed Feb 12 15:21:24 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux


~ $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 4c:34:88:94:2c:f3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.3/24 brd 192.168.1.255 scope global dynamic noprefixroute wlo1
       valid_lft 84056sec preferred_lft 84056sec
    inet6 2a02:2149:8487:8e00:be2e:dda1:1833:bdba/64 scope global dynamic noprefixroute 
       valid_lft 86151sec preferred_lft 42951sec
    inet6 fe80::dbcd:d6d3:ad84:1d6e/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever


~ $ inxi -N
Network:   Device-1: Intel Wireless 7265 driver: iwlwifi 


~ $ journalctl | grep wpa_supplicant

Feb 19 11:25:14 hp-spectre-x360 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=wpa_supplicant comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 19 11:25:14 hp-spectre-x360 wpa_supplicant[998]: Successfully initialized wpa_supplicant
Feb 19 11:25:14 hp-spectre-x360 NetworkManager[944]: <info>  [1582104314.6416] supplicant: wpa_supplicant running
Feb 19 11:25:18 hp-spectre-x360 wpa_supplicant[998]: wlo1: CTRL-EVENT-REGDOM-CHANGE init=DRIVER type=COUNTRY alpha2=GR
Feb 19 11:25:19 hp-spectre-x360 wpa_supplicant[998]: wlo1: SME: Trying to authenticate with 34:4d:ea:95:5d:14 (SSID='Forthnet-4jPPK' freq=2412 MHz)
Feb 19 11:25:19 hp-spectre-x360 wpa_supplicant[998]: wlo1: Trying to associate with 34:4d:ea:95:5d:14 (SSID='Forthnet-4jPPK' freq=2412 MHz)
Feb 19 11:25:19 hp-spectre-x360 wpa_supplicant[998]: wlo1: Associated with 34:4d:ea:95:5d:14
Feb 19 11:25:19 hp-spectre-x360 wpa_supplicant[998]: wlo1: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Feb 19 11:25:19 hp-spectre-x360 wpa_supplicant[998]: wlo1: WPA: Key negotiation completed with 34:4d:ea:95:5d:14 [PTK=CCMP GTK=CCMP]
Feb 19 11:25:19 hp-spectre-x360 wpa_supplicant[998]: wlo1: CTRL-EVENT-CONNECTED - Connection to 34:4d:ea:95:5d:14 completed [id=0 id_str=]
Feb 19 11:25:19 hp-spectre-x360 wpa_supplicant[998]: wlo1: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-39 noise=9999 txrate=1000
Feb 19 11:25:23 hp-spectre-x360 wpa_supplicant[998]: wlo1: WPA: Group rekeying completed with 34:4d:ea:95:5d:14 [GTK=CCMP]
Feb 19 11:28:01 hp-spectre-x360 wpa_supplicant[998]: wlo1: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-44 noise=9999 txrate=270000
Feb 19 11:35:22 hp-spectre-x360 wpa_supplicant[998]: wlo1: WPA: Group rekeying completed with 34:4d:ea:95:5d:14 [GTK=CCMP]
Feb 19 11:41:48 hp-spectre-x360 wpa_supplicant[998]: wlo1: CTRL-EVENT-BEACON-LOSS
Feb 19 11:41:50 hp-spectre-x360 wpa_supplicant[998]: wlo1: CTRL-EVENT-BEACON-LOSS
Feb 19 11:41:51 hp-spectre-x360 wpa_supplicant[998]: wlo1: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=0 noise=9999 txrate=0
Feb 19 11:41:51 hp-spectre-x360 wpa_supplicant[998]: wlo1: CTRL-EVENT-DISCONNECTED bssid=34:4d:ea:95:5d:14 reason=4 locally_generated=1
Feb 19 11:41:51 hp-spectre-x360 wpa_supplicant[998]: dbus: wpa_dbus_property_changed: no property SessionLength in object /fi/w1/wpa_supplicant1/Interfaces/0

Had been facing the same disconnects (every few minutes) since I replaced a Qualcomm WiFi card with an AX200 on the other day. Using Ubuntu 19.10 and kernel 5.3, getting the same "No beacon heard and the time event is over already" messages and often failing to authenticate as well. After resuming from sleep, it was almost impossible to have working WiFi even for a few minutes, requiring a reboot but also facing new issues after a few minutes. However, I have fixed the issue by disabling ipv6 for the WiFi connection in NetworkManager, as I've seem somebody suggest in some other forum. Haven't noticed a single disconnect/issue ever since, even after resuming from sleep.

(In reply to Danilo Cominotti Marques from comment #53)
> Had been facing the same disconnects (every few minutes) since I replaced a
> Qualcomm WiFi card with an AX200 on the other day. Using Ubuntu 19.10 and
> kernel 5.3, getting the same "No beacon heard and the time event is over
> already" messages and often failing to authenticate as well. After resuming
> from sleep, it was almost impossible to have working WiFi even for a few
> minutes, requiring a reboot but also facing new issues after a few minutes.
> However, I have fixed the issue by disabling ipv6 for the WiFi connection in
> NetworkManager, as I've seem somebody suggest in some other forum. Haven't
> noticed a single disconnect/issue ever since, even after resuming from sleep.

Obs.: Have disabled ipv6 *and* set the 5GHz network in the AP to a fixed (39) channel.

My 7260 on ThinkPad T440 also started to go into disconnecting rage once in a while ever since I upgraded from 4.19.x to 5.5.x kernel.

(In reply to WGH from comment #55)
> My 7260 on ThinkPad T440 also started to go into disconnecting rage once in
> a while ever since I upgraded from 4.19.x to 5.5.x kernel.

Same for me
Network controller: Intel Corporation Wireless 7265 (rev 59)
on my T450s

Same here for Network controller: Intel Corporation Wireless 7260 (rev 83), kernel 5.5.5, but it has been the same for months with the current kernel version. Though the disconnecting problems are not as severe and frequent as it was the case a while back.

Been seeing the same issue since kernel 5.1 on Arch Linux.

~ lspci | rg Wireless
02:00.0 Network controller: Intel Corporation Wireless 3165 (rev 79)
~ uname -a
Linux ph 5.5.4-arch1-1 #1 SMP PREEMPT Sat, 15 Feb 2020 00:36:29 +0000 x86_64 GNU/Linux

The frequency of this occurring reduced a lot after I switched to channel 11 (from 9). I don't have an air sniffing log, but I don't think this is an AP issue as my Android phone stays connected to the same AP while this happens. I do however note that this happens only when my laptop is charging (may just be a coincidence, though, as the problem persists for a while even if I remove the charging cable).

Restarting wpa_supplicant a bunch of times usually fixes it for me. Happy to provide any other info I can.

Same issue here starting from 5.5.* kernels onward.

WiFi card: Intel(R) Dual Band Wireless AC 8265, REV=0x230

Description of the observed issue:
- random instability of the WiFi connection: from time to time bursts of ping to the AP are lost or have high delay (> 1000msec)
- noticeable regression (wrt 5.4.* kernels) in the transfer speed (expecially tx) with low signal (< -73dBM, as reported by iw). This is easily reproducible for me.

Bisected 5.5.1 kernel and found the commit causing the regression:
39c1a9728f93 iwlwifi: refactor the SAR tables from mvm to acpi

Recompiled kernel 5.5.9 reverting the commit (and conflicting ones).
Reverted:
8f5c78a456e2 Revert "iwlwifi: fw: make pos static in iwl_sar_get_ewrd_table() loop"
2f0a482f683d Revert "iwlwifi: mvm: fix non-ACPI function"
39c1a9728f93 iwlwifi: refactor the SAR tables from mvm to acpi

Issue is fixed. With low signal (<= -72) transfer speed is comparable to 5.4.x kernels. Loading the iwlwifi and iwlmvm modules with and without the patch, immediately shows the difference with low signal (< 73 dBM).

Tried to investigate 39c1a9728f93, spent much time: cannot real spot the problem, seems just a migration of the functions from mvm/fw.c to the acpi.c.

Please, help! :-)

Created attachment 288091 [details]
Reverted SAR refactor patch for kernel 5.5.9

Applying this patch (which just reverts SAR refactor patch) to a 5.5.z kernel series (tried with 5.5.1 and 5.5.9) brings back stability and performance in low signal conditions as available in 5.4.z kernels.

(In reply to Francesco Giudici from comment #60)
> Created attachment 288091 [details]
> Reverted SAR refactor patch for kernel 5.5.9
> 
> Applying this patch (which just reverts SAR refactor patch) to a 5.5.z
> kernel series (tried with 5.5.1 and 5.5.9) brings back stability and
> performance in low signal conditions as available in 5.4.z kernels.

Hi, I applied the patch to kernel 5.5.9 (Arch Linux) but I’m still getting random disconnects with the “No beacon heard” message with Intel Corporation Wireless 7260 (rev 83).

(In reply to Andre Jonas from comment #61)
> (In reply to Francesco Giudici from comment #60)
> > Created attachment 288091 [details]
> > Reverted SAR refactor patch for kernel 5.5.9
> > 
> > Applying this patch (which just reverts SAR refactor patch) to a 5.5.z
> > kernel series (tried with 5.5.1 and 5.5.9) brings back stability and
> > performance in low signal conditions as available in 5.4.z kernels.
> 
> Hi, I applied the patch to kernel 5.5.9 (Arch Linux) but I’m still getting
> random disconnects with the “No beacon heard” message with Intel Corporation
> Wireless 7260 (rev 83).

Thanks for giving it a try. I can confirm the patch fixes the issues with my wifi card (Intel(R) Dual Band Wireless AC 8265, REV=0x230)... but clearly this is another issue then. Sorry, didn't wanted to bring more confusion here. I will open another bug.

Same issue here on gentoo-NB 5.4.28-gentoo.
I have two box with iwlwifi with different wifi cards and the error is the same in both cards.

iwlwifi 0000:03:00.0: No beacon heard and the time event is over already...
wlp3s0: Connection to AP e4:8d:8c:e2:ff:08 lost
wlp3s0: authenticate with e4:8d:8c:e2:ff:08
wlp3s0: send auth to e4:8d:8c:e2:ff:08 (try 1/3)
wlp3s0: authenticated
wlp3s0: associate with e4:8d:8c:e2:ff:08 (try 1/3)
wlp3s0: RX AssocResp from e4:8d:8c:e2:ff:08 (capab=0x431 status=0 aid=2)
wlp3s0: associated
wlp3s0: Connection to AP e4:8d:8c:e2:ff:08 lost
wlp3s0: authenticate with e4:8d:8c:e2:ff:08
wlp3s0: send auth to e4:8d:8c:e2:ff:08 (try 1/3)
wlp3s0: authenticated
wlp3s0: associate with e4:8d:8c:e2:ff:08 (try 1/3)
wlp3s0: RX AssocResp from e4:8d:8c:e2:ff:08 (capab=0x431 status=0 aid=2)
wlp3s0: associated
iwlwifi 0000:03:00.0: No beacon heard and the time event is over already...
wlp3s0: Connection to AP e4:8d:8c:e2:ff:08 lost
wlp3s0: authenticate with e4:8d:8c:e2:ff:08
wlp3s0: send auth to e4:8d:8c:e2:ff:08 (try 1/3)
wlp3s0: authenticated
wlp3s0: associate with e4:8d:8c:e2:ff:08 (try 1/3)
wlp3s0: RX AssocResp from e4:8d:8c:e2:ff:08 (capab=0x431 status=0 aid=2)
wlp3s0: associated
iwlwifi 0000:03:00.0: No beacon heard and the time event is over already...
wlp3s0: Connection to AP e4:8d:8c:e2:ff:08 lost
wlp3s0: authenticate with e4:8d:8c:e2:ff:08
wlp3s0: send auth to e4:8d:8c:e2:ff:08 (try 1/3)
wlp3s0: authenticated
wlp3s0: associate with e4:8d:8c:e2:ff:08 (try 1/3)
wlp3s0: RX AssocResp from e4:8d:8c:e2:ff:08 (capab=0x431 status=0 aid=2)
wlp3s0: associated
wlp3s0: Connection to AP e4:8d:8c:e2:ff:08 lost
wlp3s0: authenticate with e4:8d:8c:e2:ff:08
wlp3s0: send auth to e4:8d:8c:e2:ff:08 (try 1/3)
wlp3s0: authenticated
wlp3s0: associate with e4:8d:8c:e2:ff:08 (try 1/3)
wlp3s0: RX AssocResp from e4:8d:8c:e2:ff:08 (capab=0x431 status=0 aid=2)
wlp3s0: associated
wlp3s0: Connection to AP e4:8d:8c:e2:ff:08 lost
wlp3s0: authenticate with e4:8d:8c:e2:ff:08
wlp3s0: send auth to e4:8d:8c:e2:ff:08 (try 1/3)
wlp3s0: authenticated

Any workaround?
Regards.

Exactly the same here: https://bbs.archlinux.org/viewtopic.php?pid=1901025#p1901025, I really don't know what to do next.

I am on Arch Linux, linux 5.6.6, wpa_supplicant 2.9-7.

I have the same issue - it was working fine with 4.19 but no good with 5.4. Also I could give you a hint what might triggers this - I was using wifi analyzer app on my other device (Android) to scan for the channels and it appears it triggers the issue easily.

[328060.858996] iwlwifi 0000:04:00.0: No beacon heard and the time event is over already...
[328060.859005] wlp4s0: Connection to AP f4:f2:6d:c2:01:16 lost
[328064.334373] wlp4s0: authenticate with f4:f2:6d:c2:01:16
[328064.336691] wlp4s0: send auth to f4:f2:6d:c2:01:16 (try 1/3)
[328064.340536] wlp4s0: authenticated
[328064.344626] wlp4s0: associate with f4:f2:6d:c2:01:16 (try 1/3)
[328064.349165] wlp4s0: RX AssocResp from f4:f2:6d:c2:01:16 (capab=0x431 status=0 aid=1)
[328064.349993] wlp4s0: associated
[328113.788236] wlp4s0: Connection to AP f4:f2:6d:c2:01:16 lost
[328117.219951] wlp4s0: authenticate with f4:f2:6d:c2:01:16
[328117.221941] wlp4s0: send auth to f4:f2:6d:c2:01:16 (try 1/3)
[328117.225417] wlp4s0: authenticated
[328117.232304] wlp4s0: associate with f4:f2:6d:c2:01:16 (try 1/3)
[328117.236907] wlp4s0: RX AssocResp from f4:f2:6d:c2:01:16 (capab=0x431 status=0 aid=1)
[328117.237751] wlp4s0: associated
[328117.836053] iwlwifi 0000:04:00.0: No beacon heard and the time event is over already...
[328117.836064] wlp4s0: Connection to AP f4:f2:6d:c2:01:16 lost
[328121.302118] wlp4s0: authenticate with f4:f2:6d:c2:01:16
[328121.304557] wlp4s0: send auth to f4:f2:6d:c2:01:16 (try 1/3)
[328121.308252] wlp4s0: authenticated
[328121.312279] wlp4s0: associate with f4:f2:6d:c2:01:16 (try 1/3)
[328121.316874] wlp4s0: RX AssocResp from f4:f2:6d:c2:01:16 (capab=0x431 status=0 aid=1)
[328121.329829] wlp4s0: associated

anybody has a fix for this?? Its been there for last 6months.I had to switch to windows to be productive,Couldn't use my Linux system more than 10min without being disconneted from WIFI.

I don't think there is any fix yet :-( . I am now on 5.7.2 (Arch Linux) and the problem is still there.

It has `NEEDSINFO` status - what info is needed please?

For the people on Arch, obviously it's not a permanent fix, but I downgraded to the Arch Linux LTS kernel (5.4.41) around a month ago and haven't observed the issue since.

Using Arch linux-hardened (5.6.18.a-1-hardened); The issue has not been 
observed since my AP's beacon interval was increased to 50ms. It was 
mentioned by someone here as a workaround.

On 6/17/20 10:24 AM, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=203709
>
> --- Comment #69 from mikezackles@gmail.com ---
> For the people on Arch, obviously it's not a permanent fix, but I downgraded
> to
> the Arch Linux LTS kernel (5.4.41) around a month ago and haven't observed
> the
> issue since.
>

It's observed on Debian , Ubuntu all other distros not only  on Arch Linux.

I downgraded to 5.4.46-1 on Archlinux too and it seems it doesn't happen there indeed.

I actually observed the issue happening last night (again on Arch LTS 5.4.41-1), but it eventually managed to connect after a minute or two. So it seems like the issue is still present with this kernel, but perhaps less severe, as my wifi became unusable for long periods of time with the default Arch kernel (independent of reboots).

If you're using networkmanager , it tries to autoconnect to the wireless AP, but if you're using iwd or wpa supplicant youre out of luck.

OK, sorry for the confusion, I confirm it happens on 5.4 too :-(

Same thing happening on my Dell XPS 7590 using Killer Wi-Fi 6 AX1650 (see Bug 208425):
[52529.973261] iwlwifi 0000:3b:00.0: No beacon heard and the session protection is over already...
[52529.973354] wlp59s0: Connection to AP ac:22:05:83:cd:8d lost
[52530.330451] wlp59s0: send auth to ac:22:05:83:cd:8d (try 2/3)
[52531.226916] wlp59s0: send auth to ac:22:05:83:cd:8d (try 3/3)
[52532.125912] iwlwifi 0000:3b:00.0: No beacon heard and the session protection is over already...
[52532.125955] wlp59s0: Connection to AP ac:22:05:83:cd:8d lost
[52532.217812] wlp59s0: authentication with ac:22:05:83:cd:8d timed out
[52542.252729] wlp59s0: authenticate with ac:22:05:83:ce:3c
[52542.258736] wlp59s0: send auth to ac:22:05:83:ce:3c (try 1/3)
[52543.158015] iwlwifi 0000:3b:00.0: No beacon heard and the session protection is over already...
[52543.158106] wlp59s0: Connection to AP ac:22:05:83:ce:3c lost
[52543.210675] wlp59s0: send auth to ac:22:05:83:ce:3c (try 2/3)
[52544.109377] iwlwifi 0000:3b:00.0: No beacon heard and the session protection is over already...
[52544.109477] wlp59s0: Connection to AP ac:22:05:83:ce:3c lost
[52544.218379] wlp59s0: send auth to ac:22:05:83:ce:3c (try 3/3)
[52545.117366] iwlwifi 0000:3b:00.0: No beacon heard and the session protection is over already...
[52545.117443] wlp59s0: Connection to AP ac:22:05:83:ce:3c lost
[52545.209765] wlp59s0: authentication with ac:22:05:83:ce:3c timed out
[52556.087441] wlp59s0: authenticate with ac:22:05:83:ce:3c
[52556.092715] wlp59s0: send auth to ac:22:05:83:ce:3c (try 1/3)
[52556.991951] iwlwifi 0000:3b:00.0: No beacon heard and the session protection is over already...
[52556.992044] wlp59s0: Connection to AP ac:22:05:83:ce:3c lost
[52557.210817] wlp59s0: send auth to ac:22:05:83:ce:3c (try 2/3)
[52558.109601] iwlwifi 0000:3b:00.0: No beacon heard and the session protection is over already...
[52558.109688] wlp59s0: Connection to AP ac:22:05:83:ce:3c lost

It seems that this also depends on the access point that I use (on some, it happens very often, on some others almost never).

Temp solution is to use networkmanager , it automatically reconnects to the AP.

Still I want this bug to be disappear.

I can confirm this bug happens in kernel 5.4.0-40 with Intel 8260. The No beacon keeps happening in a short time. Revert to kernel 4.15 and back to normal.

when the No beacon problem happens, the wifi disconnects and you no longer see the AP at that frequency. I had to switch wifi off then on to detect the AP again.

Hello, I'm suffering the same problem with my Thinkpad P52

Fedora 32

$ uname -a
Linux mariuccio-P52 5.7.9-200.fc32.x86_64 #1 SMP Fri Jul 17 16:23:37 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux


$ lspci -kvnn | sed -n '/Network/,/^$/ p'
00:14.3 Network controller [0280]: Intel Corporation Wireless-AC 9560 [Jefferson Peak] [8086:a370] (rev 10)
	Subsystem: Intel Corporation Device [8086:0030]
	Flags: bus master, fast devsel, latency 0, IRQ 16
	Memory at 604b10c000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi


Often I'm getting disconnected for few seconds


wpa_supplicant[16018]: nl80211: Event message available
wpa_supplicant[16018]: nl80211: Drv Event 64 (NL80211_CMD_NOTIFY_CQM) received for wlp0s20f3
wpa_supplicant[16018]: nl80211: Beacon loss event
wpa_supplicant[16018]: wlp0s20f3: Event BEACON_LOSS (53) received
wpa_supplicant[16018]: wlp0s20f3: CTRL-EVENT-BEACON-LOSS
wpa_supplicant[16018]: RTM_NEWLINK: ifi_index=3 ifname=wlp0s20f3 operstate=2 linkmode=1 ifi_family=0 ifi_flags=0x1003 ([UP])
wpa_supplicant[16018]: nl80211: Event message available
wpa_supplicant[16018]: nl80211: Drv Event 20 (NL80211_CMD_DEL_STATION) received for wlp0s20f3
wpa_supplicant[16018]: nl80211: Delete station 2c:30:33:26:5d:1c
wpa_supplicant[16018]: nl80211: Event message available
wpa_supplicant[16018]: nl80211: Drv Event 39 (NL80211_CMD_DEAUTHENTICATE) received for wlp0s20f3
wpa_supplicant[16018]: nl80211: MLME event 39 (NL80211_CMD_DEAUTHENTICATE) on wlp0s20f3(d4:3b:04:c3:59:ec) A1=2c:30:33:26:5d:1c A2=d4:3b:04:c3:59:ec
wpa_supplicant[16018]: nl80211: MLME event frame - hexdump(len=26): c0 00 00 00 2c 30 33 26 5d 1c d4 3b 04 c3 59 ec 2c 30 33 26 5d 1c 00 00 04 00
wpa_supplicant[16018]: nl80211: Deauthenticate event
wpa_supplicant[16018]: wlp0s20f3: Event DEAUTH (11) received
wpa_supplicant[16018]: wlp0s20f3: Deauthentication notification
wpa_supplicant[16018]: wlp0s20f3:  * reason 4 (DISASSOC_DUE_TO_INACTIVITY) locally_generated=1
wpa_supplicant[16018]: wlp0s20f3:  * address 2c:30:33:26:5d:1c
wpa_supplicant[16018]: Deauthentication frame IE(s) - hexdump(len=0): [NULL]
wpa_supplicant[16018]: wlp0s20f3: CTRL-EVENT-DISCONNECTED bssid=2c:30:33:26:5d:1c reason=4 locally_generated=1



The problem seems the same to me.

May I provide other useful info? This issue it's very annoying
Thanks,
Mario

Hey guys so I am on arch linux and I wanted to provide some details. I use iwd for dhcp + wireless connections, and randomly in heavy network throughput the wireless connection will drop and I cannot ping my gateway or anything, so for all intents and purposes I am offline. I have GT-AX11000 asus router and the intel ax-200 wireless card. This is key, when I set a limit on my download or upload clients  at 100kbps I can stay connected for weeks at a time. If I run a very intensive (50MBps+) samba connection it will drop after an hour or so. If I attempt to saturate my ISP's uplink with a upload application such as bittorrent, it will disconnect me in seconds. (single peer, TCP only, so its not number of connections but maybe packets per second?)

Kernel information.
I have tried the latest kernel and the lts kernel, both have identical issues.
Currently on LTS, downgraded from current today.
```uname -r
5.4.53-1-lts```

I believe this is a bug in iwd, so unrelated, but 
``` cat /etc/iwd/main.conf
[General]
EnableNetworkConfiguration=true
[Network]
NameResolvingService=systemd
```

This will not reconnect when it drops. I am going to try network manager and see if it reconnects, but the goal would be for it to maintain a good connection when the signal is good at all times. IWD says I have 5/5 signal strength if that helps.

My routers default beacon was 100ms, and I changed this to 50ms. I have not noticed a disconnection yet. Will post back later in 48 hours, this is usually my disconnection frequency. When it disconnects, only a reboot of the iwd service will bring it back. (Might be a bug with iwd, NetworkManager apparently will just keep re-connecting?)

Also, I apologuise for my ignorance but I am unsure how to apply kernel patches to be of help in this matter. 

Thanks for your time.

I tried with wpa_supplicant , networkmanager, iwd all will disconnects the network. Only networkmanaher will able to reconnect. But this is not the point. Wifi connection is so essential these days should run without a drop for weeks.

(In reply to sebalinux from comment #80)
> Hello, I'm suffering the same problem with my Thinkpad P52
> 
> Fedora 32
> 
> $ uname -a
> Linux mariuccio-P52 5.7.9-200.fc32.x86_64 #1 SMP Fri Jul 17 16:23:37 UTC
> 2020 x86_64 x86_64 x86_64 GNU/Linux
> 
> 
> $ lspci -kvnn | sed -n '/Network/,/^$/ p'
> 00:14.3 Network controller [0280]: Intel Corporation Wireless-AC 9560
> [Jefferson Peak] [8086:a370] (rev 10)
>       Subsystem: Intel Corporation Device [8086:0030]
>       Flags: bus master, fast devsel, latency 0, IRQ 16
>       Memory at 604b10c000 (64-bit, non-prefetchable) [size=16K]
>       Capabilities: <access denied>
>       Kernel driver in use: iwlwifi
>       Kernel modules: iwlwifi
> 
> 
> Often I'm getting disconnected for few seconds
> 
> 
> wpa_supplicant[16018]: nl80211: Event message available
> wpa_supplicant[16018]: nl80211: Drv Event 64 (NL80211_CMD_NOTIFY_CQM)
> received for wlp0s20f3
> wpa_supplicant[16018]: nl80211: Beacon loss event
> wpa_supplicant[16018]: wlp0s20f3: Event BEACON_LOSS (53) received
> wpa_supplicant[16018]: wlp0s20f3: CTRL-EVENT-BEACON-LOSS
> wpa_supplicant[16018]: RTM_NEWLINK: ifi_index=3 ifname=wlp0s20f3 operstate=2
> linkmode=1 ifi_family=0 ifi_flags=0x1003 ([UP])
> wpa_supplicant[16018]: nl80211: Event message available
> wpa_supplicant[16018]: nl80211: Drv Event 20 (NL80211_CMD_DEL_STATION)
> received for wlp0s20f3
> wpa_supplicant[16018]: nl80211: Delete station 2c:30:33:26:5d:1c
> wpa_supplicant[16018]: nl80211: Event message available
> wpa_supplicant[16018]: nl80211: Drv Event 39 (NL80211_CMD_DEAUTHENTICATE)
> received for wlp0s20f3
> wpa_supplicant[16018]: nl80211: MLME event 39 (NL80211_CMD_DEAUTHENTICATE)
> on wlp0s20f3(d4:3b:04:c3:59:ec) A1=2c:30:33:26:5d:1c A2=d4:3b:04:c3:59:ec
> wpa_supplicant[16018]: nl80211: MLME event frame - hexdump(len=26): c0 00 00
> 00 2c 30 33 26 5d 1c d4 3b 04 c3 59 ec 2c 30 33 26 5d 1c 00 00 04 00
> wpa_supplicant[16018]: nl80211: Deauthenticate event
> wpa_supplicant[16018]: wlp0s20f3: Event DEAUTH (11) received
> wpa_supplicant[16018]: wlp0s20f3: Deauthentication notification
> wpa_supplicant[16018]: wlp0s20f3:  * reason 4 (DISASSOC_DUE_TO_INACTIVITY)
> locally_generated=1
> wpa_supplicant[16018]: wlp0s20f3:  * address 2c:30:33:26:5d:1c
> wpa_supplicant[16018]: Deauthentication frame IE(s) - hexdump(len=0): [NULL]
> wpa_supplicant[16018]: wlp0s20f3: CTRL-EVENT-DISCONNECTED
> bssid=2c:30:33:26:5d:1c reason=4 locally_generated=1
> 
> 
> 
> The problem seems the same to me.
> 
> May I provide other useful info? This issue it's very annoying
> Thanks,
> Mario


Hello,
just another little piece of information: yesterday morning I activated the 5Ghz net in my router and I switched to it. Results: about 24H without no drop, no disconnection, no bug. The router is the same, the laptop is the same, what changed is only the wifi network frequency. I tried this but I have to use 2.4Ghz network, so I would like to see the bug solved.

Alright here is what I think is going on.

Setting beacon to 50ms vs 100ms keeps the card from going into sleep mode. I think the sleep mode is the issue.... Maybe too aggressive power save?

sebalinux 
This may work for you, but I was on a 5GHz channel 160MHz and I still have major issues. Setting beacon helped, but it will still eventually disconnect (am on latest arch kernel). Since I was on iwd, every 2 days I would need to manually restart the service as it was a nas. NetworkManager service will reboot the connection on its own, so it helped. But disconnecting randomly is not ideal.

(In reply to dagthree7 from comment #84)
> Alright here is what I think is going on.
> 
> Setting beacon to 50ms vs 100ms keeps the card from going into sleep mode. I
> think the sleep mode is the issue.... Maybe too aggressive power save?
> 
> sebalinux 
> This may work for you, but I was on a 5GHz channel 160MHz and I still have
> major issues. Setting beacon helped, but it will still eventually disconnect
> (am on latest arch kernel). Since I was on iwd, every 2 days I would need to
> manually restart the service as it was a nas. NetworkManager service will
> reboot the connection on its own, so it helped. But disconnecting randomly
> is not ideal.

I completely agree that this behavior is not ideal nor acceptable. I only shared my experience (update: it was working for two days with no disconnection) just to add some (I hope useful) informations to people that are analyzing the issue.
I have to switch down the 5Ghz wifi for other reason, so it was only a test to verify if the problem was related to the different frequency.

I was experiencing this problem on both 2 and 5GHz. Reducing beacon interval from 100 to 50 didn't eliminate the issue.

Can we just take a break and admire that this bug is here for a more than a year. Thank you Intel.

Not to muddy the waters, but this is still an issue on my Lenovo Thinkpad P1Gen2 notebook with Fedora 32

[root@localhost conf.d]# uname -a
Linux localhost.localdomain 5.7.10-201.fc32.x86_64 #1 SMP Thu Jul 23 00:58:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

[root@localhost conf.d]# ethtool -i wlp82s0
driver: iwlwifi
version: 5.7.10-201.fc32.x86_64
firmware-version: 53.c31ac674.0 cc-a0-53.ucode
expansion-rom-version: 
bus-info: 0000:52:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

[root@localhost conf.d]# lspci | grep -i wi-fi
52:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a)

Wifi disconnects every 20ish minutes,and in the journal I see messages like
Aug 01 17:53:35 localhost.localdomain wpa_supplicant[1113]: wlp82s0: CTRL-EVENT-BEACON-LOSS
Aug 01 17:53:35 localhost.localdomain wpa_supplicant[1113]: wlp82s0: CTRL-EVENT-BEACON-LOSS
Aug 01 17:53:35 localhost.localdomain wpa_supplicant[1113]: wlp82s0: CTRL-EVENT-BEACON-LOSS
Aug 01 17:53:35 localhost.localdomain wpa_supplicant[1113]: wlp82s0: CTRL-EVENT-BEACON-LOSS
Aug 01 17:53:35 localhost.localdomain wpa_supplicant[1113]: wlp82s0: CTRL-EVENT-BEACON-LOSS
Aug 01 17:53:35 localhost.localdomain wpa_supplicant[1113]: wlp82s0: CTRL-EVENT-BEACON-LOSS
Aug 01 17:53:35 localhost.localdomain wpa_supplicant[1113]: wlp82s0: CTRL-EVENT-BEACON-LOSS
Aug 01 17:53:35 localhost.localdomain wpa_supplicant[1113]: wlp82s0: CTRL-EVENT-BEACON-LOSS
Aug 01 17:53:36 localhost.localdomain kernel: wlp82s0: Connection to AP 20:c0:47:e1:69:1c lost
Aug 01 17:53:36 localhost.localdomain wpa_supplicant[1113]: wlp82s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=0 noise=9999 txrate=0
Aug 01 17:53:36 localhost.localdomain wpa_supplicant[1113]: wlp82s0: CTRL-EVENT-DISCONNECTED bssid=20:c0:47:e1:69:1c reason=4 locally_generated=1
Aug 01 17:53:36 localhost.localdomain wpa_supplicant[1113]: dbus: wpa_dbus_property_changed: no property SessionLength in object /fi/w1/wpa_supplicant1/Interfaces/13

While we "wait" for this bug to be solved, I figured I'd just share what helped make my connection more stable.

1. I disabled IPv6 (not sure this step is really needed)
[root@localhost conf.d]# cat /etc/sysctl.conf 
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

2. Then I disabled powersaving on the Wi-Fi card (this probably helped the most)

[root@localhost conf.d]# cat /etc/NetworkManager/conf.d/wifi-power-save-off.conf 
[connection]
# Values are 0 (use default), 1 (ignore/don't touch), 2 (disable) or 3 (enable).
wifi.powersave = 2

3. Following https://forum.manjaro.org/t/solved-intel-ax200-iwlwifi-based-adapter-slow-wifi/148708 I also did lsmod | grep -o -e ^iwlmvm -e ^iwldvm -e ^iwlwifi | xargs sudo rmmod && sleep 3 && sudo modprobe iwlwifi swcrypto=1 11n_disable=1 and added 
[root@localhost conf.d]# cat /etc/modprobe.d/iwlwifi.conf 
options iwlwi fi swcrypto=1 11n_disable=1
for persistance.

While I realize that I probably tried a few different things and probably (2) helped the most, I have a lot more stable Wi-Fi connection now.

@sai(In reply to Sai Sindhur Malleni from comment #88)
> Not to muddy the waters, but this is still an issue on my Lenovo Thinkpad
> P1Gen2 notebook with Fedora 32
> 
> [root@localhost conf.d]# uname -a
> Linux localhost.localdomain 5.7.10-201.fc32.x86_64 #1 SMP Thu Jul 23
> 00:58:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
> 
> [root@localhost conf.d]# ethtool -i wlp82s0
> driver: iwlwifi
> version: 5.7.10-201.fc32.x86_64
> firmware-version: 53.c31ac674.0 cc-a0-53.ucode
> expansion-rom-version: 
> bus-info: 0000:52:00.0
> supports-statistics: yes
> supports-test: no
> supports-eeprom-access: no
> supports-register-dump: no
> supports-priv-flags: no
> 
> [root@localhost conf.d]# lspci | grep -i wi-fi
> 52:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a)
> 
> Wifi disconnects every 20ish minutes,and in the journal I see messages like
> Aug 01 17:53:35 localhost.localdomain wpa_supplicant[1113]: wlp82s0:
> CTRL-EVENT-BEACON-LOSS
> Aug 01 17:53:35 localhost.localdomain wpa_supplicant[1113]: wlp82s0:
> CTRL-EVENT-BEACON-LOSS
> Aug 01 17:53:35 localhost.localdomain wpa_supplicant[1113]: wlp82s0:
> CTRL-EVENT-BEACON-LOSS
> Aug 01 17:53:35 localhost.localdomain wpa_supplicant[1113]: wlp82s0:
> CTRL-EVENT-BEACON-LOSS
> Aug 01 17:53:35 localhost.localdomain wpa_supplicant[1113]: wlp82s0:
> CTRL-EVENT-BEACON-LOSS
> Aug 01 17:53:35 localhost.localdomain wpa_supplicant[1113]: wlp82s0:
> CTRL-EVENT-BEACON-LOSS
> Aug 01 17:53:35 localhost.localdomain wpa_supplicant[1113]: wlp82s0:
> CTRL-EVENT-BEACON-LOSS
> Aug 01 17:53:35 localhost.localdomain wpa_supplicant[1113]: wlp82s0:
> CTRL-EVENT-BEACON-LOSS
> Aug 01 17:53:36 localhost.localdomain kernel: wlp82s0: Connection to AP
> 20:c0:47:e1:69:1c lost
> Aug 01 17:53:36 localhost.localdomain wpa_supplicant[1113]: wlp82s0:
> CTRL-EVENT-SIGNAL-CHANGE above=0 signal=0 noise=9999 txrate=0
> Aug 01 17:53:36 localhost.localdomain wpa_supplicant[1113]: wlp82s0:
> CTRL-EVENT-DISCONNECTED bssid=20:c0:47:e1:69:1c reason=4 locally_generated=1
> Aug 01 17:53:36 localhost.localdomain wpa_supplicant[1113]: dbus:
> wpa_dbus_property_changed: no property SessionLength in object
> /fi/w1/wpa_supplicant1/Interfaces/13
> 
> While we "wait" for this bug to be solved, I figured I'd just share what
> helped make my connection more stable.
> 
> 1. I disabled IPv6 (not sure this step is really needed)
> [root@localhost conf.d]# cat /etc/sysctl.conf 
> net.ipv6.conf.all.disable_ipv6 = 1
> net.ipv6.conf.default.disable_ipv6 = 1
> net.ipv6.conf.lo.disable_ipv6 = 1
> 
> 2. Then I disabled powersaving on the Wi-Fi card (this probably helped the
> most)
> 
> [root@localhost conf.d]# cat
> /etc/NetworkManager/conf.d/wifi-power-save-off.conf 
> [connection]
> # Values are 0 (use default), 1 (ignore/don't touch), 2 (disable) or 3
> (enable).
> wifi.powersave = 2
> 
> 3. Following
> https://forum.manjaro.org/t/solved-intel-ax200-iwlwifi-based-adapter-slow-
> wifi/148708 I also did lsmod | grep -o -e ^iwlmvm -e ^iwldvm -e ^iwlwifi |
> xargs sudo rmmod && sleep 3 && sudo modprobe iwlwifi swcrypto=1
> 11n_disable=1 and added 
> [root@localhost conf.d]# cat /etc/modprobe.d/iwlwifi.conf 
> options iwlwi fi swcrypto=1 11n_disable=1
> for persistance.
> 
> While I realize that I probably tried a few different things and probably
> (2) helped the most, I have a lot more stable Wi-Fi connection now.


I believe i tried all of the things you mentioning in all the kernel firmware updates since aug 2019, probably more than the Intel engineers.none of them works. Can't argue the fact that they are just a Titanic, they are doomed for sinking. No wonder they are failing. RIP

Confirming this issue with ath9k-based APs. My router is Turris Omnia with Qualcomm Atheros AR9287 and QCA9880 cards. Turris OS 3.x.x (based on OpenWRT 15.05) had some issues with ath10k, so my laptop was often connected to 2.4GHz network. I had multiple disconnections per day, sometimes to the point that I need to manually disconnect and connect again:

$ sudo LC_ALL=en_US.UTF-8 journalctl | fgrep 'Connection to AP 04:f0:21:XX:XX:XX lost' | awk '{print $1" "$2}' | uniq -c 
     33 Jun 23
      2 Jun 25
     60 Jun 26
      1 Jun 27
     80 Jun 28
     23 Jun 29
      2 Jul 02
     26 Jul 03
     71 Jul 08
    167 Jul 09
     56 Jul 10
     67 Jul 11
     56 Jul 14
     25 Jul 15

After upgrade to the Turris OS 5.x.x (based on OpenWRT 19.07) my laptop is always connected to the 5GHz network and the issue is completely gone. I didn't change anything in my laptop and/or router configuration.


My laptop wifi card:

[  171.990009] iwlwifi 0000:00:14.3: Detected Intel(R) Dual Band Wireless AC 9560, REV=0x318

00:14.3 Network controller [0280]: Intel Corporation Cannon Point-LP CNVi [Wireless-AC] [8086:9df0] (rev 11)
	Subsystem: Intel Corporation Cannon Point-LP CNVi [Wireless-AC] [8086:0034]
	Flags: bus master, fast devsel, latency 0, IRQ 16
	Memory at f1210000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [c8] Power Management version 3
	Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
	Capabilities: [40] Express Root Complex Integrated Endpoint, MSI 00
	Capabilities: [80] MSI-X: Enable+ Count=16 Masked-
	Capabilities: [100] Null
	Capabilities: [14c] Latency Tolerance Reporting
	Capabilities: [164] Vendor Specific Information: ID=0010 Rev=0 Len=014 <?>
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

AX200 on Arch Linux here been having this problem since I purchased the card a few weeks ago.

I updated to kernel 5.8.0.1 via linux-mainline in the aur today and so far have been connected for nearly four hours of solidly hitting the connection without any beacon loss (or any connection loss). This is much longer than I normally get. It could be a coincidence but it hasn't lasted this long before.

For a full list of things I've also changed or have:

AX200 (more specifically this one: https://www.amazon.co.uk/gp/product/B07YZ7J8QD)

Computer is a Dell OptiPlex 990 SFF, using second PCIe slot, first used by an Nvidia NVS 510

Arch Linux x86-64

linux-mainline 5.8-1 from the aur

Disconnects frequently (hour max) and has trouble connecting to TalkTalk's ISP router, Sagemcom FAST5364 3.0. Stays connected to Galaxy Note 10+ as a hotspot to the same router for a few hours at a time before disconnecting. Neither has had their beacon interval changed (not changeable on both). I have yet to try it on my home Ubiquiti Unifi UAP-AC-LITE as I won't be there for a while.

Using NetworkManager

Disabled ipv6

Disabled power saving via modprobe with:
options iwlmvm power_scheme=1
options iwlwifi power_save=0

Tried both latest Arch kernel (5.7.9) and LTS and issue persists on both

Would be great if someone else could have a go and see if they're having a consistent connection on 5.8

I'm not sure how to edit comments, I forgot this thing I changed as well:

Disabled mac spoofing randomisation, instead using the actual mac for the card. I found this made reconnections easier and possibly allowed it to stay connected a bit longer, although that may have been a placebo.

Just to say it has lasted over 30 hours without a disconnection now. I had the following a few times around 1pm today:

    iwlwifi 0000:04:00.0: Unhandled alg: 0x71b

But that didn't actually cause any connection loss or any visible effects (I had a download going at the time and it didn't even slow down), and no beacon errors or anything else.

So far, keeping ipv6 but turning off power saving via modprobe seems to be a great workaround (no more firmware crashes in the last few days when it used to crash many times a day with every heavy web usage). 

So, just add to /etc/modprobe.d/iwlwifi.conf the following:
options iwlmvm power_scheme=1
options iwlwifi power_save=0

Unfortunately, disabling power saving in the driver alone is not solving my problem. The only thing that has solved my problem so far is 
 lsmod | grep -o -e ^iwlmvm -e ^iwldvm -e ^iwlwifi |xargs sudo rmmod && sleep 3 && sudo modprobe iwlwifi 11n_disable=1

At which point I have horrible throughput and can't even connect to 5GHz networks anymore.

Unfortunately, disabling power saving in the driver alone is not solving my problem. The only thing that has solved my problem so far is 
 lsmod | grep -o -e ^iwlmvm -e ^iwldvm -e ^iwlwifi |xargs sudo rmmod && sleep 3 && sudo modprobe iwlwifi 11n_disable=1

At which point I have horrible throughput and can't even connect to 5GHz networks anymore.

I resolved this issue blacklisting iwlwifi and buying a Chinese USB wifi adapter.

Thank you Intel.

Mathias Bavay solution actually solved that for me (THANKS!). Specifically I have:

* TP-Link Archer C6 router, 5GHz, beacon interval set to 50. 

* Intel Corporation Wireless 8260 (rev 3a) (with Thinkpad T460s)

* Linux 5.7.12-arch1-1 #1 SMP PREEMPT Fri, 31 Jul 2020 17:38:22 +0000 x86_64 GNU/Linux (previously I was on lts419 which didn't have this bug)

* modprobe like:
# cat /etc/modprobe.d/iwlwifi.conf
options iwlmvm power_scheme=1
options iwlwifi power_save=0

I have been stable for a day and a half. 

I have not disabled ipv6 (although I don't use it). I also didn't fixed channel on the router. See my early attempts earlier.

Update to my last comment: it only makes the problem less likely apparently - today I got in the "No beacon heard..." after a week of stable connection (two days ago, I upgraded to 5.8.1 though).

Sorry, another update - it got to the same frequency as before, therefore my last two comments were just a random noise, sorry for that.

A friend of mine has exactly the same hardware as I do, Thinkpad T460s with Intel Corporation Wireless 8260 (rev 3a), but with Linux Manjaro (I have Arch). He doesn't experience the problems at all. Is there anyone who's _not_ on Arch and experiencing this?

Manjaro and Kernel 5.8.1 here on my T450s. Card is Intel Corporation Wireless 7265 (rev 59).
Had this issue with every recent Kernel.
The comment from Mathias Bavay fixes the issue for me:
https://bugzilla.kernel.org/show_bug.cgi?id=203709#c94

Debian 5.8.1 toshiba portege x30-f. Never had this issue on 5.7.x kernels, but since 5.8.1 had this issue twice, but can't reproduce on purpose. Since I've got it on AC power, it doesn't seems like switching off powersave can help.

@GRbit I forgot to mention, I was always on AC power.  It's just that the wifi card would by default try to use a power save mode that seems quite buggy...

I am experiencing what seems to be the same issue on the intel 8265 / 8275. Performance drops, and only picks up speed when WiFi is turned on and off

$ uname -r
5.4.0-42-generic

$ lspci
00:1f.4 SMBus: Intel Corporation 100 Series/C230 Series Chipset Family SMBus (rev 31)
01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Polaris 22 MGL XL [Radeon Pro WX Vega M GL] (rev c0)
02:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78)
03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS525A PCI Express Card Reader (rev 01)

It seems that the error is with some IPv6 configuration. In Ubuntu, I disabled DNS and Auto Routes and the error went almost unnoticed

I want to mention that the below advice has helped me with AC 8265 adaptor.  Iw worked fine on Windows, but dropped packets in Kernel 5.4 and 5.8
Thank you,
Sergey

(In reply to Mathias Bavay from comment #94)
> So far, keeping ipv6 but turning off power saving via modprobe seems to be a
> great workaround (no more firmware crashes in the last few days when it used
> to crash many times a day with every heavy web usage). 
> 
> So, just add to /etc/modprobe.d/iwlwifi.conf the following:
> options iwlmvm power_scheme=1
> options iwlwifi power_save=0

I've notice this isse on my Lenovo L490. Wifi went crazy - computer started to loose connection every few minutes. Restart helped.  
# uname -r
5.4.0-47-generic

# lspci 
00:00.0 Host bridge: Intel Corporation Coffee Lake HOST and DRAM Controller (rev 0c)
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (Whiskey Lake) (rev 02)
00:04.0 Signal processing controller: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (rev 0c)
00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model
00:12.0 Signal processing controller: Intel Corporation Cannon Point-LP Thermal Controller (rev 30)
00:14.0 USB controller: Intel Corporation Cannon Point-LP USB 3.1 xHCI Controller (rev 30)
00:14.2 RAM memory: Intel Corporation Cannon Point-LP Shared SRAM (rev 30)
00:15.0 Serial bus controller [0c80]: Intel Corporation Cannon Point-LP Serial IO I2C Controller #0 (rev 30)
00:15.2 Serial bus controller [0c80]: Intel Corporation Device 9dea (rev 30)
00:16.0 Communication controller: Intel Corporation Cannon Point-LP MEI Controller #1 (rev 30)
00:1d.0 PCI bridge: Intel Corporation Cannon Point-LP PCI Express Root Port #9 (rev f0)
00:1d.3 PCI bridge: Intel Corporation Device 9db3 (rev f0)
00:1d.7 PCI bridge: Intel Corporation Device 9db7 (rev f0)
00:1f.0 ISA bridge: Intel Corporation Cannon Point-LP LPC Controller (rev 30)
00:1f.3 Audio device: Intel Corporation Cannon Point-LP High Definition Audio Controller (rev 30)
00:1f.4 SMBus: Intel Corporation Cannon Point-LP SMBus Controller (rev 30)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Cannon Point-LP SPI Controller (rev 30)
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (6) I219-V (rev 30)
04:00.0 Non-Volatile memory controller: Toshiba Corporation Device 011a
05:00.0 Network controller: Intel Corporation Wireless-AC 9260 (rev 29)
07:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS522A PCI Express Card Reader (rev 01)

same here Asus Vivobook S15 

5.8.6-1-MANJARO

Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78)

I have same problem after suspend on lenovo ideapad 5 ( amd ryzen 7 )

Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a)

Linux ubuntu-pc 5.8.13-050813-generic...

Same on Arch 5.8.10-arch1-1 and 02:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a)
but same with other kernels and Intel based wifi.

it's really annoy, do not find solution what really helps. Sometimes littlebit help modprobe iwlwifi power_save=0 sometimes help move with laptop. Sometimes help turn off bluetooth on mobile from which using hotspot.

First I thought it's because Mikrotik's WiFi, but now I can see that on other networks too (even TPLink, UBNT, android hotspot, Turris). Mostly it's worse on 5ghz than 2.4GHz

If I can help somehow with debugging (wireshark, some dumps, sniff something by other wifi card. Anything what could help to find what it causes.


[466410.753117] wlp2s0: authenticate with 68:72:51:60:bd:7b
[466410.755615] wlp2s0: send auth to 68:72:51:60:bd:xx (try 1/3)
[466411.323928] wlp2s0: send auth to 68:72:51:60:bd:xx (try 2/3)
[466411.350849] wlp2s0: authenticated
[466411.353084] wlp2s0: associate with 68:72:51:60:bd:xx (try 1/3)
[466411.356407] wlp2s0: RX AssocResp from 68:72:51:60:bd:xx (capab=0x431 status=0 aid=4)
[466411.363796] wlp2s0: associated
[466412.222808] iwlwifi 0000:02:00.0: No beacon heard and the session protection is over already...
[466412.222836] wlp2s0: Connection to AP 68:72:51:60:bd:xx lost


and repeat every second

I "solved" this by buying https://www.tp-link.com/cz/home-networking/adapter/archer-t2u-nano/ instead :-( . It's sad...

I think I got a pretty stable setup now but there were three problems on my system (I'm using IWD on my system):

1.There is currently a bug in the Kernel (5.9.1):
Discussion: https://www.reddit.com/r/archlinux/comments/jdlayz/iwd_broken_after_update/
Proposed patch: https://lore.kernel.org/linux-wireless/20201017230818.04896494%40mathy-work.localhost/

2. Using IWD with NetworkManager also causes disconnects
=> I have disabled NetworkManager on my system and use systemd-networkd to configure my wireless connection

3. I have disabled all power saving options and also 11ax in the driver
/etc/modprobe.d/iwlwifi.conf:
options iwlwifi power_save=0
options iwlwifi disable_11ax=1
options iwlmvm power_scheme=1

Hi folks,

I have two laptops with this a Intel AC7260 the one laptop is a Sony Vaio Flip 14 and the other is a Probook 4540s. This bug only seems to happen on the Probook 4540s. Problematic Laptop is the 4540s.

I have been suffering this bug since 5.4 Kernel on Ubuntu 18.04, Kernel 4.15 on Ubuntu 18.04 is fine no problems but something i have noticed. Having Fast Boot enabled in the BIOS breaks the Bluetooth also causes WIFI to drop every 5mins, disabled Fast Boot has solved issue with Bluetooth not being seen and WIFI dropping out every 5 mins.

Here what i have found, changing DTIM to 50 on 5G with the Ubiquti AC Lite has seemed to fix the problem so far, when this problem is caused its mainly when there is no activity on the Network Card loads of traffic and constant pings do not cause this problem.

When SAMBA Share is mounted that is when it happens the most. Something else that is interesting it only happens on certain Routers. Ubiquti AC Lite it happens on but a BT Homehub or Smarthub this doesn't happen also tested on Sky Broadband Router and no problems neither.

Heres what i have tried before changing DTIM to 50.

Downloaded latest Driver from Intel and removed old firmware, This makes Network card not detected,

Disabled PowerManagement,
Disabled ipv6

none solved except issue has disappeared when changing DTIM to 50.

Find it strange that some Routers are fine tho. Maybe something to do with UEFI BIOS will test with Legacy and see if problem is there.

Cheers.

Jack.

Update,

My HP Probook 4540s has been up for 2 days and had this No beacon heard and the time event is over already... It is not as frequent as it was tho.

I have noticed something tho, This seems to be machine specific why i say this, I have another 7260 Card which i installed on a Desktop tested with Ubuntu 18.04 and 20.04 with 5.4.0-52-generic Kernel and this Error does not happen. Output i get on both machines are,

[140029.104658] wlan0: authenticate with fc:ec:da
[140029.107120] wlan0: send auth to fc:ec:da (try 1/3)
[140029.111995] wlan0: authenticated

at least it connects on first attempt. But this issue is only on certain machines, Doesn't happen on Sony Vaio Flip 14 or a G41M-P25, Core 2 Quad Desktop but does indeed happen on mu HP Probook 4540s.

(In reply to Jack Bamford from comment #114)

you could try swapping the cards between those two devices?! Maybe it's a problem in the cards, not the notebooks?

We're having some hundred of the cards out in the wild, but still don't understand why some fail often, some sometimes and some never...

(In reply to lukas.redlinger from comment #115)
> (In reply to Jack Bamford from comment #114)
> 
> you could try swapping the cards between those two devices?! Maybe it's a
> problem in the cards, not the notebooks?
> 
> We're having some hundred of the cards out in the wild, but still don't
> understand why some fail often, some sometimes and some never...

Hi,

Thanks for your reply, I have tried that that was the first thing i done but the problem still happens. 

Problem doesnt happen on Ubuntu 16.04 or Windows 10 on the HP Probook 4540s.

Thanks.

Jack.

Moving off of iwlwifi with an external adapter (awus036ach) using realtek-rtl8812 driver "solved" it for me.

Created attachment 293565 [details]
Sample output from journalctl (Ubuntu 20.04, 8265wifi, kernel 5.4.0)

Created attachment 293567 [details]
trace_cmd output (8265wifi, Kernel 5.4.0)

The issue happened multiple times during this trace_cmd.

Created attachment 293569 [details]
trace_cmd output (8265wifi, kernel 5.4.0, debug-fw 36.9f0a2d68.0 op_mode iwlmvm)

Created attachment 293571 [details]
fw_dbg_collect dump (8265wifi, kernel 5.4.0, debug-fw 36.9f0a2d68.0 op_mode iwlmvm)

Hello,

I have this problem for quite a long time, both with Ubuntu 18.04 and 20.04. The issue occurs rarely but consistently. My laptop is a Dell Inc. Latitude 7490 with Intel 8265 wireless controller. I am on Kernel 5.4.0 shipped with Ubuntu 20.04. I replaced the FW with the debug version and verified that the version changed in the dmesg output. I don't observe the "No beacon heard and the time event is over already" message anywhere, though my error seems to be related to a beacon loss as well according to the system logs (see the sample_syslog.txt) attachment. Lastly, the error occurs with 2 different APs. I have a macbook air and multiple other wifi devices hanging around that does not have such connectivity issues.

I previously attached (I couldn't encrypt the files because the keys seem outdated?):
 - a sample log from journalctl
 - as well as a trace_cmd dump during which the issue occurred multiple times. 
 - An fw_dbg_collect coredump file during which the issue was there as well

I am willing to help more to resolve this issue, @devs please do use me :) Thanks!

I tried now with fedora (5.9.8-200.fc33.x86_64) and is the same issue.Now i "solve" this wirh TP-Link TL-WN823N v2/v3 [Realtek RTL8192EU].

Hi folks,

So after a few days i installed PopOS on my 4540s and this problem doesn't happen as much but the actual connection doesn't drop when No beacon heard and the time event is over already... is under dmesg live TV stream or Radio Streams doesn't stop playing im guessing this is just cosmetic but in Ubuntu the connection actually drops and live streams drops which causes Kodi to use Timeshift which doesn't happen in PopOS its actually usable again.

Output of dmesg,

[983327.928806] iwlwifi 0000:03:00.0: No beacon heard and the time event is over already...
[983327.928866] wlo1: Connection to AP fc:ec:da: lost
[983331.227857] wlo1: authenticate with fc:ec:da:
[983331.230331] wlo1: send auth to fc:ec:da:1e:a3 (try 1/3)
[983331.235718] wlo1: authenticated
[983331.237283] wlo1: associate with fc:ec:da: (try 1/3)
[983331.241497] wlo1: RX AssocResp from fc:ec:da: (capab=0x411 status=0 aid=1)
[983331.242967] wlo1: associated
[983339.959839] wlo1: Connection to AP fc:ec:da: lost
[983343.211156] wlo1: authenticate with fc:ec:da:
[983343.214274] wlo1: send auth to fc:ec:da: (try 1/3)
[983343.216853] wlo1: authenticated
[983343.221001] wlo1: associate with fc:ec:da: (try 1/3)
[983343.225177] wlo1: RX AssocResp from fc:ec:da: (capab=0x411 status=0 aid=1)
[983343.226556] wlo1: associated

Kernel Version in PopOS,
5.8.0-7625-generic

Kernel Version in Ubuntu 18.04
5.4.0-53-generic

Update of laptop on PopOS no disconnect from WIFI happens. LiveStreams still plays when dmesg shows No beacon heard and the time event is over already...
15:51:16 up 11 days, 12:21,  1 user,  load average: 1.22, 1.10, 1.08


Hope this is a bit more information.

I fitted my laptop with an AX200 to get stable Wifi. But it's getting worse recently.

I cannot connect to the Hotspot of the Android phone anymore (A520F with all updates). It just failed to authenticate over and over again, each time with the infamous "No beacon heard and the session protection is over already". The phone is right next to the laptop.

Now I also get the message when I'm connected to my Router (AVM FritzBox 7490, all updates). Connection is somewhat stable though.

any progress? No beacon and beacon lost happens everyday. sometimes can't connect anymore because no AP detected.

Update:with latest update in Fedora i have now a very stable Wifi connection,
no ping lag,no lost packet.(tested 2 days with no issue)

what latest update is Fedora? Which kernel version?

I just managed to get a Mint Kernel 4.15-124 working. it is LTS to 2023. So I will use this instead, is much more stable.

(In reply to how from comment #128)
> what latest update is Fedora? Which kernel version?
> 
> I just managed to get a Mint Kernel 4.15-124 working. it is LTS to 2023. So
> I will use this instead, is much more stable.

5.9.10-200.fc33.x86_64

thanks, but the only version I can get with the repo is 5.8 and is reported as buggy as well. So just use 4.15 I am happy with for now.

Just installed 5.9.10 on Ubuntu 20.04. Let's see what happens.

The issue still persists with the mainline kernel 5.9.10 on Ubuntu 20.04.

iwlwifi 0000:01:00.0: No beacon heard and the time event is over already...
wlp1s0: Connection to AP 18:31:bf:62:09:ac lost
wlp1s0: authenticate with 18:31:bf:62:09:ac
wlp1s0: send auth to 18:31:bf:62:09:ac (try 1/3)
wlp1s0: authenticated
wlp1s0: associate with 18:31:bf:62:09:ac (try 1/3)
wlp1s0: RX AssocResp from 18:31:bf:62:09:ac (capab=0x31 status=0 aid=4)
wlp1s0: associated
wlp1s0: Connection to AP 18:31:bf:62:09:ac lost
wlp1s0: Connection to AP 00:00:00:00:00:00 lost
wlp1s0: authenticate with 18:31:bf:62:09:ac
wlp1s0: send auth to 18:31:bf:62:09:ac (try 1/3)
wlp1s0: authenticated
wlp1s0: associate with 18:31:bf:62:09:ac (try 1/3)
wlp1s0: RX AssocResp from 18:31:bf:62:09:ac (capab=0x31 status=0 aid=4)
wlp1s0: associated
iwlwifi 0000:01:00.0: No beacon heard and the time event is over already...
wlp1s0: Connection to AP 18:31:bf:62:09:ac lost
wlp1s0: authenticate with 18:31:bf:62:09:ac
wlp1s0: send auth to 18:31:bf:62:09:ac (try 1/3)
wlp1s0: authenticated
wlp1s0: associate with 18:31:bf:62:09:ac (try 1/3)
wlp1s0: RX AssocResp from 18:31:bf:62:09:ac (capab=0x31 status=0 aid=4)
wlp1s0: associated
iwlwifi 0000:01:00.0: No beacon heard and the time event is over already...
wlp1s0: Connection to AP 18:31:bf:62:09:ac lost
wlp1s0: authenticate with 18:31:bf:62:09:ac
wlp1s0: send auth to 18:31:bf:62:09:ac (try 1/3)
wlp1s0: authenticated
wlp1s0: associate with 18:31:bf:62:09:ac (try 1/3)
wlp1s0: RX AssocResp from 18:31:bf:62:09:ac (capab=0x31 status=0 aid=4)
wlp1s0: associated

well, The only kernel that works is 4.15 or may be 5.0 as well. If you need to know how to get those kernel working I can provide the details

I must say, that I don't understand why this bug have so low priority. It is known for 1,5 year and it concerns all (or almost all) Intel WIFI cards. All distros forums are full of topics regarding this issue.
Some people will not even notice 3 lost pings until their wifi will not break definitely, but the experience with online meetings (kids learning, work) in time of covid is terrible.

My laptop with arch have become unusable (I need to buy external USB wifi card without Intel chipset). All "workarounds" do not work.

Kernel: Linux arch 5.9.11-arch2-1
Network controller: Intel Corporation Centrino Wireless-N 1000

gru 04 08:28:42 arch iwd[441]: Received Deauthentication event, reason: 4, from_ap: false
gru 04 08:29:46 arch iwd[441]: Received Deauthentication event, reason: 4, from_ap: false
gru 04 08:33:16 arch iwd[441]: Received Deauthentication event, reason: 4, from_ap: false
gru 04 08:35:10 arch iwd[441]: Received Deauthentication event, reason: 4, from_ap: false
gru 04 08:36:50 arch iwd[441]: Received Deauthentication event, reason: 4, from_ap: false
gru 04 08:38:57 arch iwd[441]: Received Deauthentication event, reason: 4, from_ap: false
gru 04 08:45:59 arch iwd[441]: Received Deauthentication event, reason: 4, from_ap: false
gru 04 09:01:53 arch iwd[441]: Received Deauthentication event, reason: 4, from_ap: false
gru 04 09:04:45 arch iwd[441]: Received Deauthentication event, reason: 4, from_ap: false
gru 04 09:15:24 arch iwd[441]: Received Deauthentication event, reason: 4, from_ap: false

What other info do we need to change the status of this bug? I think that all info was provided.

Same issue on Ubuntu 20.04 and been happening since I started using linux on a Lenovo P76.

$ lspci -kvnn | sed -n '/Network/,/^$/ p'

52:00.0 Network controller [0280]: Intel Corporation Wi-Fi 6 AX200 [8086:2723] (rev 1a)
	Subsystem: Intel Corporation Wi-Fi 6 AX200 [8086:0080]
	Flags: bus master, fast devsel, latency 0, IRQ 17
	Memory at ee300000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi
 
Multiple entries in dmesg:
[60383.709055] wlp82s0: Connection to AP 74:83:c2:19:df:9e lost
[60384.149855] wlp82s0: authentication with 74:83:c2:19:df:9e timed out
[60395.563700] wlp82s0: authenticate with 74:83:c2:19:df:9d
[60395.568179] wlp82s0: send auth to 74:83:c2:19:df:9d (try 1/3)
[60396.082119] wlp82s0: send auth to 74:83:c2:19:df:9d (try 2/3)
[60396.696463] iwlwifi 0000:52:00.0: No beacon heard and the time event is over already...
[60396.696541] wlp82s0: Connection to AP 74:83:c2:19:df:9d lost
[60397.142290] wlp82s0: send auth to 74:83:c2:19:df:9d (try 3/3)
[60397.756606] iwlwifi 0000:52:00.0: No beacon heard and the time event is over already...


Syslog details:
Dec  5 03:01:11 D wpa_supplicant[802]: wlp82s0: CTRL-EVENT-STARTED-CHANNEL-SWITCH freq=5220 ht_enabled=1 ch_offset=1 ch_width=80 MHz cf1=5210 cf2=0
Dec  5 03:01:13 D wpa_supplicant[802]: wlp82s0: CTRL-EVENT-BEACON-LOSS
Dec  5 03:01:14 D wpa_supplicant[802]: message repeated 5 times: [ wlp82s0: CTRL-EVENT-BEACON-LOSS ]
Dec  5 03:01:14 D wpa_supplicant[802]: wlp82s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=0 noise=9999 txrate=0
Dec  5 03:01:14 D wpa_supplicant[802]: wlp82s0: CTRL-EVENT-DISCONNECTED bssid=74:83:c2:19:df:9d reason=4 locally_generated=1
Dec  5 03:01:14 D NetworkManager[772]: <warn>  [1607166074.5520] sup-iface[0x55ce06446120,wlp82s0]: connection disconnected (reason -4)
Dec  5 03:01:14 D NetworkManager[772]: <info>  [1607166074.5576] device (wlp82s0): supplicant interface state: completed -> disconnected
Dec  5 03:01:14 D NetworkManager[772]: <info>  [1607166074.5577] device (p2p-dev-wlp82s0): supplicant management interface state: completed -> disconnected
Dec  5 03:01:14 D wpa_supplicant[802]: wlp82s0: Reject scan trigger since one is already pending
Dec  5 03:01:15 D wpa_supplicant[802]: wlp82s0: SME: Trying to authenticate with 74:83:c2:19:df:9d (SSID='A&D' freq=5220 MHz)
Dec  5 03:01:15 D kernel: [44577.801756] wlp82s0: authenticate with 74:83:c2:19:df:9d
Dec  5 03:01:15 D NetworkManager[772]: <info>  [1607166075.8417] device (wlp82s0): supplicant interface state: disconnected -> authenticating
Dec  5 03:01:15 D NetworkManager[772]: <info>  [1607166075.8417] device (p2p-dev-wlp82s0): supplicant management interface state: disconnected -> authenticating
Dec  5 03:01:15 D kernel: [44577.806415] wlp82s0: send auth to 74:83:c2:19:df:9d (try 1/3)
Dec  5 03:01:16 D kernel: [44578.421045] iwlwifi 0000:52:00.0: No beacon heard and the time event is over already...
Dec  5 03:01:16 D kernel: [44578.421084] wlp82s0: Connection to AP 74:83:c2:19:df:9d lost
Dec  5 03:01:17 D kernel: [44579.161075] wlp82s0: send auth to 74:83:c2:19:df:9d (try 2/3)
Dec  5 03:01:17 D kernel: [44579.775600] iwlwifi 0000:52:00.0: No beacon heard and the time event is over already...
Dec  5 03:01:17 D kernel: [44579.775665] wlp82s0: Connection to AP 74:83:c2:19:df:9d lost
Dec  5 03:01:18 D kernel: [44580.057137] wlp82s0: send auth to 74:83:c2:19:df:9d (try 3/3)
Dec  5 03:01:18 D kernel: [44580.671557] iwlwifi 0000:52:00.0: No beacon heard and the time event is over already...
Dec  5 03:01:18 D kernel: [44580.671624] wlp82s0: Connection to AP 74:83:c2:19:df:9d lost
Dec  5 03:01:19 D kernel: [44581.080601] wlp82s0: authentication with 74:83:c2:19:df:9d timed out
Dec  5 03:01:19 D NetworkManager[772]: <info>  [1607166079.1438] device (wlp82s0): supplicant interface state: authenticating -> disconnected



My Asus laptops, using the Broadcom drivers, have no such issues and stay connected until a reboot.

Using the GUI to go to airplane mode and back to wireless mode fixes it.
I suspect rmmod(1) and insmod(1) would also fix this issue. But why does it happen for an Intel driver and not Broadcom?

It happens about 3 hours after I stop being active on the laptop but I don't have an exact time.

I forgot to add that I'm also seeing if wifi-powersave is the issue. It was set to 3 and I'm trying 2.

See 
1. https://askubuntu.com/questions/1230140/wifi-keeps-dropping-out-ubuntu-20-04-and-broadcom-wireless-adaptor
2. https://gist.github.com/jcberthon/ea8cfe278998968ba7c5a95344bc8b55 

And I'll report back in a day or two to see if this fixes the issue.

(In reply to d from comment #136)
> I forgot to add that I'm also seeing if wifi-powersave is the issue. It was
> set to 3 and I'm trying 2.
> 
> See 
> 1.
> https://askubuntu.com/questions/1230140/wifi-keeps-dropping-out-ubuntu-20-04-
> and-broadcom-wireless-adaptor
> 2. https://gist.github.com/jcberthon/ea8cfe278998968ba7c5a95344bc8b55 
> 
> And I'll report back in a day or two to see if this fixes the issue.

Disabling Power Management doesn't make much difference. I changed DTIM to 3 on my UAP which makes this problem less frequent but WIFI never disconnects, when this happens i can still ping anything.

Jack,

You are correct, no change for me. The kernel dropped the connection despite the change, just like it has. 

It looks like the entry  https://bugzilla.kernel.org/show_bug.cgi?id=205299 is a duplicate of this. I don't have fast boot set so it's not that issue.

https://bugzilla.kernel.org/show_bug.cgi?id=210491 may be related.

I was just reading earlier entries and saw the ref to the wiki for debugging wifi. Most of the data is included but I did miss some items.

$ ethtool -i wlp82s0 | grep firmware
firmware-version: 48.4fa0041f.0

But it does seem closely related to hibernate/sleep function that I believe I have turned off but looks like it's triggering anyway. And I can't figure out where else to check.

Has anyone tried the advice from the iwlwifi module? https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi#about_platform_noise

> Disable Wi-Fi's power save (prevent the PCIe link to go to power save):
> power_scheme=1 module parameter for iwlmvm

I have added this to /etc/modprobe.d/wifi-powersave.conf

    options iwlmvm power_scheme=1

And reloaded the wifi kernel modules (I'm on Debian testing with kernel 5.9). I did not run this for long enough to check whether it permanently fixes the issue though, but given that I cannot reproduce it, it might take some time.

I'm already on 5GHz so I think this is unlikely to be relevant..

the power option does not work for me. It also reported not to work by some users. You shouldn't need to use the power option. It is just a really bad bug. 
Just cannot use the internet with this bug.

If only we had a way to trigger it, we could do git bisect and find the relevant commit. But it happens very sporadically.

As I commented some time ago, disabling powersave  has worked for me.  Still, it's a shameful bug to be fixed.

Created attachment 294123 [details]
attachment-28808-0.html

Any updates on this

On Mon, Dec 14, 2020, 2:06 AM <bugzilla-daemon@bugzilla.kernel.org> wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=203709
>
> --- Comment #143 from Sergey Slizovskiy (sereza@gmail.com) ---
> As I commented some time ago, disabling powersave  has worked for me.
> Still,
> it's a shameful bug to be fixed.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

(In reply to how from comment #141)
> the power option does not work for me. It also reported not to work by some
> users. You shouldn't need to use the power option. It is just a really bad
> bug. 
> Just cannot use the internet with this bug.

I agree that the power option should not be needed. But if it "fixes" the problem, it may give us a better idea of what might be causing the bug.

The iwlmvm power_scheme=1 option also does not seems to help the issue for my intel 8265.

Created attachment 294137 [details]
attachment-15444-0.html

Any updates on this

On Mon, Dec 14, 2020, 11:29 PM <bugzilla-daemon@bugzilla.kernel.org> wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=203709
>
> --- Comment #146 from Dirk Jonker (dirkjonker@gmail.com) ---
> The iwlmvm power_scheme=1 option also does not seems to help the issue for
> my
> intel 8265.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

I just compiled and started to use the 4.19.163 stable kernel for Ubuntu 20.04. I assumed from the discussions that this version did not have the issue. Let's see what happens.

4.15 definitely works. I think up to kernel 5.0 will work. Problem starts with 5.1 as reported.

So 4.19 will work.

(In reply to how from comment #149)
> 4.15 definitely works. I think up to kernel 5.0 will work. Problem starts
> with 5.1 as reported.
> 
> So 4.19 will work.

Kernel version 4.15+ will work with no problems. The problem is with kernel version 5+ since its been patched for new vulnerabilities for WIFI this is where the problem starts. What ever the security patch has done this is where the issue relies.

4.15 is lts for several years more. So can't be less secure than 5+

OK, between 5.0 and 5.1, I see a commit that may be related as people previously also mentioned that this may be due to buggy APs

I'm currently running v5.0-rc1 to see if it occurred between 4.9 and 5.


commit babea2d4fe76c6515da6231e8d940044bad686b1
Author: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Date:   Sun Nov 4 21:56:31 2018 +0200

    iwlwifi: mvm: Disconnect on large beacon loss
    
    Some buggy APs stop sending beacons, but continue to ack our null data
    packets or even run some traffic. It's better not to stick connected to
    such an AP forever, so disconnect after some larger beacon loss
    threshold is crossed.
    
    Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

Running Fedora and recently upgraded to Fedora 32 (kernel 5.9.13-100-fc32) so have been experiencing this problem. Have an old Fedora 30 kernel 5.0.9-301-fc30 still installed so rebooted to using that instead and this still suffers BEACON-LOSS events.

> 04:00.0 Network controller [0280]: Intel Corporation Wireless 8265 / 8275
> [8086:24fd] (rev 78)

log of NetworkManger:
> Dec 16 10:31:41 pj NetworkManager[943]: <info>  [1608114701.0423] device
> (wlp4s0): supplicant interface state: 4-way handshake -> completed
> Dec 16 10:31:41 pj NetworkManager[943]: <info>  [1608114701.0437] device
> (p2p-dev-wlp4s0): supplicant management interface state: 4-way handshake ->
> completed
> Dec 16 10:41:40 pj NetworkManager[943]: <warn>  [1608115300.5121]
> sup-iface[0x5570298a2920,wlp4s0]: connection disconnected (reason -4)
> Dec 16 10:41:40 pj NetworkManager[943]: <info>  [1608115300.5260] device
> (wlp4s0): supplicant interface state: completed -> disconnected
> Dec 16 10:41:40 pj NetworkManager[943]: <info>  [1608115300.5261] device
> (p2p-dev-wlp4s0): supplicant management interface state: completed ->
> disconnected
> Dec 16 10:41:40 pj NetworkManager[943]: <info>  [1608115300.6175] device
> (wlp4s0): supplicant interface state: disconnected -> scanning


pinging my router:
> 64 bytes from os (<ip>): icmp_seq=584 ttl=64 time=0.772 ms
> 64 bytes from os (<ip>): icmp_seq=585 ttl=64 time=0.813 ms
> 64 bytes from os (<ip>): icmp_seq=586 ttl=64 time=0.934 ms
> From pj (<ip>) icmp_seq=588 Destination unreachable: Address unreachable
> From pj (<ip>) icmp_seq=589 Destination unreachable: Address unreachable
> From pj (<ip>) icmp_seq=590 Destination unreachable: Address unreachable
> From pj (<ip>) icmp_seq=591 Destination unreachable: Address unreachable
> From pj (<ip>) icmp_seq=592 Destination unreachable: Address unreachable
> From pj (<ip>) icmp_seq=593 Destination unreachable: Address unreachable
> From pj (<ip>) icmp_seq=594 Destination unreachable: Address unreachable
> From pj (<ip>) icmp_seq=595 Destination unreachable: Address unreachable
> From pj (<ip>) icmp_seq=596 Destination unreachable: Address unreachable
> 64 bytes from os (<ip>): icmp_seq=598 ttl=64 time=2.51 ms
> 64 bytes from os (<ip>): icmp_seq=599 ttl=64 time=0.612 ms

log of wpa_supplicant:
> Dec 16 10:31:32 pj wpa_supplicant[1274]: nl80211: Event message available
> Dec 16 10:31:32 pj wpa_supplicant[1274]: nl80211: Ignored event 64
> (NL80211_CMD_NOTIFY_CQM) for foreign interface (ifindex 3 wdev 0x0)
> Dec 16 10:31:32 pj wpa_supplicant[1274]: nl80211: Drv Event 64
> (NL80211_CMD_NOTIFY_CQM) received for wlp4s0
> Dec 16 10:31:32 pj wpa_supplicant[1274]: nl80211: Beacon loss event
> Dec 16 10:31:32 pj wpa_supplicant[1274]: wlp4s0: Event BEACON_LOSS (53)
> received
> Dec 16 10:31:32 pj wpa_supplicant[1274]: wlp4s0: CTRL-EVENT-BEACON-LOSS
> Dec 16 10:31:32 pj wpa_supplicant[1274]: RTM_NEWLINK: ifi_index=3
> ifname=wlp4s0 operstate=2 linkmode=1 ifi_family=0 ifi_flags=0x1003 ([UP])
> Dec 16 10:31:32 pj wpa_supplicant[1274]: nl80211: Event message available
> Dec 16 10:31:32 pj wpa_supplicant[1274]: nl80211: Ignored event 20
> (NL80211_CMD_DEL_STATION) for foreign interface (ifindex 3 wdev 0x0)
> Dec 16 10:31:32 pj wpa_supplicant[1274]: nl80211: Drv Event 20
> (NL80211_CMD_DEL_STATION) received for wlp4s0
> Dec 16 10:31:32 pj wpa_supplicant[1274]: nl80211: Delete station
> 02:50:7f:c1:b8:16
> Dec 16 10:31:32 pj wpa_supplicant[1274]: nl80211: Event message available
> Dec 16 10:31:32 pj wpa_supplicant[1274]: nl80211: Ignored event 39
> (NL80211_CMD_DEAUTHENTICATE) for foreign interface (ifindex 3 wdev 0x0)
> Dec 16 10:31:32 pj wpa_supplicant[1274]: nl80211: Drv Event 39
> (NL80211_CMD_DEAUTHENTICATE) received for wlp4s0
> Dec 16 10:31:32 pj wpa_supplicant[1274]: nl80211: MLME event 39
> (NL80211_CMD_DEAUTHENTICATE) on wlp4s0(ac:ed:5c:73:a5:28)
> A1=02:50:7f:c1:b8:16 A2=ac:ed:5c:73:a5:28
> Dec 16 10:31:32 pj wpa_supplicant[1274]: nl80211: MLME event frame -
> hexdump(len=26): c0 00 00 00 02 50 7f c1 b8 16 ac ed 5c 73 a5 28 02 50 7f c1
> b8 16 00 00 04 00
> Dec 16 10:31:32 pj wpa_supplicant[1274]: nl80211: Deauthenticate event
> Dec 16 10:31:32 pj wpa_supplicant[1274]: wlp4s0: Event DEAUTH (11) received
> Dec 16 10:31:32 pj wpa_supplicant[1274]: wlp4s0: Deauthentication
> notification
> Dec 16 10:31:32 pj wpa_supplicant[1274]: wlp4s0:  * reason 4
> (DISASSOC_DUE_TO_INACTIVITY) locally_generated=1
> Dec 16 10:31:32 pj wpa_supplicant[1274]: wlp4s0:  * address 02:50:7f:c1:b8:16
> Dec 16 10:31:32 pj wpa_supplicant[1274]: Deauthentication frame IE(s) -
> hexdump(len=0): [NULL]
> Dec 16 10:31:32 pj wpa_supplicant[1274]: wlp4s0: CTRL-EVENT-DISCONNECTED
> bssid=02:50:7f:c1:b8:16 reason=4 locally_generated=1
> Dec 16 10:31:32 pj wpa_supplicant[1274]: wlp4s0: Auto connect enabled: try to
> reconnect (wps=0/0 wpa_state=9)

Installed & booted the following kernels and still saw the same log entries:
  * 4.20.16-200.fc29
  * 4.15.9-300.fc27

I have updated the firmware of my access point and router so will see if that makes a difference.

(In reply to p.g.richardson from comment #154)
> Installed & booted the following kernels and still saw the same log entries:
>   * 4.20.16-200.fc29
>   * 4.15.9-300.fc27
> 
> I have updated the firmware of my access point and router so will see if
> that makes a difference.

After upgrade of the firmware of both my router (draytek vigor 2862ac) and access-point (draytek vigor AP903) to the latest recommended [1][2], I've experienced none of the symptoms while running either kernel 4.20-16 or 5.9.13-100.

So, in my case, a bug in the router firmware has been the culprit. 

[1] https://www.draytek.co.uk/support/downloads/vigor-2862
[2] https://www.draytek.co.uk/support/downloads/vigorap-903

Hi,
I tested sever kernels and can say (very likely), this bug is not in 5.0x kernel (never experienced this issue), but in kernel 5.1 always got this bug.
Lubo

Hi,

Just an update, I have fixed the issue with No Beacon, it seems to be related to Ubiqutis Firmware i had a issue with my Access Point which i had to fix after a firmware update. Spent 16 hours straight trying to solve the issue i had with the AP. UniFi firmware 4.3.21 and UniFi firmware 4.3.24 both has issues i downgraded to 4.3.20 and i havent had this No Beacon heard for the past 3 days now.

If anyone has a Ubiquti Access Point i would recommend downgrade to 4.3.20 version, the past two firmware updates are known to have problems.

Hope this helps.

Cheers.

Jack.

Created attachment 294355 [details]
attachment-10169-0.html

How would I tell what my access point is running? 

And why this isn't an issue on the two machines with NON-Intel chips. The Broadcom chipset doesn't have this issue.



So I'm not convinced, at least not yet.



David





---- On Sun, 27 Dec 2020 02:02:42 +0000  <bugzilla-daemon@bugzilla.kernel.org> wrote ----


https://bugzilla.kernel.org/show_bug.cgi?id=203709 
 
--- Comment #157 from Jack Bamford (mailto:jack@violetdragonsnetwork.co.uk) --- 
Hi, 
 
Just an update, I have fixed the issue with No Beacon, it seems to be related 
to Ubiqutis Firmware i had a issue with my Access Point which i had to fix 
after a firmware update. Spent 16 hours straight trying to solve the issue i 
had with the AP. UniFi firmware 4.3.21 and UniFi firmware 4.3.24 both has 
issues i downgraded to 4.3.20 and i havent had this No Beacon heard for the 
past 3 days now. 
 
If anyone has a Ubiquti Access Point i would recommend downgrade to 4.3.20 
version, the past two firmware updates are known to have problems. 
 
Hope this helps. 
 
Cheers. 
 
Jack.

(In reply to d from comment #158)
> Created attachment 294355 [details]
> attachment-10169-0.html
> 
> How would I tell what my access point is running? 
> 
> And why this isn't an issue on the two machines with NON-Intel chips. The
> Broadcom chipset doesn't have this issue.
> 
> 
> 
> So I'm not convinced, at least not yet.
> 
> 
> 
> David
> 
> 
> 
> 
> 
> ---- On Sun, 27 Dec 2020 02:02:42 +0000 
> <bugzilla-daemon@bugzilla.kernel.org> wrote ----
> 
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=203709 
>  
> --- Comment #157 from Jack Bamford (mailto:jack@violetdragonsnetwork.co.uk)
> --- 
> Hi, 
>  
> Just an update, I have fixed the issue with No Beacon, it seems to be
> related 
> to Ubiqutis Firmware i had a issue with my Access Point which i had to fix 
> after a firmware update. Spent 16 hours straight trying to solve the issue i 
> had with the AP. UniFi firmware 4.3.21 and UniFi firmware 4.3.24 both has 
> issues i downgraded to 4.3.20 and i havent had this No Beacon heard for the 
> past 3 days now. 
>  
> If anyone has a Ubiquti Access Point i would recommend downgrade to 4.3.20 
> version, the past two firmware updates are known to have problems. 
>  
> Hope this helps. 
>  
> Cheers. 
>  
> Jack.


No idea but anything is possible. What Access Point do you have? if its Ubiquti you can retrieve it by clicking on your AP and looking down Overview in the controller.

(In reply to Ozan Caglayan from comment #152)
> OK, between 5.0 and 5.1, I see a commit that may be related as people
> previously also mentioned that this may be due to buggy APs
> 
> I'm currently running v5.0-rc1 to see if it occurred between 4.9 and 5.
> 
> 
> commit babea2d4fe76c6515da6231e8d940044bad686b1
> Author: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
> Date:   Sun Nov 4 21:56:31 2018 +0200
> 

According to the above commit, 
I changed the timeout value
```
#define IWL_MVM_MISSED_BEACONS_THRESHOLD_LONG 16
```
in drivers/net/wireless/intel/iwlwifi/mvm/mvm.h to
```
#define IWL_MVM_MISSED_BEACONS_THRESHOLD_LONG 128
```

Now everything goes well without any change of module parameters.
It seems the timeout value is too small in my case.

I have run into this bug for a few months, but only now started looking for a solution.

I am running Debian 10 on a Lenovo Thinkpad E570 with an AX200 Wifi card talking to a ASUS AX6100, though this same problem manifests itself with other access points.  

My kernel is currently Linux x501b 5.9.0-0.bpo.2-amd64 #1 SMP Debian 5.9.6-1~bpo10+1 (2020-11-19) x86_64 GNU/Linux

Changing the beacon interval to 50ms has during the last 12 hours eliminated the problem.  I generally experienced the issue 3 to 4 times per day, so I am keeping my fingers crossed.

By the way, I can trigger BEACON LOSS on demand by connecting via 2.4GHz and running my microwave oven.

Salute, comrades! 
In order to avoid the BEACON LOSS problem, you need to set BEACON intervals in your access points: for 5.8 GHz 100, for 2.4 GHz 200. After setting these values, the problem will disappear !!!

Sounds reasonable, but not a proper solution for the laptop to work with any access point.  Can the expected BEACON intervals be raised in the WLAN driver?

(In reply to Eaglet from comment #162)
> Salute, comrades! 
> In order to avoid the BEACON LOSS problem, you need to set BEACON intervals
> in your access points: for 5.8 GHz 100, for 2.4 GHz 200. After setting these
> values, the problem will disappear !!!

And not everyone has access to the change the beacon settings in the access point. The real fix is the change the NHonda committed (3 posts away, on 27 Dec).

And not everyone has the knowledge to build their own kernels.

Which Wifi-driver would say "I'm receiving too many beacons, let's disconnect"?
100 is pretty much the standard setting for all DD-WRT and Tomato routers. Also ASUS's router firmware uses it as a default. This doesn't sound reasonable at all! (a workaround is always though)

I am not an expert, but the name of the variable: "IWL_MVM_MISSED_BEACONS_THRESHOLD_LONG" sounds like these are the MISSED beacons. So I can interpret it that it needs to seem to miss 128 beacons before disconnecting (instead of a smaller amount).

(In reply to Sven Köhler from comment #165)
> Which Wifi-driver would say "I'm receiving too many beacons, let's
> disconnect"?
> 100 is pretty much the standard setting for all DD-WRT and Tomato routers.
> Also ASUS's router firmware uses it as a default. This doesn't sound
> reasonable at all! (a workaround is always though)

Sorry, I was responding to comment #162 suggesting to _increase_ the time between beacons sent by the access point.

(In reply to Sergey Slizovskiy from comment #166)
> I am not an expert, but the name of the variable:
> "IWL_MVM_MISSED_BEACONS_THRESHOLD_LONG" sounds like these are the MISSED
> beacons. So I can interpret it that it needs to seem to miss 128 beacons
> before disconnecting (instead of a smaller amount).

This bug is not solely an Intel issue, it’s the very same on a Qualcomm Atheros AR93xx Wireless Network Adapter. The latest kernel made the network very unstable, ping got worse and the network would deauthenticate a lot.

(Reason: 9=STA_REQ_ASSOC_WITHOUT_AUTH)

Please fix this asap!

(In reply to kernelspace from comment #168)
> This bug is not solely an Intel issue, it’s the very same on a Qualcomm
> Atheros AR93xx Wireless Network Adapter. The latest kernel made the network
> very unstable, ping got worse and the network would deauthenticate a lot.
> 
> (Reason: 9=STA_REQ_ASSOC_WITHOUT_AUTH)
> 
> Please fix this asap!

I agree with you that this is not an Intel driver problem. This is a problem with the AP drivers and the NDIS EEPROM of the APs. Also, this problem can be caused by sysctl settings in access points - this is a consequence of incorrectly written NDIS EEPROM for the WiFi module and its access point drivers for the Linux kernel.
I had a similar issue with hotspot on OpenWRT. The problem was almost completely solved by more liberal sysctl settings in the OpenWRT access point.

(In reply to Eaglet from comment #169)
> (In reply to kernelspace from comment #168)
> > This bug is not solely an Intel issue, it’s the very same on a Qualcomm
> > Atheros AR93xx Wireless Network Adapter. The latest kernel made the network
> > very unstable, ping got worse and the network would deauthenticate a lot.
> > 
> > (Reason: 9=STA_REQ_ASSOC_WITHOUT_AUTH)
> > 
> > Please fix this asap!
> 
> I agree with you that this is not an Intel driver problem. This is a problem
> with the AP drivers and the NDIS EEPROM of the APs. Also, this problem can
> be caused by sysctl settings in access points - this is a consequence of
> incorrectly written NDIS EEPROM for the WiFi module and its access point
> drivers for the Linux kernel.
> I had a similar issue with hotspot on OpenWRT. The problem was almost
> completely solved by more liberal sysctl settings in the OpenWRT access
> point.

Downgrading the Firmware on my UAP Lite solved the problem for me ive tried known Distros that was causing me issues, Ubuntu 18.04, 20.04, PopOS after downgrading to 4.3.20.11298 problem is solved. Ive tested with both 4.3.21, 4.3.24 are problematic i was also suffering with drops out on my Phone so not sure if it was related to the issue i was seeing on Ubuntu but 4.3.20.11298 solved the issue.

In my Testing to trigger it, refreshing or reloading the DHCP Server on pfSense. Problem started back in November 1st last year.

Hope this gives more of a idea to what is happening.

Created attachment 294585 [details]
Module parameter for beacon timeout

Building on Ozan and Nhonda's observations, I made this little patch that makes the beacon timeout a runtime-configurable kernel parameter, keeping the default of 16 missed beacons. It seems to resolve the issue for me (with a timeout of 256 missed beacons).

Even if this is an issue entirely external to iwlwifi (buggy AP etc.), it seems that other drivers both for Linux and other operating systems tolerate these conditions, so there should still be some sort of fix in iwlwifi.

Without this fix, my wifi becomes completely unusable for long stretches due to repeated disconnects every few days (likely correlated with network conditions).

(In reply to mikezackles from comment #172)
> Created attachment 294585 [details]
> Module parameter for beacon timeout
> 
> Building on Ozan and Nhonda's observations, I made this little patch that
> makes the beacon timeout a runtime-configurable kernel parameter, keeping
> the default of 16 missed beacons. It seems to resolve the issue for me (with
> a timeout of 256 missed beacons).
> 
> Even if this is an issue entirely external to iwlwifi (buggy AP etc.), it
> seems that other drivers both for Linux and other operating systems tolerate
> these conditions, so there should still be some sort of fix in iwlwifi.
> 
> Without this fix, my wifi becomes completely unusable for long stretches due
> to repeated disconnects every few days (likely correlated with network
> conditions).

This is an access point problem only, not the iwlwifi driver!!! The source of the access point problem:
1) problems in the WiFi hotspot driver;
2) the problem is in the EEPROM of the WiFi chip;
3) the problem is in the settings of the access point software (wpasupplicant, hostapd & etc ...) incompatible with the WiFi driver of the access point.

From my experience using OpenWRT, I can definitely say that such a problem is quickly fixed by the correct software parameters (wpasupplicant, hostapd & etc ...) for the WiFI driver used by the access point.

If you patch the iwlwifi driver as you want (reduce BEACON to a critically possible level), then you will encounter degradation in the performance of the WiFi system on your laptop / computer, i.e., you will actually decrease the speed parameters of your Linux system when working with network.
I repeat for those who do not check this problem and do not find out its causes in practice: THIS IS NOT A PROBLEM of the iwlwifi driver, IT IS EXCLUSIVELY AN ACCESS POINT PROBLEM !!!

> From my experience using OpenWRT, I can definitely say that such a problem
> is quickly fixed by the correct software parameters (wpasupplicant, hostapd
> & etc ...) for the WiFI driver used by the access point.

I'm glad you found a fix that works for you, but not everyone runs OpenWRT or is in a position to make many customizations at the access point. If other drivers are tolerating this just fine, there isn't much incentive for commercial vendors to worry about it.
 
> If you patch the iwlwifi driver as you want (reduce BEACON to a critically
> possible level), then you will encounter degradation in the performance of
> the WiFi system on your laptop / computer, i.e., you will actually decrease
> the speed parameters of your Linux system when working with network.

If you look back at my patch and what I wrote, it defaults to the existing behavior (16 missed timeouts), but it allows people who are out of options to customize the timeout so that they can actually use the network. I'm not sure why that upsets you.

Even if this is an access point bug, it seems to be a widely deployed one, making it something that (imo) iwlwifi should worry about. Something along the lines of my patch acknowledges that the existing behavior is the desired one but provides a workaround when that's not enough.

Eh, I don't really follow the discussion anymore, but consider that:

1. I can reproduce the problem with my intel wifi (Intel 8260) on many different access points where none of other ~15+ devices has any issues at all
2. The problem does not show up on any access points if I use the exact same hardware _but_ the wifi adapter (TP-Link AC600 wireless Realtek RTL8811AU) without any obvious drawbacks.

It's really hard to see how the above could be the case if it was "EXCLUSIVELY AN ACCESS POINT PROBLEM"

(In reply to kotrfa from comment #175)
> Eh, I don't really follow the discussion anymore, but consider that:
> 
> 1. I can reproduce the problem with my intel wifi (Intel 8260) on many
> different access points where none of other ~15+ devices has any issues at
> all
> 2. The problem does not show up on any access points if I use the exact same
> hardware _but_ the wifi adapter (TP-Link AC600 wireless Realtek RTL8811AU)
> without any obvious drawbacks.
> 
> It's really hard to see how the above could be the case if it was
> "EXCLUSIVELY AN ACCESS POINT PROBLEM"

You were told what the problem is: it's in the access points. Variants of the problem in points of access by me are given in the previous message. If something is difficult for you to understand, then you have not tested what I tested (I described the causes of the problem in access points in three points). Understanding only happens if you have relevant experience, which you do not yet have, but I do. And if so, then not a troll!
I have tested all possible causes (indicated in three points). And you could not test it and have the audacity to point out!

Eaglet:

I'm sorry, I don't see kotrfa@ as a troll. I have the same issue. 

How long were you running your tests for? We're talking about days and if your tests only ran for a few hours you may not have triggered the issue.

When I'm running my ThinkPad P73 under Windows (god save my soul) there is no issue, for days. Under Ubuntu 20.04, I get a disconnect between 1am and 4am 90% of the time. 

So I don't believe it's a firmware or AP issue, at least not at this point.

Also, how would the average user, who can't compile a kernel access the parameter you've made available? I don't believe there is a CLI or configuration file that would allow this to be set at boot time.

I can add that my two Asus laptops and Asus PC motherboard, all running Ubuntu 20.04 but using the Broadcom chips do not exhibit this failure.

This is all with an Ubiquiti AP that I don't have access to change settings on (even if I knew the Unifi interface).

So if you can explain why, when Windows works on this laptop, but linux fails I'd be interested. If you can tell me what I should ask the network people to look for in their logs or settings it may help get to the bottom of this.

(In reply to d from comment #177)
> Eaglet:
> 
> I'm sorry, I don't see kotrfa@ as a troll. I have the same issue. 
> 
> How long were you running your tests for? We're talking about days and if
> your tests only ran for a few hours you may not have triggered the issue.
> 
> When I'm running my ThinkPad P73 under Windows (god save my soul) there is
> no issue, for days. Under Ubuntu 20.04, I get a disconnect between 1am and
> 4am 90% of the time. 
> 
> So I don't believe it's a firmware or AP issue, at least not at this point.
> 
> Also, how would the average user, who can't compile a kernel access the
> parameter you've made available? I don't believe there is a CLI or
> configuration file that would allow this to be set at boot time.
> 
> I can add that my two Asus laptops and Asus PC motherboard, all running
> Ubuntu 20.04 but using the Broadcom chips do not exhibit this failure.
> 
> This is all with an Ubiquiti AP that I don't have access to change settings
> on (even if I knew the Unifi interface).
> 
> So if you can explain why, when Windows works on this laptop, but linux
> fails I'd be interested. If you can tell me what I should ask the network
> people to look for in their logs or settings it may help get to the bottom
> of this.

The problem is actually much more interesting. I was able to reproduce this issue when my laptop with Intel Link 5100 chip was connected to an OpenWRT router based on MTK7620A chip. With the standard WiFi chip EEPROM, my laptop had no connection problems even when trying to use 80211n mode, which is not recommended by the OpenWRT developers. After downgrade the current version of the WiFi EEPROM chip on my router to the EEPROM version from 2016 and using the 80211n mode, problems began with BEACON-LOST: a lot of this appeared in the logs of my laptop. After disabling 80211n support and enabling only 80211g mode in OpenWRT (version 19.07.5 /latest/) with 2016 EEPROM firmware, BEACON-LOST messages no longer appeared. Then I updated the EEPROM of my WiFi chip (MTK7620A) on the router again to the 2019 version (without changing the installed version and OpenWRT settings). BEACON-LOST messages also stopped appearing. From what I concluded that the problem is/or/and: 1) EEPROM; 2) WiFi router driver; 3) settings of the 80211 operating mode in software AP. Or in a combination of these reasons.
As you can see, the problem is not in the Intel driver for Linux, but in the access point.
I hope I have satisfied your interest on this issue.

> Also, how would the average user, who can't compile a kernel access the
> parameter you've made available? I don't believe there is a CLI or
> configuration file that would allow this to be set at boot time.

There is no way for a user to change this timeout without recompiling the kernel. My patch makes it a module parameter configurable at boot in the standard ways (https://wiki.archlinux.org/index.php/Kernel_module#Setting_module_options) or by writing to the file /sys/module/iwlwifi/parameters/beacon_timeout as root. Absent a more complete fix, it would be nice to upstream something along the lines of my patch to the mainline kernel seeing as how this has been an issue for so long, and many users don't have a workaround. That way users could configure the timeout without needing to compile a kernel. But I'm just a frustrated user, not (at all) an expert in this area, and I don't have a ton of time to go digging.

Let us stop blaming WiFi router. When it works for other Operating Systems, you can imagine a situation that you will not be allowed to change the driver of the router.  
What makes me feel the problem is not yet  fully understood is that there are at least two workarounds: one with BEACON wait interval,  another with "add to /etc/modprobe.d/iwlwifi.conf the following:
> options iwlmvm power_scheme=1
> options iwlwifi power_save=0  "

Are these two "solutions" related?  Are the beacons missed due to adaptor going to sleep? Or, is it vice versa: WiFi Adaptor goes to sleep due to missed beacons?

> > options iwlmvm power_scheme=1
> > options iwlwifi power_save=0  "

For what it's worth, these did not resolve the issue for me.

> Are these two "solutions" related?  Are the beacons missed due to adaptor
> going to sleep? Or, is it vice versa: WiFi Adaptor goes to sleep due to
> missed beacons?

This might be a clue: https://github.com/torvalds/linux/blob/d635a69dd4981cc51f90293f5f64268620ed1565/include/net/mac80211.h#L2869-L2928

I am in agreement that the problem isn't fully understood.

(In reply to Eaglet from comment #176)

> You were told what the problem is: it's in the access points. Variants of
> the problem in points of access by me are given in the previous message. If
> something is difficult for you to understand, then you have not tested what
> I tested (I described the causes of the problem in access points in three
> points). Understanding only happens if you have relevant experience, which
> you do not yet have, but I do. And if so, then not a troll!
> I have tested all possible causes (indicated in three points). And you could
> not test it and have the audacity to point out!

I am not an expert, I am a regular user who barely understands what's going on here. I have been trying to provide relevant information and support as you can see in the earlier comments. In my message you reacted to, I only asked considering (I used exactly this word) the observations and that the conclusion seems unlikely to me. 

Your answer could be simply "not relevant" and I would take it, but instead I am asked to stop trolling and that I am rude? I am grateful for your contribution, but your answer is fairly offensive and simply makes me less likely to contribute the next time. 


> options iwlmvm power_scheme=1
> options iwlwifi power_save=0

did not solve it for me either

(In reply to kotrfa from comment #182)
> (In reply to Eaglet from comment #176)
> 
> > You were told what the problem is: it's in the access points. Variants of
> > the problem in points of access by me are given in the previous message. If
> > something is difficult for you to understand, then you have not tested what
> > I tested (I described the causes of the problem in access points in three
> > points). Understanding only happens if you have relevant experience, which
> > you do not yet have, but I do. And if so, then not a troll!
> > I have tested all possible causes (indicated in three points). And you
> could
> > not test it and have the audacity to point out!
> 
> I am not an expert, I am a regular user who barely understands what's going
> on here. I have been trying to provide relevant information and support as
> you can see in the earlier comments. In my message you reacted to, I only
> asked considering (I used exactly this word) the observations and that the
> conclusion seems unlikely to me. 
> 
> Your answer could be simply "not relevant" and I would take it, but instead
> I am asked to stop trolling and that I am rude? I am grateful for your
> contribution, but your answer is fairly offensive and simply makes me less
> likely to contribute the next time. 
> 
> 
> > options iwlmvm power_scheme=1
> > options iwlwifi power_save=0
> 
> did not solve it for me either

You have inflicted no less insult upon me and received what you deserve. From now on, learn to be courteous and this will not happen to you again.

Eaglet,

Thanks for the URL. I'm having issues getting it the parameters to show-up under /sys/module/<anything> but that is my issue to learn.

When I have it working I'll post what I've set and how the results worked. This may work around the several possible causes of different interactions of firmware, drivers and APs.

FYI for people coming in late I did try using /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf with:
wifi.powersave = 2 

for several weeks but that didn't change anything.

Disabling power saving has worked for me, as I reported above. Following the clue of mikezackles, it now looks reasonable that either we increase the beacon wait time,  or, we disable the beacon filtering support (which will increase the beacon frequency reported by hardware).  It is also logically possible that a beacon filtering support is not working as expected in the driver. 

(In reply to mikezackles from comment #181)

> 
> This might be a clue:
> https://github.com/torvalds/linux/blob/
> d635a69dd4981cc51f90293f5f64268620ed1565/include/net/mac80211.h#L2869-L2928
> 
> I am in agreement that the problem isn't fully understood.

It is not an Access Point bug.  Why all other devices and Windows work as expected except the one with iwlwifi on Linux Kernel 5.1 and above? You revert the Kernel to 4.15 and works as normal as other devices.

While I'm not on the dev team the revision to a 4.15 kernel is interesting.

Have you tried the 4.15 kernel with the latest driver? 

I don't think this is a trival problem for the people working on this.

Unfortunately I'm not in position to revert to earlier kernels but it may be an issue for some specific Intel chip sets.

I am using the Kernel 4.15.0-124 LTS. I managed to revert to 4.15 by booting to USB Mint 19.3 install the kernel,then copy the files to Mint 20. So the drivers are from 19.3. 

I cannot try the new drivers since the kernel 4.15 is compiled with gcc7. Mint 20 uses gcc9.

The commit that Ozan pointed out (between 5.0 and 5.1) is where the disconnect/timeout is introduced, so it would make sense that the problem doesn't happen before that point: https://github.com/torvalds/linux/commit/babea2d4fe76c6515da6231e8d940044bad686b1#diff-87e4eb6cde9b874e4303cc17a793ac5e5fc194f6b22d9d3ae3f74d2fffc71463

> Why all other devices and Windows work as expected except the one with
> iwlwifi on Linux Kernel 5.1 and above?

One possibility is that other drivers don't intentionally disconnect after too many missed beacons. Note that the commit above mentions buggy APs specifically. It seems like the author was hoping that reconnecting would get the AP to start sending beacons again, but this seems like it may not be the case. This would be in line with what Emmanuel said:

> We disconnected because we couldn't hear beacons from almost a second and
> then we couldn't re-connect because we couldn't hear beacons during the
> connection phase.

If this is true and there is nothing else fishy going on in iwlwifi it might even make sense to just revert the commit because it is not accomplishing its intent of getting the AP to start sending beacons again. Or something like my patch would be an alternative.

Is anyone in a position to set up a second machine as an air sniffer? (https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging) As best I can tell this is where the devs left off asking for information, so if we get this to them maybe they will be able to make some progress.

It is not just disconnects or miss beacons. At times when it is still connected, the performance is very slow and the response is very slow. You can use speedtest, the page actually loads and took a long time to appear. When the test started you only get a few megabits. Other drivers don't have performance or connection issues. All APs works with other wifi hardware except iwlifi, even Windows Intel wifi works. Other Linux drivers uses the same wifi stack. 

The commit suggest to patch all APs? APs are not buggy. There is no AP firmware to suggest connection issues.

The commit is only for iwlwifi. If it is a buggy AP all other wifi drivers then should have the same code, but is it?

@how: I'm not a dev but I think it's more complex. If it was just the driver then all Intel chip sets would be affected. And they are not.

It's weird and I think it's interaction with the kernel for some cases. I've used the modules configuration to set both variables to 256 and did not loose connection for the first time for 3 weeks. So I'm still testing.

Look at my earlier comments, initially I blamed the driver but on testing it's an interaction that the devs are having a hard time to clearly identify what's happening. 

My best guess is a kernel/driver edge case that is not handled cleanly but works when the missed beacon setting is set very high.

(In reply to d from comment #192)
> My best guess is a kernel/driver edge case that is not handled cleanly but
> works when the missed beacon setting is set very high.

Signal level might affect it as well, so the further away the AP is the more likely the bug will occur.

(In reply to kernelspace from comment #193)
> Signal level might affect it as well, so the further away the AP is the more
> likely the bug will occur.

Exactly! Disabling power savings fixed it for me, until I moved my desk into another room where the signal is weaker and now, it is unbearable. I had to bring Ethernet into this room in order to still be able to work (but my wife's mac works perfectly fine with the wifi in this new room). 

And regarding AP bugs: this is beyond the point in the sense that if all other drivers / adapters work fine, this one should implement a workaround if this is truly an AP bug (see the robustness principle: "Be conservative in what you send, be liberal in what you accept"). When traveling, I often have this problem and it is not reasonable to expect that I could patch the firmware of the AP of the hotel / office / conference center where I am. And my wifi getting lost so often gives a bad name to Linux and Intel...

The observation of Mathias  about distance-dependence may explain why some people (like me) claim that disabling power-saving  sort of helps. Indeed, I have not tried it further away from the router.
Here I quote an email reply from Andrei and Luca from Intel who worked on the commits https://github.com/torvalds/linux/commit/babea2d4fe76c6515da6231e8d940044bad686b1#diff-87e4eb6cde9b874e4303cc17a793ac5e5fc194f6b22d9d3ae3f74d2fffc71463
quoted above:

I believe that the patch you're referring to is not the root cause for the issue, but rather a real beacon loss that is detected instead of being ignored.
Actually this patch was done as a customer bugfix due to our station not roaming correctly between APs when we stop hearing the beacons of one of them - so it is totally intended.
There might be several reasons for such a large beacon loss - first it may be a really buggy AP that stops transmitting beacons. In this case we have nothing to do.
Keeping connection to an AP that we can't hear its beacons is unhealthy and after some short period of time we will be completely out of sync - loosing multicast traffic, 
not being able to perform any power saving procedures etc.. If this issue is not seen for some larger values of IWL_MVM_MISSED_BEACONS_THRESHOLD_LONG,
we may probably consider making it configurable through some module param. Luca, what do you think?
Anyway, though it is hard to follow the bug thread a bit as it is a mix of multiple different issues, I've noticed that people claim that disabling power save "solves" the issue.
Since disabling power save shouldn't change anything about real over the air beacon loss, I suspect here a fw issue.
Please follow the procedures here: https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging to collect the trace-cmd and core dump as well.
If you have another machine with a wireless NIC that you can use as an air sniffer, this would be very helpful as well.

I don't think introducing a mod parameters is the right way to go.  As Andrei said, this is probably a FW bug.  Can you try to replace the FW with the ones from this commit (the previous version) instead?

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=5ee1c7d65c26b90b796362ac1b5715435e2a1384

Switched to it, let's see what happens. Nice to hear from some people involved finally.

Hi folks!
I just join the discussion and try to read all the comments above.

I'm having the same issue with an **Intel Corporation Wi-Fi 6 AX201**

I tried the following module's configuration but it didn't work as well.

```
options cfg80211 cfg80211_disable_40mhz_24ghz=1
options iwlmvm power_scheme=1
options iwlwifi swcrypto=0
options iwlwifi bt_coex_active=1
options iwlwifi power_save=0
options iwlwifi uapsd_disable=1
```

I set Beacons intervals in my [TP-Link AX50](https://www.tp-link.com/us/home-networking/wifi-router/archer-ax50/) but didn't work as well. I also tried with 2 other routers and I still had the same problem.

My only way to connect in this room for the moment is by using tethering with my mobile. As others have mentioned, all my other devices have no problem connecting in the same zone.

I'm glad to help to find the root of this issue.

In chasing a moving target I have not had a dropout for 3 days with:

options iwlwifi IWL_MVM_MISSED_BEACONS_THRESHOLD=256
options iwlwifi IWL_MVM_MISSED_BEACONS_THRESHOLD_LONG=256

On Ubuntu 20.04 using the kernel 5.4.0-62-generic.

However there is a firmware update for the EUFI: Version 12.0.70.1652 (LVFS: 192.70.1652)

So this invalidates my current assumptions and will remove my settings and see what happens with a reboot and default values.

I have checked the below commands on my 8275 card and these did NOT help.
(In reply to d from comment #199)
> options iwlwifi IWL_MVM_MISSED_BEACONS_THRESHOLD=256
> options iwlwifi IWL_MVM_MISSED_BEACONS_THRESHOLD_LONG=256
Namely, the command ping google.com  gives 8% packet loss.
On the other hand, the option to disable power saving stops the package loss. 

Probably, these above commands had no effect since my kernel have not been patched.

I can confirm that

options iwlwifi IWL_MVM_MISSED_BEACONS_THRESHOLD=256
options iwlwifi IWL_MVM_MISSED_BEACONS_THRESHOLD_LONG=256

does not solve the problem.

$ nmcli
wlp3s0: nicht verbunden
        "Intel 7265"
        1 Verbindung verfügbar
        wifi (iwlwifi), 94:65:9C:91:36:AB, hw, mtu 1500

The syslog shows

wpa_supplicant[644]: wlp3s0: CTRL-EVENT-BEACON-LOSS

Created attachment 294779 [details]
complete syslog output

My WLAN lost connection at around 11:57. Then I reconnected and the connection was lost again.

I use Ubuntu 20.10 with kernel 5.8.0-38-generic. I've had this problem since Ubuntu 20.04. I didn't have this problem with earlier version of Ubuntu.

Created attachment 294787 [details]
syslog

Another excerpt from syslog.

Also, 

options iwlmvm power_scheme=1
options iwlwifi power_save=0

didn't help.

With the upgrade to kernel 5.10 in fedora my wifi work now without any issue.

I have not experienced any issues since the upgrade to 5.10 on Debian.

Created attachment 294811 [details]
dmesg output

After upgrading to 5.10 on Ubuntu 20.10, the messages are still in the syslog. However, the system succesfully reconnected instead of dropping the connection as before.

Problem persists with kernels 5.10 and 5.11-RC4.

It seems I was too fast in reporting the lack of issues with kernel 5.10 as in the past 2 days the logs show beacon loss again, after a period of 10 days without any issues, which was a lot more than before.

I was just able to run the following command from a mac connected to the same AP while the problem is happening:

sudo tcpdump -l --interface=en0 -I type mgt subtype beacon and wlan[20:2] == 0xABCD | pv --line-mode -F "Total Beacons: %b Beacons/sec: %r" > /dev/null

(where ABCD is the final two bytes of the BSSID)

This command reports ~10 beacons per second both when the issue is occuring and when it is not.

@Luca To me this seems like pretty strong evidence that this is a firmware bug as opposed to the access point not sending beacons, but maybe I'm misunderstanding as I'm ignorant of the details of this process.

Absent any breakthroughs here I will try to get a dump with more information next time (may take a few weeks for me to get to it).

I have not yet tried the old firmware as requested.

Hello @Dirk Jonker 

This looks like a FW issue. So, can you please share FW logs. Following link will assist you to collect FW logs.

https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging#firmware_debugging

Hello mikezackles,
Thanks for the information. Please try old firmware.
If you are still facing the issue. Please share FW logs.

Hi,

Just a note that I'm experiencing this problem on 5.10.  I have a Lenovo X1 Carbon v7 and firmware version 46.4d093a30.0 9000-pu-b0-jf-b0.

Unlike some other people, I experience this problem multiple times per hour.  This might be caused by placing my laptop lid near an external monitor.  We have two APs (one older, one new), and I only experience it with one of them.

Debian kernels don't have CONFIG_IWLWIFI_DEBUG set, so I need to recompile the kernel before I can follow the firmware debugging instructions posted above.  However, I plan to do this in the next week or so.  I plan to try to old firmware as well.  Thanks @Abishek Naik!

-BenRI

So I've been using my laptop with the updated firmware suggested in
https://bugzilla.kernel.org/show_bug.cgi?id=203709#c196

and the issue did not happen again for me in a period of 15 days. I just noticed that the firmware file was replaced back with the Ubuntu's shipped one during a package update.. I just replaced it back with the suggested one (36.79ff3ccf.0) to observe more.

Hello. I made an account just to tell what worked for me.

Context: on Ubuntu 20.04, constantly dropped connections, especially apparent with bluetooth enabled. "dmesg | grep iwl" gave the same, repeating "No beacon heard and the time event is over already..." message.

Solution: Changed from WPA&WPA2 to WPA2. I left the encryption mode to AES. I also changed the name of the SSID to all lowercase and no spaces.

Hello, let me share what helped me.  

My Access Point (AP) is Mikrotik, OS Fedora 33, kernel 5.8.18-300.fc33.x86_64, Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78).  

I was getting repeated connectivity losses under load, which were starting with error:
```
wpa_supplicant[1523]: wlp2s0: CTRL-EVENT-BEACON-LOSS
```
followed by:
```
wlp2s0: CTRL-EVENT-DISCONNECTED bssid=74:4d:28:b3:e6:73 reason=4 locally_generated=1
```

The issue started to happen when I played with the AP settings and set "HW. protection mode" to value "CTS to self". It took me a while to realize, but now it works for 3 days already.

Created attachment 295421 [details]
dmesg after exiting the last suspend

After a short time, after exiting suspend, a single loss of connection to the access point. The frequency and intensity of connection losses with the access point is random, from a single loss to an intense one several times in a row. After the connection to the access point is restored, the connection is stable. Until the next connection loss. The laptop is in the same place and does not move.

# lspci -k | grep -A2 Net
03:00.0 Network controller: Intel Corporation Wireless 3160 (rev 93)
	Subsystem: Intel Corporation Dual Band Wireless AC 3160
	Kernel driver in use: iwlwifi


# uname -rm
5.4.62-std-def-alt1 x86_64


# iwconfig wlan0 
wlan0     IEEE 802.11  ESSID:"AP"  
          Mode:Managed  Frequency:2.462 GHz  Access Point: xx:xx:xx:xx:xx:xx   
          Bit Rate=65 Mb/s   Tx-Power=22 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=62/70  Signal level=-48 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:7   Missed beacon:0