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

As another data point, I used to have my connection dropped multiple times per day with "No beacon heard and the time event is over already..." messages.

However, on Feb 23rd this inexplicably stopped --- without a reboot! 

I'm running Debian unstable, with kernel 5.10.0-3-amd64.  Firmware version is iwlwifi-9000-pu-b0-jf-b0-46.ucode.

I searched for software that was upgraded on that day, but didn't find anything that looked relevant.  The router firmware seems to be unchanged.  So, I can't explain why the problem stopped.

-BenRI

Hello @Yury Pakin,
      Thanks for sharing dmesg logs. But this looks like a FW issue. So can you please share FW logs.
      Please refer to Firmware Debugging section in below link for steps to collect firmware logs.
      https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging

Thanks.

Created attachment 295645 [details]
Firmware dump crash

Hello,

This is the card model

00:14.3 Network controller: Intel Corporation Wireless-AC 9560 


Here the error log:
https://pastebin.com/LY771WXg

I have had this problem on the 7260 ever since upgrading Ubuntu from 18.04 LTS (4.15 kernel / 17.948900127.0 7260-17.ucode) to 20.04 LTS (5.4 kernel / 17.3216344376.0 7260-17.ucode). It manifests as reported above, frequent disconnects, with numerous "No beacon heard and the time event is over already..." and CTRL-EVENT-BEACON-LOSS trace from wpa_supplicant. 

After downgrading the kernel to 4.15 (keeping FW at version 17.3216344376.0), I no longer have the problem with disconnects. Of note, CTRL-EVENT-BEACON-LOSS traces persist, even though there are no disconnects. Seems like a spurious beacon loss reported by the FW. I have not tried downgrading the FW since seeing the bug, but I have never had a single CTRL-EVENT-BEACON-LOSS while running the 17.948900127.0 FW. Other devices on the same AP do not have disconnect issues.

My bet is this is a FW bug, likely dating back to: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=58265e0def90e8f1b6c1987fbf70af983e84d514.

It did not start manifesting in disconnects until the patch mentioned in earlier comments, to disconnect in case of large beacon loss, which landed in the 5.1 kernel. (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c?id=babea2d4fe76c6515da6231e8d940044bad686b1).

If it helps, I will collect FW debug logs.

This beacon problem is not on a particular firmware, not on a particular Intel wifi device. You are using a 7260, I am using a 8260 on a 8000C firmware and I still have the same problem. Kernel 4.15 works fine for everybody.

Hello Victor P

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.

Also can you please collect trace-cmd logs too.
https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging#tracing



Hello mikezackles,
Thanks for the information. Please try old firmware.
If you are still facing the issue. Please share FW logs.(In reply to Victor P from comment #221)
> I have had this problem on the 7260 ever since upgrading Ubuntu from 18.04
> LTS (4.15 kernel / 17.948900127.0 7260-17.ucode) to 20.04 LTS (5.4 kernel /
> 17.3216344376.0 7260-17.ucode). It manifests as reported above, frequent
> disconnects, with numerous "No beacon heard and the time event is over
> already..." and CTRL-EVENT-BEACON-LOSS trace from wpa_supplicant. 
> 
> After downgrading the kernel to 4.15 (keeping FW at version
> 17.3216344376.0), I no longer have the problem with disconnects. Of note,
> CTRL-EVENT-BEACON-LOSS traces persist, even though there are no disconnects.
> Seems like a spurious beacon loss reported by the FW. I have not tried
> downgrading the FW since seeing the bug, but I have never had a single
> CTRL-EVENT-BEACON-LOSS while running the 17.948900127.0 FW. Other devices on
> the same AP do not have disconnect issues.
> 
> My bet is this is a FW bug, likely dating back to:
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
> commit/?id=58265e0def90e8f1b6c1987fbf70af983e84d514.
> 
> It did not start manifesting in disconnects until the patch mentioned in
> earlier comments, to disconnect in case of large beacon loss, which landed
> in the 5.1 kernel.
> (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/
> drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.
> c?id=babea2d4fe76c6515da6231e8d940044bad686b1).
> 
> If it helps, I will collect FW debug logs.

Created attachment 295757 [details]
7260 system logs, trace and fw core dump

Attached iwlwifi_debug_vp.7z containing the logs and trace on the 7260. The FW did not automatically create any dumps, so I manually obtained a few while the problem was happening. Hope this helps.

Hello Victor P,
          Thanks for sharing logs. We will look into it.

Thanks,
Abhishek Naik.

On the core

# uname -r
5.4.98-std-def-alt1

with an adapter

# lspci -nn | grep Netw
03:00.0 Network controller [0280]: Intel Corporation Wireless 3160 [8086:08b4] (rev 93)

the beacon was lost 44 times,

# iw wlan0 station dump | grep 'beacon\|signal\|failed'
	tx failed:	1
	beacon loss:	44
	beacon rx:	43010
	signal:  	-46 [-46] dBm
	signal avg:	-46 [-46] dBm
	beacon signal avg:	-39 dBm
	beacon interval:100

but not all 44 times the connection is lost

# dmesg | grep 'lost\|No beacon heard'
[23758.984770] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[23763.142388] iwlwifi 0000:03:00.0: No beacon heard and the time event is over already...
[23763.142404] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[24029.315008] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[24041.503706] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[24052.879331] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[24056.478335] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[24060.625166] iwlwifi 0000:03:00.0: No beacon heard and the time event is over already...
[24060.625209] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[24064.260956] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[24067.845555] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[24185.386849] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[24354.445211] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[24558.333156] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[24561.932078] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[24565.515109] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[24569.100665] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[24575.224355] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[24582.821172] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[32587.612876] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost


When booting the same system without updates with a major kernel version lower than kernel 5.4.98,

# uname -r
4.19.102-std-def-alt1

for 13 hours of the test,

# LC_ALL=C date
Tue Mar  9 05:58:54 +03 2021

# LC_ALL=C date
Tue Mar  9 19:03:11 +03 2021

with the same adapter, on the same system,

# lspci -nn | grep Netw
03:00.0 Network controller [0280]: Intel Corporation Wireless 3160 [8086:08b4] (rev 93)

there was no loss of the beacon and no loss of the connection

# iw wlan0 station dump | grep 'beacon\|signal\|failed'
	tx failed:	0
	beacon loss:	0
	beacon rx:	452364
	signal:  	-42 [-42] dBm
	signal avg:	-42 [-42] dBm
	beacon signal avg:	-39 dBm
	beacon interval:100

# dmesg | grep 'lost\|No beacon heard'
# _


If the problem is in the Intel firmware, then why is it that with the same firmware in the system without updates, when changing the kernel with a downgrade of the kernel version from version 5.{4.10} to kernel 4.19, the problem with the loss of beacons and the loss of the connection is not reproduced?

(In reply to Yury Pakin from comment #226)
 
> If the problem is in the Intel firmware, then why is it that with the same
> firmware in the system without updates, when changing the kernel with a
> downgrade of the kernel version from version 5.{4.10} to kernel 4.19, the
> problem with the loss of beacons and the loss of the connection is not
> reproduced?

What firmware version are you running? (ethtool -i wlan0)

Could you check the system journal (not just dmesg) for CTRL-EVENT-BEACON-LOSS reported by wpa_supplicant even when running on 4.19? I still see CTRL-EVENT-BEACON-LOSS on 4.15, when running with the latest 7260 firmware (17.3216344376.0). No disconnects on 4.15, the trace there is "harmless".

My hunch is that some change related to reporting beacon loss was introduced in the FW at some point. The iwlwifi driver in kernels before around 5.1 does not disconnect when a huge beacon loss is reported, whereas in newer kernels it does.

(In reply to Victor P from comment #227)
> (In reply to Yury Pakin from comment #226)
>  
> > If the problem is in the Intel firmware, then why is it that with the same
> > firmware in the system without updates, when changing the kernel with a
> > downgrade of the kernel version from version 5.{4.10} to kernel 4.19, the
> > problem with the loss of beacons and the loss of the connection is not
> > reproduced?
> 
> What firmware version are you running? (ethtool -i wlan0)
> 

# ethtool -i wlan0
driver: iwlwifi
version: 5.4.98-std-def-alt1
firmware-version: 17.3216344376.0
expansion-rom-version: 
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no


> Could you check the system journal (not just dmesg) for
> CTRL-EVENT-BEACON-LOSS reported by wpa_supplicant even when running on 4.19?

My logs do not contain this message, neither on kernel 5.4.98 nor on kernel 4.19.102 (rsyslog logging):

# grep -ri CTRL-EVENT-BEACON-LOSS /var/log
#_


> I still see CTRL-EVENT-BEACON-LOSS on 4.15, when running with the latest
> 7260 firmware (17.3216344376.0). No disconnects on 4.15, the trace there is
> "harmless".
> 
> My hunch is that some change related to reporting beacon loss was introduced
> in the FW at some point. The iwlwifi driver in kernels before around 5.1
> does not disconnect when a huge beacon loss is reported, whereas in newer
> kernels it does.

On the core 5.4 and higher, the loss of beacons and connection, I have random and in time and intensity. The command can display lost beacons even when there is no connection loss yet and nothing goes to the log:

# iw wlan0 station dump | grep 'beacon\|signal\|failed'
	tx failed:	2
	beacon loss:	9
	beacon rx:	65423
	signal:  	-46 [-46] dBm
	signal avg:	-46 [-46] dBm
	beacon signal avg:	-40 dBm
	beacon interval:100

But it's worth going back to kernel 4.19 (or any 4.X) and with the same firmware 3160 (17.3216344376.0) the connection is exceptionally stable and there is no loss of any beacon.

with the latest update from Fedora 33 
  
  kernel version: 5.10.21-200.fc33.x86_64
  iwwifi firmware-version: 36.ad812ee0.0 8265-36.ucode

I have now:

        tx failed:	167
	beacon loss:	0
	beacon rx:	37551
	signal:  	-63 [-63, -93] dBm
	signal avg:	-63 [-63, -91] dBm
	beacon signal avg:	-74 dBm
	beacon interval:100

Test week passed:
Forced beacon interval:50
There were no disconnections from the access point

# uname -r
5.4.98-std-def-alt1

# uptime 
 16:09:15 up 7 days, 20:08,  4 users,  load average: 0,57, 0,61, 0,66

# grep -H . /etc/modprobe.d/iwlwifi.conf*
/etc/modprobe.d/iwlwifi.conf.bak:options iwlmvm power_scheme=1
/etc/modprobe.d/iwlwifi.conf.bak:options iwlwifi power_save=0


Despite the fact that iw shows 23 lost access point beacons,

# iw wlan0 station dump | grep 'beacon\|signal\|failed'
	tx failed:	0
	beacon loss:	23
	beacon rx:	178981
	signal:  	-49 [-49] dBm
	signal avg:	-47 [-47] dBm
	beacon signal avg:	-43 dBm
	beacon interval:50

# dmesg | grep 'lost\|No beacon heard' 
[160392.189974] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[351269.779722] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost

iwconfig says there were no beacon losses

# iwconfig wlan0 | grep 'Management\|Signal\|beacon'
          Power Management:off
          Link Quality=60/70  Signal level=-50 dBm  
          Tx excessive retries:0  Invalid misc:15   Missed beacon:0

But the same iwconfig says about fifteen other lost packets

# man iwconfig | grep -A1 'Invalid misc'
       Invalid misc
              Other packets lost in relation with specific wireless operations.


It probably makes sense to return the Beacon Interval to 100 and drive for another week with a lock of 11n

# modinfo iwlwifi | grep '11n\|power_save'
parm:           11n_disable:disable 11n functionality, bitmap: 1: full, 2: disable agg TX, 4: disable agg RX, 8 enable agg TX (uint)
parm:           power_save:enable WiFi power management (default: disable) (bool)

https://bbs.archlinux.org/viewtopic.php?pid=1060792#p1060792

#/etc/modprobe.d/iwlwifi.conf
options iwlwifi 11n_disable=1 swcrypto=1

(In reply to Abhishek Naik from comment #225)
> Hello Victor P,
>           Thanks for sharing logs. We will look into it.
> 
> Thanks,
> Abhishek Naik.

Anything new on that topic?
I am on Fedora 33 with Kernel 5.11 and my 7260 is also affected.

I downgraded my kernel to 4.19.0-16-amd64 around 2 weeks ago. No more disconnects since then.

This has started happening to me just recently, with 5.10 series kernel and linux-firmware-20210315 (17.3216344376.0 3160-17.ucode) on an intel 3160 r83 card.

Hello, 
I have this same issue on the card listed below. But I have noticed something odd about the problem. If I connect into a network using standard wireless G 2.4ghz then its fine. If I connect in using 5gz then I get this random disconnection problem. The problem is vastly worse with the new wireless 6 systems however. My work has these wireless routers and its almost impossible to stay connected to them. Its always reason 4 when it disconnects. 

Network controller: Intel Corporation Wireless 8260 (rev 3a)


I hope this is helpful to someone. 

I am running on a Gentoo install using kernel 5.10.27 kernel.

(In reply to Sai Sindhur Malleni from comment #96)
> 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
> 


Returned 100 ms at the access point for the Beacon Interval.
Set 11n_disable to active with the iwlwifi module reload:

# lsmod | grep -o -e ^iwlmvm -e ^iwldvm -e ^iwlwifi | \
#xargs rmmod && sleep 3 && modprobe iwlwifi 11n_disable=1


Start of the test:

# sh test-beacon-loss.sh

# lspci -knn | grep Net
03:00.0 Network controller [0280]: Intel Corporation Wireless 3160 [8086:08b4] (rev 93)

# ethtool -i wlan0 | grep 'driver\|^version\|firmware\|bus'
driver: iwlwifi
version: 5.4.111-std-def-alt1
firmware-version: 17.3216344376.0
bus-info: 0000:03:00.0

# iw dev wlan0 info | grep 'Interface\|type\|channel\|txpower'
Interface wlan0
	type managed
	channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz
	txpower 20.00 dBm

# iw wlan0 station dump | grep 'beacon\|signal\|failed\|bitrate\|connected'
	tx failed:	0
	beacon loss:	0
	beacon rx:	10608
	signal:  	-49 [-49] dBm
	signal avg:	-49 [-49] dBm
	beacon signal avg:	-44 dBm
	tx bitrate:	54.0 MBit/s
	rx bitrate:	54.0 MBit/s
	beacon interval:100
	connected time:	1113 seconds

# iwconfig wlan0
wlan0     IEEE 802.11  ESSID:"AP0"  
          Mode:Managed  Frequency:2.412 GHz  Access Point: XX:XX:XX:XX:XX:XX   
          Bit Rate=54 Mb/s   Tx-Power=20 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:on
          Link Quality=61/70  Signal level=-49 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:5   Missed beacon:0


# cat /etc/modprobe.d/iwlwifi.conf
options iwlwifi 11n_disable=1 swcrypto=1


After 2 hours and 49 minutes from the start of the test, the rx bitrate dropped to 1 MBit/s:

# sh test-beacon-loss.sh

# lspci -knn | grep Net
03:00.0 Network controller [0280]: Intel Corporation Wireless 3160 [8086:08b4] (rev 93)

# ethtool -i wlan0 | grep 'driver\|^version\|firmware\|bus'
driver: iwlwifi
version: 5.4.111-std-def-alt1
firmware-version: 17.3216344376.0
bus-info: 0000:03:00.0

# cat /etc/modprobe.d/iwlwifi.conf
options iwlwifi 11n_disable=1 swcrypto=1

# iw dev wlan0 info | grep 'Interface\|type\|channel\|txpower'
Interface wlan0
	type managed
	channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz
	txpower 20.00 dBm

# iw wlan0 station dump | grep 'beacon\|signal\|failed\|bitrate\|connected'
	tx failed:	3
	beacon loss:	0
	beacon rx:	98439
	signal:  	-46 [-46] dBm
	signal avg:	-46 [-46] dBm
	beacon signal avg:	-45 dBm
	tx bitrate:	54.0 MBit/s
	rx bitrate:	1.0 MBit/s
	beacon interval:100
	connected time:	10150 seconds

# iwconfig wlan0 | grep -v 'Retry\|Encryption'
wlan0     IEEE 802.11  ESSID:"AP0"  
          Mode:Managed  Frequency:2.412 GHz  Access Point: XX:XX:XX:XX:XX:XX   
          Bit Rate=54 Mb/s   Tx-Power=20 dBm   
          Power Management:on
          Link Quality=64/70  Signal level=-46 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:3  Invalid misc:62   Missed beacon:0


And in dmesg:

# dmesg | grep -A1000 '561122.366868' 
[561122.366868] wlan0: deauthenticating from xx:xx:xx:xx:xx:xx by local choice (Reason: 3=DEAUTH_LEAVING)
[561125.460397] Intel(R) Wireless WiFi driver for Linux
[561125.460398] Copyright(c) 2003- 2015 Intel Corporation
[561125.462129] iwlwifi 0000:03:00.0: loaded firmware version 17.3216344376.0 op_mode iwlmvm
[561125.471405] iwlwifi 0000:03:00.0: Detected Intel(R) Dual Band Wireless AC 3160, REV=0x164
[561125.496122] iwlwifi 0000:03:00.0: base HW address: zz:zz:zz:zz:zz:zz
[561125.606517] ieee80211 phy3: Selected rate control algorithm 'iwl-mvm-rs'
[561131.433852] wlan0: authenticate with xx:xx:xx:xx:xx:xx
[561131.438828] wlan0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
[561131.441713] wlan0: authenticated
[561131.442364] wlan0: associate with xx:xx:xx:xx:xx:xx (try 1/3)
[561131.446169] wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x411 status=0 aid=2)
[561131.459617] wlan0: associated
[561131.481369] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[563756.334465] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[563759.881280] wlan0: authenticate with xx:xx:xx:xx:xx:xx
[563759.886050] wlan0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
[563759.889178] wlan0: authenticated
[563759.890137] wlan0: associate with xx:xx:xx:xx:xx:xx (try 1/3)
[563759.893824] wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x411 status=0 aid=2)
[563759.906462] wlan0: associated
[563760.500179] iwlwifi 0000:03:00.0: No beacon heard and the time event is over already...
[563760.500230] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[563764.033418] wlan0: authenticate with xx:xx:xx:xx:xx:xx
[563764.038493] wlan0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
[563764.041530] wlan0: authenticated
[563764.042166] wlan0: associate with xx:xx:xx:xx:xx:xx (try 1/3)
[563764.046286] wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x411 status=0 aid=2)
[563764.057577] wlan0: associated
[563786.330867] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[563789.865888] wlan0: authenticate with xx:xx:xx:xx:xx:xx
[563789.871459] wlan0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
[563789.874912] wlan0: authenticated
[563789.875310] wlan0: associate with xx:xx:xx:xx:xx:xx (try 1/3)
[563789.880372] wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x411 status=0 aid=2)
[563789.881097] wlan0: associated
[563815.317608] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[563827.259950] wlan0: authenticate with xx:xx:xx:xx:xx:xx
[563827.265818] wlan0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
[563827.268722] wlan0: authenticated
[563827.269533] wlan0: associate with xx:xx:xx:xx:xx:xx (try 1/3)
[563827.273344] wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x411 status=0 aid=2)
[563827.284320] wlan0: associated
[563827.879816] iwlwifi 0000:03:00.0: No beacon heard and the time event is over already...
[563827.879867] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[563831.410640] wlan0: authenticate with xx:xx:xx:xx:xx:xx
[563831.416500] wlan0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
[563831.419741] wlan0: authenticated
[563831.420563] wlan0: associate with xx:xx:xx:xx:xx:xx (try 1/3)
[563831.424928] wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x411 status=0 aid=2)
[563831.445276] wlan0: associated
[563938.411108] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[563941.944973] wlan0: authenticate with xx:xx:xx:xx:xx:xx
[563941.949913] wlan0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
[563941.952748] wlan0: authenticated
[563941.953233] wlan0: associate with xx:xx:xx:xx:xx:xx (try 1/3)
[563941.956896] wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x411 status=0 aid=2)
[563941.959181] wlan0: associated
[563945.161711] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[563948.698314] wlan0: authenticate with xx:xx:xx:xx:xx:xx
[563948.703342] wlan0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
[563948.707781] wlan0: authenticated
[563948.708264] wlan0: associate with xx:xx:xx:xx:xx:xx (try 1/3)
[563948.711856] wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x411 status=0 aid=2)
[563948.722906] wlan0: associated
[563949.317177] iwlwifi 0000:03:00.0: No beacon heard and the time event is over already...
[563949.317203] wlan0: Connection to AP xx:xx:xx:xx:xx:xx lost
[563952.847377] wlan0: authenticate with xx:xx:xx:xx:xx:xx
[563952.853077] wlan0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
[563952.855840] wlan0: authenticated
[563952.856283] wlan0: associate with xx:xx:xx:xx:xx:xx (try 1/3)
[563952.859953] wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x411 status=0 aid=2)
[563952.871994] wlan0: associated
[564388.957148] wlan0: deauthenticating from xx:xx:xx:xx:xx:xx by local choice (Reason: 3=DEAUTH_LEAVING)
[564392.056491] Intel(R) Wireless WiFi driver for Linux
[564392.056492] Copyright(c) 2003- 2015 Intel Corporation
[564392.058336] iwlwifi 0000:03:00.0: loaded firmware version 17.3216344376.0 op_mode iwlmvm
[564392.067695] iwlwifi 0000:03:00.0: Detected Intel(R) Dual Band Wireless AC 3160, REV=0x164
[564392.090556] iwlwifi 0000:03:00.0: base HW address: zz:zz:zz:zz:zz:zz
[564392.203001] ieee80211 phy4: Selected rate control algorithm 'iwl-mvm-rs'
[564398.025794] wlan0: authenticate with xx:xx:xx:xx:xx:xx
[564398.032179] wlan0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
[564398.040025] wlan0: authenticated
[564398.040929] wlan0: associate with xx:xx:xx:xx:xx:xx (try 1/3)
[564398.044861] wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x411 status=0 aid=2)
[564398.046605] wlan0: associated
[564398.079560] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready


At the same time, there was no network loss:

# sh test-beacon-loss.sh

# lspci -knn | grep Net
03:00.0 Network controller [0280]: Intel Corporation Wireless 3160 [8086:08b4] (rev 93)

# ethtool -i wlan0 | grep 'driver\|^version\|firmware\|bus'
driver: iwlwifi
version: 5.4.111-std-def-alt1
firmware-version: 17.3216344376.0
bus-info: 0000:03:00.0

# cat /etc/modprobe.d/iwlwifi.conf
options iwlwifi 11n_disable=1 swcrypto=1

# iw dev wlan0 info | grep 'Interface\|type\|channel\|txpower'
Interface wlan0
	type managed
	channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz
	txpower 20.00 dBm

# iw wlan0 station dump | grep 'beacon\|signal\|failed\|bitrate\|connected'
	tx failed:	3
	beacon loss:	0
	beacon rx:	103574
	signal:  	-52 [-52] dBm
	signal avg:	-49 [-49] dBm
	beacon signal avg:	-46 dBm
	tx bitrate:	54.0 MBit/s
	rx bitrate:	54.0 MBit/s
	beacon interval:100
	connected time:	10689 seconds

# iwconfig wlan0 | grep -v 'Retry\|Encryption'
wlan0     IEEE 802.11  ESSID:"AP0"  
          Mode:Managed  Frequency:2.412 GHz  Access Point: XX:XX:XX:XX:XX:XX   
          Bit Rate=54 Mb/s   Tx-Power=20 dBm   
          Power Management:on
          Link Quality=58/70  Signal level=-52 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:3  Invalid misc:62   Missed beacon:0

This bug's status is currently showing as "NEEDINFO". Is this correct (or should it say "IN_PROGRESS")? If it is correct, what INFO do you NEED?

Comment 190: 

> 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.

Comment 193:

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

I can confirm both observations. 

In my case, AP signal is weak (and there is nothing I can do about it) and there is also a Bluetooth keyboard and mouse added to the mix (see Comment 214). For a first few hours after boot (or reconnect, as it seems) I getting just a few megabits per second (iperf3). However, by the next morning, I always get around 0-1 megabits per second and have to reboot/reconnect. So from my point of view, a weak signal does trigger bug with higher probability, and performance does degrade over time (at least with older kernel and firmware).

After upgrade from Linux 5.8 to 5.12 (and also updating the firmware package) I still getting disconnects due to beacon loss (probably due to weak signal) but then connection is re-established so speed degradation does not happen.

driver: iwlwifi
version: 5.12.4-051204-generic
firmware-version: 29.4063824552.0 7265D-29.ucode
expansion-rom-version: 
bus-info: 0000:01:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

I will try to decrease beacon_int on AP from 100 to 50 and see how it goes in the next few days.

Hi,

I'm also having the same problem using Intel 8260, rev 3a.
It seems that the problem is only happening on 5GHz, and it's worse when trying to connect to Wi-Fi 6 AP.

On dmesg I can see the following errors:
...
iwlwifi 0000:01:00.0: No beacon heard and the time event is over already...
...
wlan0: authenticate with 7x:xx:xx:xx:xx:xc
[Tue May 18 23:16:38 2021] wlan0: send auth to 7x:xx:xx:xx:xx:xc (try 1/3)
[Tue May 18 23:16:38 2021] wlan0: send auth to 7x:xx:xx:xx:xx:xc (try 2/3)
[Tue May 18 23:16:38 2021] wlan0: send auth to 7x:xx:xx:xx:xx:xc (try 3/3)
[Tue May 18 23:16:38 2021] wlan0: authentication with 7x:xx:xx:xx:xx:xc timed out
...

Information from the system:

cat /proc/version
Linux version 5.10.18- (gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP PREEMPT Wed Feb 24 13:53:52 WET 2021

lshw -c network
  *-network
       description: Wireless interface
       product: Wireless 8260
       vendor: Intel Corporation
       physical id: 0
       bus info: pci@0000:01:00.0
       logical name: wlan0
       version: 3a
       serial: b8:xx:xx:xx:dd:ad
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
       configuration: broadcast=yes driver=iwlwifi driverversion=5.10.18 firmware=36.ad812ee0.0 8000C-36.ucode latency=0 link=no multicast=yes wireless=IEEE 802.11
       resources: irq:137 memory:c1200000-c1201fff

lspci -knn | grep Net
01:00.0 Network controller [0280]: Intel Corporation Wireless 8260 [8086:24f3] (rev 3a)

ethtool -i wlan0 | grep 'driver\|^version\|firmware\|bus'
driver: iwlwifi
version: 5.10.18-catf
firmware-version: 36.ad812ee0.0 8000C-36.ucode
bus-info: 0000:01:00.0

lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 9.13 (stretch)
Release:        9.13
Codename:       stretch

I can replicate this easily. How can I help with this?
Thanks.

(In reply to oleal from comment #238)
> Hi,
> 
> I'm also having the same problem using Intel 8260, rev 3a.
> It seems that the problem is only happening on 5GHz, and it's worse when
> trying to connect to Wi-Fi 6 AP.
> 
> On dmesg I can see the following errors:
> ...
> iwlwifi 0000:01:00.0: No beacon heard and the time event is over already...
> ...
> wlan0: authenticate with 7x:xx:xx:xx:xx:xc
> [Tue May 18 23:16:38 2021] wlan0: send auth to 7x:xx:xx:xx:xx:xc (try 1/3)
> [Tue May 18 23:16:38 2021] wlan0: send auth to 7x:xx:xx:xx:xx:xc (try 2/3)
> [Tue May 18 23:16:38 2021] wlan0: send auth to 7x:xx:xx:xx:xx:xc (try 3/3)
> [Tue May 18 23:16:38 2021] wlan0: authentication with 7x:xx:xx:xx:xx:xc
> timed out
> ...
> 
> Information from the system:
> 
> cat /proc/version
> Linux version 5.10.18- (gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU
> Binutils for Debian) 2.35.1) #1 SMP PREEMPT Wed Feb 24 13:53:52 WET 2021
> 
> lshw -c network
>   *-network
>        description: Wireless interface
>        product: Wireless 8260
>        vendor: Intel Corporation
>        physical id: 0
>        bus info: pci@0000:01:00.0
>        logical name: wlan0
>        version: 3a
>        serial: b8:xx:xx:xx:dd:ad
>        width: 64 bits
>        clock: 33MHz
>        capabilities: pm msi pciexpress bus_master cap_list ethernet physical
> wireless
>        configuration: broadcast=yes driver=iwlwifi driverversion=5.10.18
> firmware=36.ad812ee0.0 8000C-36.ucode latency=0 link=no multicast=yes
> wireless=IEEE 802.11
>        resources: irq:137 memory:c1200000-c1201fff
> 
> lspci -knn | grep Net
> 01:00.0 Network controller [0280]: Intel Corporation Wireless 8260
> [8086:24f3] (rev 3a)
> 
> ethtool -i wlan0 | grep 'driver\|^version\|firmware\|bus'
> driver: iwlwifi
> version: 5.10.18-catf
> firmware-version: 36.ad812ee0.0 8000C-36.ucode
> bus-info: 0000:01:00.0
> 
> lsb_release -a
> No LSB modules are available.
> Distributor ID: Debian
> Description:    Debian GNU/Linux 9.13 (stretch)
> Release:        9.13
> Codename:       stretch
> 
> I can replicate this easily. How can I help with this?
> Thanks.

Holy cow, limiting the frequency to the 2.4 ghz range seems to have made my problems go away completely. Thank you for that, oleal.

I could not stay connected to save my life until trying that (I've also got power save turned off, but I've been doing that for months with no luck).

I wonder if I limit it to just the 5Ghz band, if it comes back or not. I will experiment over the next few days and report back

(In reply to Decent Mix from comment #239)
> (In reply to oleal from comment #238)
> > Hi,
> > 
> > I'm also having the same problem using Intel 8260, rev 3a.
> > It seems that the problem is only happening on 5GHz, and it's worse when
> > trying to connect to Wi-Fi 6 AP.
> > 
> > On dmesg I can see the following errors:
> > ...
> > iwlwifi 0000:01:00.0: No beacon heard and the time event is over already...
> > ...
> > wlan0: authenticate with 7x:xx:xx:xx:xx:xc
> > [Tue May 18 23:16:38 2021] wlan0: send auth to 7x:xx:xx:xx:xx:xc (try 1/3)
> > [Tue May 18 23:16:38 2021] wlan0: send auth to 7x:xx:xx:xx:xx:xc (try 2/3)
> > [Tue May 18 23:16:38 2021] wlan0: send auth to 7x:xx:xx:xx:xx:xc (try 3/3)
> > [Tue May 18 23:16:38 2021] wlan0: authentication with 7x:xx:xx:xx:xx:xc
> > timed out
> > ...
> > 
> > Information from the system:
> > 
> > cat /proc/version
> > Linux version 5.10.18- (gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU
> > Binutils for Debian) 2.35.1) #1 SMP PREEMPT Wed Feb 24 13:53:52 WET 2021
> > 
> > lshw -c network
> >   *-network
> >        description: Wireless interface
> >        product: Wireless 8260
> >        vendor: Intel Corporation
> >        physical id: 0
> >        bus info: pci@0000:01:00.0
> >        logical name: wlan0
> >        version: 3a
> >        serial: b8:xx:xx:xx:dd:ad
> >        width: 64 bits
> >        clock: 33MHz
> >        capabilities: pm msi pciexpress bus_master cap_list ethernet
> physical
> > wireless
> >        configuration: broadcast=yes driver=iwlwifi driverversion=5.10.18
> > firmware=36.ad812ee0.0 8000C-36.ucode latency=0 link=no multicast=yes
> > wireless=IEEE 802.11
> >        resources: irq:137 memory:c1200000-c1201fff
> > 
> > lspci -knn | grep Net
> > 01:00.0 Network controller [0280]: Intel Corporation Wireless 8260
> > [8086:24f3] (rev 3a)
> > 
> > ethtool -i wlan0 | grep 'driver\|^version\|firmware\|bus'
> > driver: iwlwifi
> > version: 5.10.18-catf
> > firmware-version: 36.ad812ee0.0 8000C-36.ucode
> > bus-info: 0000:01:00.0
> > 
> > lsb_release -a
> > No LSB modules are available.
> > Distributor ID: Debian
> > Description:    Debian GNU/Linux 9.13 (stretch)
> > Release:        9.13
> > Codename:       stretch
> > 
> > I can replicate this easily. How can I help with this?
> > Thanks.
> 
> Holy cow, limiting the frequency to the 2.4 ghz range seems to have made my
> problems go away completely. Thank you for that, oleal.
> 
> I could not stay connected to save my life until trying that (I've also got
> power save turned off, but I've been doing that for months with no luck).
> 
> I wonder if I limit it to just the 5Ghz band, if it comes back or not. I
> will experiment over the next few days and report back

Glad that I'm able to help :)
Unfortunately, no one from intel is answering to these issues. This is a critical issue and will become even worst when people start having Wi-Fi 6 in their homes.

On Fri, May 21, 2021 at 07:57:15PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
Yes that was my experiance too with my card as well. Limiting it to
2.4ghz was the way I was able to fix the problem as well. My wifi at
work however uses the newer standard and it was the only way I could get
it to stay connected. 

> https://bugzilla.kernel.org/show_bug.cgi?id=203709
> 
> --- Comment #240 from oleal (oscarleal.network@gmail.com) ---
> (In reply to Decent Mix from comment #239)
> > (In reply to oleal from comment #238)
> > > Hi,
> > > 
> > > I'm also having the same problem using Intel 8260, rev 3a.
> > > It seems that the problem is only happening on 5GHz, and it's worse when
> > > trying to connect to Wi-Fi 6 AP.
> > > 
> > > On dmesg I can see the following errors:
> > > ...
> > > iwlwifi 0000:01:00.0: No beacon heard and the time event is over
> already...
> > > ...
> > > wlan0: authenticate with 7x:xx:xx:xx:xx:xc
> > > [Tue May 18 23:16:38 2021] wlan0: send auth to 7x:xx:xx:xx:xx:xc (try
> 1/3)
> > > [Tue May 18 23:16:38 2021] wlan0: send auth to 7x:xx:xx:xx:xx:xc (try
> 2/3)
> > > [Tue May 18 23:16:38 2021] wlan0: send auth to 7x:xx:xx:xx:xx:xc (try
> 3/3)
> > > [Tue May 18 23:16:38 2021] wlan0: authentication with 7x:xx:xx:xx:xx:xc
> > > timed out
> > > ...
> > > 
> > > Information from the system:
> > > 
> > > cat /proc/version
> > > Linux version 5.10.18- (gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld
> (GNU
> > > Binutils for Debian) 2.35.1) #1 SMP PREEMPT Wed Feb 24 13:53:52 WET 2021
> > > 
> > > lshw -c network
> > >   *-network
> > >        description: Wireless interface
> > >        product: Wireless 8260
> > >        vendor: Intel Corporation
> > >        physical id: 0
> > >        bus info: pci@0000:01:00.0
> > >        logical name: wlan0
> > >        version: 3a
> > >        serial: b8:xx:xx:xx:dd:ad
> > >        width: 64 bits
> > >        clock: 33MHz
> > >        capabilities: pm msi pciexpress bus_master cap_list ethernet
> > physical
> > > wireless
> > >        configuration: broadcast=yes driver=iwlwifi driverversion=5.10.18
> > > firmware=36.ad812ee0.0 8000C-36.ucode latency=0 link=no multicast=yes
> > > wireless=IEEE 802.11
> > >        resources: irq:137 memory:c1200000-c1201fff
> > > 
> > > lspci -knn | grep Net
> > > 01:00.0 Network controller [0280]: Intel Corporation Wireless 8260
> > > [8086:24f3] (rev 3a)
> > > 
> > > ethtool -i wlan0 | grep 'driver\|^version\|firmware\|bus'
> > > driver: iwlwifi
> > > version: 5.10.18-catf
> > > firmware-version: 36.ad812ee0.0 8000C-36.ucode
> > > bus-info: 0000:01:00.0
> > > 
> > > lsb_release -a
> > > No LSB modules are available.
> > > Distributor ID: Debian
> > > Description:    Debian GNU/Linux 9.13 (stretch)
> > > Release:        9.13
> > > Codename:       stretch
> > > 
> > > I can replicate this easily. How can I help with this?
> > > Thanks.
> > 
> > Holy cow, limiting the frequency to the 2.4 ghz range seems to have made my
> > problems go away completely. Thank you for that, oleal.
> > 
> > I could not stay connected to save my life until trying that (I've also got
> > power save turned off, but I've been doing that for months with no luck).
> > 
> > I wonder if I limit it to just the 5Ghz band, if it comes back or not. I
> > will experiment over the next few days and report back
> 
> Glad that I'm able to help :)
> Unfortunately, no one from intel is answering to these issues. This is a
> critical issue and will become even worst when people start having Wi-Fi 6 in
> their homes.
> 
> -- 
> You may reply to this email to add a comment.
> 
> You are receiving this mail because:
> You are on the CC list for the bug.

Hello All,
     Please provide FW dump from 9260 or 9560 for further analysis.

Please follow the procedures to collect the trace-cmd and FWdump.
 
https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging 

Thanks

After enabling all the required debugging options from that link (same kernel version and no other changes), the issue hasn't occurred - seems like we have a heisenbug?

I'll report back if the aberrant behaviour pops up again.

PS: /sys/kernel/debug/iwlwifi doesn't exist even after following those instructions, are they outdated for 5.10-series kernels or am I missing something?

Created attachment 297003 [details]
iwl-fw-error_2021-05-27_16-14-36.dump

I got a firmware crash (dump attached), after which it started dropping the WiFi connection a lot - tracing now

I have posted a zstd-compressed trace at https://triffid-hunter.no-ip.info/2021-05-27T172251trace.dat.zst (23MB, 375MB uncompressed) since it's too large to attach here.

It corresponds to the following dmesg events:

[13663.985250] wlp4s0: Connection to AP 4c:77:6d:96:ae:4e lost
[13667.533496] wlp4s0: authenticate with 4c:77:6d:96:ae:4e
[13667.535518] wlp4s0: send auth to 4c:77:6d:96:ae:4e (try 1/3)
[13667.536852] wlp4s0: authenticated
[13667.537349] wlp4s0: associate with 4c:77:6d:96:ae:4e (try 1/3)
[13667.538890] wlp4s0: RX AssocResp from 4c:77:6d:96:ae:4e (capab=0x411 status=0 aid=189)
[13667.539815] wlp4s0: associated
[13667.676923] wlp4s0: Limiting TX power to 23 (23 - 0) dBm as advertised by 4c:77:6d:96:ae:4e
[14136.974041] wlp4s0: Connection to AP 4c:77:6d:96:ae:4e lost
[14140.621631] wlp4s0: authenticate with 4c:77:6d:96:ae:4e
[14140.622545] wlp4s0: send auth to 4c:77:6d:96:ae:4e (try 1/3)
[14140.625115] wlp4s0: authenticated
[14140.626017] wlp4s0: associate with 4c:77:6d:96:ae:4e (try 1/3)
[14140.630738] wlp4s0: RX AssocResp from 4c:77:6d:96:ae:4e (capab=0x411 status=0 aid=15)
[14140.632519] wlp4s0: associated
[14140.662973] wlp4s0: Limiting TX power to 23 (23 - 0) dBm as advertised by 4c:77:6d:96:ae:4e
[14229.023360] wlp4s0: Connection to AP 4c:77:6d:96:ae:4e lost
[14229.646871] wlp4s0: authenticate with 4c:77:6d:05:7f:2e
[14229.650137] wlp4s0: send auth to 4c:77:6d:05:7f:2e (try 1/3)
[14229.650987] wlp4s0: authenticated
[14229.651352] wlp4s0: associate with 4c:77:6d:05:7f:2e (try 1/3)
[14229.652796] wlp4s0: RX AssocResp from 4c:77:6d:05:7f:2e (capab=0x411 status=0 aid=28)
[14229.656151] wlp4s0: associated
[14229.722667] wlp4s0: Limiting TX power to 21 (21 - 0) dBm as advertised by 4c:77:6d:05:7f:2e

Hello triffid.hunter

Thanks for the fw dump. But looks like for some reason fw dump is corrupted. We are not able to parse it.

I believe you have provided firmware dump for 3160.
We need fw dump for 9260 or 9560 for further analysis.

If you cant find /sys/kernel/debug/iwlwifi. It can be kernel configuration issue.
you need to have at least these three options enabled when they compile the kernel 
CPTCFG_IWLWIFI_DEBUG=y
CPTCFG_IWLWIFI_DEBUGFS=y
CPTCFG_IWLWIFI_DEVICE_TRACING=y

(In reply to Abhishek Naik from comment #246)
> I believe you have provided firmware dump for 3160.

Yeah, I have a 3160 chipset

> If you cant find /sys/kernel/debug/iwlwifi. It can be kernel configuration
> issue.
> you need to have at least these three options enabled when they compile the
> kernel 
> CPTCFG_IWLWIFI_DEBUG=y
> CPTCFG_IWLWIFI_DEBUGFS=y
> CPTCFG_IWLWIFI_DEVICE_TRACING=y

$ zgrep IWLWIFI_DE /proc/config.gz
CONFIG_IWLWIFI_DEBUG=y
CONFIG_IWLWIFI_DEVICE_TRACING=y

Seems I'm missing CONFIG_IWLWIFI_DEBUGFS, but that config option isn't mentioned in your https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging instructions - perhaps they need an update?

Hello sebalinux, Alexander Tsoy and testillox,
     From the logs you pasted here, I can see that you are using 9560 chipset. Can you please try to reproduce this issue and share following logs.
1. trace-cmd log
2. Fw-dump

Please refer to below link for collecting logs
https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging

Thanks
Abhishek Naik.

(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).

Your patch, with a timeout of 256 missed beacons, has fixed the problem for me. Thank you so much, this problem was driving me crazy.

Created attachment 297119 [details]
attachment-1050-0.html

Dear sender,

I am out of office until 7th of June 2021 and will answer your email after my return.
In urgent cases, please contact Mr. Gerd Brost (gerd.brost@aisec.fraunhofer.de), he will redirect you to the right person.

Best regards,
Mathias Morbitzer

(In reply to Lucas Correia Villa Real from comment #249)
> Your patch, with a timeout of 256 missed beacons, has fixed the problem for
> me. Thank you so much, this problem was driving me crazy.

Glad it was helpful! This is indeed an extremely frustrating issue.

As this thread is a mile long, I thought I'd reiterate:
Abhishek from Intel is looking for firmware dumps from 9260 and 9560. (Unfortunately I have 8265/8275 if I'm looking at the right number.)
https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging

Also, given the longevity (2 years!) and severity of the issue, is it possible that Intel might please devote some resources toward reproducing this internally? As users we don't have much recourse since the firmware is closed.

In case it is helpful for Arch users, I made a kernel package that includes the beacon timeout patch, and I also uploaded a binary package to github:
https://aur.archlinux.org/pkgbase/linux-beacon/
https://github.com/mikezackles/linux-beacon-pkgbuild/releases/tag/v5.12.9.arch1

(This is just to hopefully help people work around the issue until there is a firmware fix.)

(In reply to mikezackles from comment #172)
> Created attachment 294585 [details]
> Module parameter for beacon timeout

I've applied this patch locally (running Gentoo so just dropped it in /etc/portage/patches/ and tweaked /etc/modprobe.d/), and haven't had WiFi reconnects since.

I'm not sure if it's a workaround or an actual solution, but it definitely seems to help.

(In reply to mikezackles from comment #252)
> In case it is helpful for Arch users, I made a kernel package that includes
> the beacon timeout patch, and I also uploaded a binary package to github:
> https://aur.archlinux.org/pkgbase/linux-beacon/
> https://github.com/mikezackles/linux-beacon-pkgbuild/releases/tag/v5.12.9.
> arch1
> 
> (This is just to hopefully help people work around the issue until there is
> a firmware fix.)

Hello mikezackles, this issue is driving me crazy since almost a year ago I  install every new kernel released and any update hoping one would be the solution but the problem never goes away, I lost the count of working hours I have spent due to this issue.
I use Ubuntu 20.04.2 LTS with kernel 5.12.9-051209-generic can you guide me to a tutorial or give me some help about how to apply this patch to my system? I don't know if I have to compile the kernel, the driver or what.
Thanks for your effort, I don't undestand why Intel does not revert the changes that are causing so many headhaches to users.

> I lost the count of working hours I have spent due to this issue.

I completely understand :(

> I use Ubuntu 20.04.2 LTS with kernel 5.12.9-051209-generic can you guide me
> to a tutorial or give me some help about how to apply this patch to my
> system?

It's been a while since I've had to do this on Ubuntu. I think you can follow this guide to recompile your kernel:
https://help.ubuntu.com/community/Kernel/Compile

I'm pretty sure that once you get the sources on your system there will be a subdirectory named debian or something similar, and somewhere inside that you'll find a folder containing Ubuntu's kernel patches. You should be able to put the patch in that folder before compiling (which will take a while), and the build will apply it automatically.

Other people here may be able to point out if I'm missing or forgetting anything.

(In reply to mikezackles from comment #255)
> > I lost the count of working hours I have spent due to this issue.
> 
> I completely understand :(
> 
> > I use Ubuntu 20.04.2 LTS with kernel 5.12.9-051209-generic can you guide me
> > to a tutorial or give me some help about how to apply this patch to my
> > system?
> 
> It's been a while since I've had to do this on Ubuntu. I think you can
> follow this guide to recompile your kernel:
> https://help.ubuntu.com/community/Kernel/Compile
> 
> I'm pretty sure that once you get the sources on your system there will be a
> subdirectory named debian or something similar, and somewhere inside that
> you'll find a folder containing Ubuntu's kernel patches. You should be able
> to put the patch in that folder before compiling (which will take a while),
> and the build will apply it automatically.
> 
> Other people here may be able to point out if I'm missing or forgetting
> anything.

Thanks mikezackles, I compiled the kernel 5.13.0-rc6-custom with the patch and set beacon_timeout=256 few days ago, so far I got no problems, but problem normaly appeared after some weeks with laptop on, so lets see if this solution is definitive.

When I upgraded the kernel version to kernel-5.12.12-300.fc34.x86_64, I encountered the same problem.

But when I downgraded to 5.12.10-300.fc34.x86_64 kernel, the problem disappeared.



The logs pate here: https://paste.ubuntu.com/p/tVVZJG9zpM/

6月 30 10:44:11 moelove NetworkManager[871]: <info>  [1625021051.0711] device (p2p-dev-wlp0s20f3): supplicant management interface state: authenticating -> disconnected
6月 30 10:44:11 moelove NetworkManager[871]: <info>  [1625021051.0711] device (wlp0s20f3): supplicant interface state: authenticating -> disconnected
6月 30 10:44:11 moelove wpa_supplicant[1377]: wlp0s20f3: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="Krspace-Guest" auth_failures=2 duration=20 reason=CONN_FAILED
6月 30 10:44:11 moelove kernel: wlp0s20f3: authentication with 20:a6:cd:9c:15:e2 timed out
6月 30 10:44:10 moelove kernel: wlp0s20f3: Connection to AP 20:a6:cd:9c:15:e2 lost
6月 30 10:44:10 moelove kernel: iwlwifi 0000:00:14.3: No beacon heard and the session protection is over already...
6月 30 10:44:10 moelove kernel: wlp0s20f3: send auth to 20:a6:cd:9c:15:e2 (try 3/3)
6月 30 10:44:09 moelove kernel: wlp0s20f3: Connection to AP 20:a6:cd:9c:15:e2 lost
6月 30 10:44:09 moelove kernel: iwlwifi 0000:00:14.3: No beacon heard and the session protection is over already...
6月 30 10:44:09 moelove kernel: wlp0s20f3: send auth to 20:a6:cd:9c:15:e2 (try 2/3)
6月 30 10:44:08 moelove kernel: wlp0s20f3: Connection to AP 20:a6:cd:9c:15:e2 lost
6月 30 10:44:08 moelove kernel: iwlwifi 0000:00:14.3: No beacon heard and the session protection is over already...

(In reply to Jintao Zhang from comment #257)
> When I upgraded the kernel version to kernel-5.12.12-300.fc34.x86_64, I
> encountered the same problem.
> 
> But when I downgraded to 5.12.10-300.fc34.x86_64 kernel, the problem
> disappeared.
> 
> 
> 
> The logs pate here: https://paste.ubuntu.com/p/tVVZJG9zpM/
> 
> 6月 30 10:44:11 moelove NetworkManager[871]: <info>  [1625021051.0711] device
> (p2p-dev-wlp0s20f3): supplicant management interface state: authenticating
> -> disconnected
> 6月 30 10:44:11 moelove NetworkManager[871]: <info>  [1625021051.0711] device
> (wlp0s20f3): supplicant interface state: authenticating -> disconnected
> 6月 30 10:44:11 moelove wpa_supplicant[1377]: wlp0s20f3:
> CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="Krspace-Guest" auth_failures=2
> duration=20 reason=CONN_FAILED
> 6月 30 10:44:11 moelove kernel: wlp0s20f3: authentication with
> 20:a6:cd:9c:15:e2 timed out
> 6月 30 10:44:10 moelove kernel: wlp0s20f3: Connection to AP 20:a6:cd:9c:15:e2
> lost
> 6月 30 10:44:10 moelove kernel: iwlwifi 0000:00:14.3: No beacon heard and the
> session protection is over already...
> 6月 30 10:44:10 moelove kernel: wlp0s20f3: send auth to 20:a6:cd:9c:15:e2
> (try 3/3)
> 6月 30 10:44:09 moelove kernel: wlp0s20f3: Connection to AP 20:a6:cd:9c:15:e2
> lost
> 6月 30 10:44:09 moelove kernel: iwlwifi 0000:00:14.3: No beacon heard and the
> session protection is over already...
> 6月 30 10:44:09 moelove kernel: wlp0s20f3: send auth to 20:a6:cd:9c:15:e2
> (try 2/3)
> 6月 30 10:44:08 moelove kernel: wlp0s20f3: Connection to AP 20:a6:cd:9c:15:e2
> lost
> 6月 30 10:44:08 moelove kernel: iwlwifi 0000:00:14.3: No beacon heard and the
> session protection is over already...

Hello Zhang,
     What is your nic type? Is it 9260 and 9560? We need a firmware dump from 9260 or 9560 for further analysis.
Can you please share the firmware dump? Please follow the below link.

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

Thanks

As an update to my comment #253, I've had a few random WiFi drops since then - but the incidence of random drops is drastically reduced with mikezackles's comment #172 patch and associated sysfs setting.

Hello,

experiencing this issue on my P1Gen2 ThinkPad NB with Fedora SilverBlue system.

$ uname -r
5.12.13-300.fc34.x86_64

My WiFi:
52:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a)

journal log output:

čec 02 09:52:01 loki.packetseekers.eu kernel: wlp82s0: associated
čec 02 09:52:01 loki.packetseekers.eu NetworkManager[1176]: <info>  [1625212321.2311] device (wlp82s0): supplicant interface state: associating -> 4way_handshake
čec 02 09:52:01 loki.packetseekers.eu NetworkManager[1176]: <info>  [1625212321.2311] device (p2p-dev-wlp82s0): supplicant management interface state: associating -> 4way_handshake
čec 02 09:52:01 loki.packetseekers.eu NetworkManager[1176]: <info>  [1625212321.2312] device (wlp82s0): DHCPv4 lease renewal requested
čec 02 09:52:01 loki.packetseekers.eu NetworkManager[1176]: <info>  [1625212321.2396] dhcp4 (wlp82s0): canceled DHCP transaction
čec 02 09:52:01 loki.packetseekers.eu NetworkManager[1176]: <info>  [1625212321.2396] dhcp4 (wlp82s0): state changed bound -> terminated
čec 02 09:52:01 loki.packetseekers.eu NetworkManager[1176]: <info>  [1625212321.2399] dhcp4 (wlp82s0): activation: beginning transaction (timeout in 45 seconds)
čec 02 09:52:01 loki.packetseekers.eu wpa_supplicant[1277]: wlp82s0: WPA: Key negotiation completed with 48:8f:5a:34:06:47 [PTK=CCMP GTK=CCMP]
čec 02 09:52:01 loki.packetseekers.eu wpa_supplicant[1277]: wlp82s0: CTRL-EVENT-CONNECTED - Connection to 48:8f:5a:34:06:47 completed [id=0 id_str=]
čec 02 09:52:01 loki.packetseekers.eu NetworkManager[1176]: <info>  [1625212321.2610] device (wlp82s0): supplicant interface state: 4way_handshake -> completed
čec 02 09:52:01 loki.packetseekers.eu NetworkManager[1176]: <info>  [1625212321.2740] device (p2p-dev-wlp82s0): supplicant management interface state: 4way_handshake -> completed
čec 02 09:52:02 loki.packetseekers.eu kernel: iwlwifi 0000:52:00.0: No beacon heard and the session protection is over already...
čec 02 09:52:02 loki.packetseekers.eu kernel: wlp82s0: Connection to AP 48:8f:5a:34:06:47 lost
čec 02 09:52:02 loki.packetseekers.eu wpa_supplicant[1277]: wlp82s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=0 noise=9999 txrate=0
čec 02 09:52:02 loki.packetseekers.eu wpa_supplicant[1277]: wlp82s0: CTRL-EVENT-DISCONNECTED bssid=48:8f:5a:34:06:47 reason=4 locally_generated=1
čec 02 09:52:02 loki.packetseekers.eu wpa_supplicant[1277]: dbus: wpa_dbus_property_changed: no property SessionLength in object /fi/w1/wpa_supplicant1/Interfaces/0
čec 02 09:52:02 loki.packetseekers.eu NetworkManager[1176]: <info>  [1625212322.1372] device (wlp82s0): supplicant interface state: completed -> disconnected
čec 02 09:52:02 loki.packetseekers.eu NetworkManager[1176]: <info>  [1625212322.1373] device (p2p-dev-wlp82s0): supplicant management interface state: completed -> disconnected
čec 02 09:52:02 loki.packetseekers.eu NetworkManager[1176]: <info>  [1625212322.2310] device (wlp82s0): supplicant interface state: disconnected -> scanning
čec 02 09:52:02 loki.packetseekers.eu NetworkManager[1176]: <info>  [1625212322.2310] device (p2p-dev-wlp82s0): supplicant management interface state: disconnected -> scanning
čec 02 09:52:03 loki.packetseekers.eu wpa_supplicant[1277]: wlp82s0: SME: Trying to authenticate with 48:8f:5a:34:06:47 (SSID='TAJ-2' freq=2447 MHz)

Output from my Mikrotik router log:
A8:7E:EA:56:A4:E6@wlan1: disconnected, received deauth: no activity (4)


I read something that changing the AP settings could help. Do someone here knows how to do that on my Mikrotik router?

after a full 2 days of my holidays pulling my hair out & alienating myself from my family, I found something that is working well for me (for now).

I run fedora 34 on a fairly broken Toshiba Satellite LG50-A.  Suites me fine, & I get a kick out of wringing every last semblance of life out of this thing!

Long story short, to try:

echo 5000 > /sys/module/mac80211/parameters/probe_wait_ms 
echo 50 > /sys/module/mac80211/parameters/beacon_loss_count

If that works for you, you can make it permanent by:

cat << EOF > /etc/modprobe.d/mac80211.conf
option mac80211 beacon_loss_count=50
option mac80211 probe_wait_ms=5000
EOF

Probably overkill, & I can supply more info if asked.

My laptop's wifi has always been a bit crappy, tbh, & it's much better now, especially because I am forcing 40MHz wide wireless N - I know I shouldn't, but 2.4g is a cluster-truck where I am anyway.

Usual stuff; your mileage may vary etc. ad nausuem; all care no responsibility.  Good luck.

(In reply to marc from comment #261)
> after a full 2 days of my holidays pulling my hair out & alienating myself
> from my family, I found something that is working well for me (for now).
> 
> I run fedora 34 on a fairly broken Toshiba Satellite LG50-A.  Suites me
> fine, & I get a kick out of wringing every last semblance of life out of
> this thing!
> 
> Long story short, to try:
> 
> echo 5000 > /sys/module/mac80211/parameters/probe_wait_ms 
> echo 50 > /sys/module/mac80211/parameters/beacon_loss_count
> 
> If that works for you, you can make it permanent by:
> 
> cat << EOF > /etc/modprobe.d/mac80211.conf
> option mac80211 beacon_loss_count=50
> option mac80211 probe_wait_ms=5000
> EOF
> 
> Probably overkill, & I can supply more info if asked.
> 
> My laptop's wifi has always been a bit crappy, tbh, & it's much better now,
> especially because I am forcing 40MHz wide wireless N - I know I shouldn't,
> but 2.4g is a cluster-truck where I am anyway.
> 
> Usual stuff; your mileage may vary etc. ad nausuem; all care no
> responsibility.  Good luck.

btw, I replied here, because it's this post that helped me the most, so big thanks to all of those that helped me (indirectly) + a special thanks to whomever it was that talked about beacon intervals.  Also beware that this mod will likely have implications for your WPA2 setup (you'll be able to use it again :D )

(In reply to marc from comment #261)

> option mac80211 beacon_loss_count=50
> option mac80211 probe_wait_ms=5000

Seems promising to me. I can't test this for a little while, but I'm hopeful that it will provide some relief without patching. If this turns out to be a definitive workaround, I can't believe it took this long for someone to point it out! Thanks for sharing!

(In reply to mikezackles from comment #263)
> (In reply to marc from comment #261)
> 
> > option mac80211 beacon_loss_count=50
> > option mac80211 probe_wait_ms=5000
> 
> Seems promising to me. I can't test this for a little while, but I'm hopeful
> that it will provide some relief without patching. If this turns out to be a
> definitive workaround, I can't believe it took this long for someone to
> point it out! Thanks for sharing!

So I got more curious about this & continued tinkering.  Here's what I found:

* my modprobe config was wrong.  Here it is now, with some further tweaks:
# cat /etc/modprobe.d/mac80211.conf 
options mac80211 beacon_loss_count=1000 probe_wait_ms=75
options ath9k debug=0xffffffff btcoex_enable=0 ps_enable=0 use_msi=0

I encourage any noobs (like me) to use modinfo & google to work out what I've done.

This config prevented the connection dropping.  I still get HUGE ping spikes - up to 3 seconds! but my connection doesn't actually drop anymore.

I can push data at about 5 to 8 MB/s to a local server using scp.  It would be faster, but I get about 10 second blocks followed by about 2 to 3 second periods of negligable data rates when I look using the system monitor; you could nearly time a German train on it; it's very frustrating.

Turning off IPv6 removed all errors from debug in my router & my laptop, so everything is hunky-dory according to that, & I'm just not going to know what's causing those flat spots in transmission rates.

I tried all sorts of different g & n, wide & 20MHz channels & the flat spots in my data rates do not go away.

I'm now so curious about this I could burst tbh.

(In reply to marc from comment #264)
> So I got more curious about this & continued tinkering.  Here's what I found:
> 
> * my modprobe config was wrong.  Here it is now, with some further tweaks:
> # cat /etc/modprobe.d/mac80211.conf 
> options mac80211 beacon_loss_count=1000 probe_wait_ms=75
> options ath9k debug=0xffffffff btcoex_enable=0 ps_enable=0 use_msi=0
> 
ok.  grr.  problem appears completely fixed for me now.  But I learned a lot.  But I'm embarrassed.  Here it is:
1) systemctl disable --now bluetooth # I used "rfkill event" to see that my radio was getting turned off every ~10 seconds!  I don't use bluetooth on my laptop, tough if I did
2) turn off ipv6 (fedora 34 is NetworkManager or a lot of work - I'm  allergic to work - that was the disconnect problem - I don't need IPv6 for now, so I'm happy, & there's definitely a problem there I think)
3) I had some acpi tuning in my kernel options that I turned off.  I don't think this made any difference at all, but I'm glad to be rid of having anything custom & for that exact same reason I was able to remove my modprobe customizations.

My wifi works for me now.  I average about 5MB/s (because people get confused, I'm saying ~ 5 * 1024 * 1204 * 8 bits per second) with anywhere from 2MB/s to about 12MB/s common variance probably due to interference on my HT40 2.4g 802.11n connection.

Very interestingly, I did find a 99999 us (10 seconds!) parameter in the aqm code which is just too interesting to pass up but I think that's OT to this bug report.

I really hope this helps someone - directly or otherwise.  Personally I resent the time I have to spend rooting these problems out, & I know it'll be a PITA if I ever decide I want to use bluetooh again.

Ping me if I can help you, I may be willing to - but OT for this bug.

I can confirm that with the patch https://aur.archlinux.org/pkgbase/linux-beacon applied my wifi is working flawlessly (on Archlinux).

I tried mac80211 module config beacon_loss_count=50 probe_wait_ms=5000 does not work, still has beacon lost and disconnect

(In reply to how from comment #267)
> I tried mac80211 module config beacon_loss_count=50 probe_wait_ms=5000 does
> not work, still has beacon lost and disconnect

see my previous post about MY hardware (tobshiba satellite l50-a, atheros bluetooth/2.4g pcie card) - in summary: try these things * turn ipv6 off * turn bluetooth off * increase the beacon loss count (probe wait seems less important).  see how you go.  Also I tried to bear in mind that this is bugzilla, not tech support.

I just updated to 5.10.52 (LTS) (from 5.10.51) and despite having the workaround from comment #172 in my local patches, my WiFi is constantly dropping with a vengeance once again - every 20 seconds to a few minutes!

It occasionally states "No beacon heard and the time event is over already" but frequently just disconnects without giving a reason.

I'll try downgrading to 5.10.51 tomorrow and see if the errant behaviour also reverts.

Created attachment 297995 [details]
attachment-10273-0.html

Dear sender,

I am out of office until 26th of July 2021 and will answer your email after my return.
In urgent cases, please contact Mr. Gerd Brost (gerd.brost@aisec.fraunhofer.de), he will redirect you to the right person.

Best regards,
Mathias Morbitzer

Disabling IPv6 via sysctl.conf really helped with the beacons dropping.

Created attachment 298877 [details]
dmseg log in Fedora 34 which has 5.13.16-200.fc34.x86_64 kernel at the moment

```
pranav@fedora ~> ethtool -i wlp3s0
driver: iwlwifi
version: 5.13.16-200.fc34.x86_64
firmware-version: 17.3216344376.0 3160-17.ucode
expansion-rom-version:
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
pranav@fedora ~> lspci -kvnn | sed -n '/Network/,/^$/ p'
03:00.0 Network controller [0280]: Intel Corporation Wireless 3160 [8086:08b3] (rev 83)
	Subsystem: Intel Corporation Dual Band Wireless AC 3160 [8086:8470]
	Flags: bus master, fast devsel, latency 0, IRQ 49
	Memory at c1000000 (64-bit, non-prefetchable) [size=8K]
	Capabilities: <access denied>
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi
pranav@fedora ~>
```

Experienced similar bug today.

Network controller [0280]: Intel Corporation Wi-Fi 6 AX201
driver: iwlwifi
version: 5.15.1-2.gdcfd611-default
firmware-version: 63.c04f3485.0 QuZ-a0-hr-b0-63.u

None of the proposed actions did really work, but switching from leap to tumbleweed and kernel 5.15.1-2.gdcfd611-default with the latest firmware didn't make the problem disappear, but 5ghz wifi now becomes usable (less than 1% packet loss).

Same issue here with Fedora 35

Dec10 08:14] wlp4s0: Connection to AP 44:a6:1e:ea:9a:d5 lost
[  +0.288456] wlp4s0: authenticate with 44:a6:1e:ea:9a:d0
[  +0.002411] wlp4s0: send auth to 44:a6:1e:ea:9a:d0 (try 1/3)
[  +0.030269] wlp4s0: authenticated
[  +0.000575] wlp4s0: associate with 44:a6:1e:ea:9a:d0 (try 1/3)
[  +0.010794] wlp4s0: RX AssocResp from 44:a6:1e:ea:9a:d0 (capab=0x1411 status=0 aid=3)
[  +0.006745] wlp4s0: associated
[  +0.160819] wlp4s0: Limiting TX power to 20 (20 - 0) dBm as advertised by 44:a6:1e:ea:9a:d0
[  +4.147438] wlp4s0: deauthenticated from 44:a6:1e:ea:9a:d0 (Reason: 12=<unknown>)
[  +0.644001] wlp4s0: authenticate with 44:a6:1e:ea:9a:d5
[  +0.003845] wlp4s0: send auth to 44:a6:1e:ea:9a:d5 (try 1/3)
[  +0.004685] wlp4s0: authenticated
[  +0.000759] wlp4s0: associate with 44:a6:1e:ea:9a:d5 (try 1/3)
[  +0.003442] wlp4s0: RX AssocResp from 44:a6:1e:ea:9a:d5 (capab=0x1511 status=0 aid=8)
[  +0.002473] wlp4s0: associated
[  +0.603012] iwlwifi 0000:04:00.0: No beacon heard and the time event is over already...


$ ethtool -i wlp4s0
driver: iwlwifi
version: 5.15.6-200.fc35.x86_64
firmware-version: 36.ca7b901d.0 8265-36.ucode
expansion-rom-version: 
bus-info: 0000:04:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

$  lspci -kvnn | sed -n '/Network/,/^$/ p'
04:00.0 Network controller [0280]: Intel Corporation Wireless 8265 / 8275 [8086:24fd] (rev 78)
	Subsystem: Intel Corporation Dual Band Wireless-AC 8265 [8086:0010]
	Flags: bus master, fast devsel, latency 0, IRQ 163
	Memory at ec100000 (64-bit, non-prefetchable) [size=8K]
	Capabilities: <access denied>
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

$ uname -a
5.15.6-200.fc35.x86_64 #1 SMP Wed Dec 1 13:41:10 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Same thing happens to me on a Dell XPS 13 9310 2-in-1 (Intel Corporation Wi-Fi 6 AX201 (rev 20)):

[ 4136.870490] wlp0s20f3: authenticate with 3c:a6:2f:23:d9:7d
[ 4136.881492] wlp0s20f3: send auth to 3c:a6:2f:23:d9:7d (try 1/3)
[ 4137.001509] wlp0s20f3: authenticated
[ 4137.003196] wlp0s20f3: associate with 3c:a6:2f:23:d9:7d (try 1/3)
[ 4137.006526] wlp0s20f3: RX AssocResp from 3c:a6:2f:23:d9:7d (capab=0x1511 status=0 aid=1)
[ 4137.018060] wlp0s20f3: associated
[ 4137.781572] iwlwifi 0000:00:14.3: No beacon heard and the session protection is over already...
[ 4137.781672] wlp0s20f3: Connection to AP 3c:a6:2f:23:d9:7d lost

Router: Fritzbox 7530 and Fritz Repeater 2400: It tries to connect via 5Ghz to the 2400 AP but usually drops within minutes. Very annoying issue, especially when working via ssh on a remote server. Happens to me with latest firmware and kernel 5.15.7.

Why is this still flagged as NEEDINFO? What info do you need?

Not sure if it will help anyone, but I solved this with the core64 release of the iwlwifi drivers ( https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/backport-iwlwifi.git/log/?h=release/core64 )


compiled with the instructions from: https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/core_release


my reasoning is that it already had the bug fix from https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/backport-iwlwifi.git/commit/?id=53faa7fb4f69b2e28495b05e0a8bae7bcf47d60e


The next thing i did was get the microcode from here: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git 



I used: iwlwifi-QuZ-a0-hr-b0-63.ucode



which i just copied to /lib/firmware



I am way out of my league here, but I thought it might help someone. This worked on a debian 11 



$ uname -a
Linux bml01 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1 (2021-12-08) x86_64 GNU/Linux



with an intel comet lake wifi interface.  



$lspci -kvnn | sed -n '/Network/,/^$/ p'
00:14.3 Network controller [0280]: Intel Corporation Comet Lake PCH CNVi WiFi [8086:06f0]
	Subsystem: Intel Corporation Comet Lake PCH CNVi WiFi [8086:0070]
	Flags: bus master, fast devsel, latency 0, IRQ 16, IOMMU group 7
	Memory at 604111c000 (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] Latency Tolerance Reporting
	Capabilities: [164] Vendor Specific Information: ID=0010 Rev=0 Len=014 <?>
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

I've recently upgraded the kernel to 5.12.12 and it has become a constant annoyance with my 9260. Guess I'll need to start compiling the kernel with mikezackles patch...


Also this has been asked multiple times but who "NEEDSINFO"?

Installed the microcode from Luca's 196 comment and apparently it has a higher version than the intalled with Arch pacman????

old -> Jan 04 16:35:04 krystal kernel: iwlwifi 0000:04:00.0: loaded firmware version 46.6b541b68.0 9260-th-b0-jf-b0-46.ucode op_mode iwlmvm
new -> Jan 04 16:46:20 krystal kernel: iwlwifi 0000:04:00.0: loaded firmware version 46.8902351f.0 9260-th-b0-jf-b0-46.ucode op_mode iwlmvm


It fixed my issue. For anyone looking for a fix, just downgrade the uCode for the iwlwifi don't mess with anything else.

what do you mean by downgrade ucode? There are several Intel wifi cards mentioned. The initial report is for 8260. Each card has different firmware, downgrade which?

(In reply to Yury Pakin from comment #235)

> After 2 hours and 49 minutes from the start of the test, the rx bitrate
> dropped to 1 MBit/s:
> 

Interesting, I'm experiencing the same behavior after roughly 3 hours after the machine is turned on and connected.
I have a Lenovo P50, (Intel Corporation Wireless 8260 (rev 3a)) kernel 5.16.2 and I'm experiencing this issue quite regularly since a lot of time. Oddly enough, after several disconnections the issue solves itself.

I'm going to try some of the suggestions in this thread to see if something changes. I have no problem into patching the kernel itself, I'm only not sure which patch to try, this thread is really something huge :)

(In reply to Fabio Coatti from comment #280)
> (In reply to Yury Pakin from comment #235)
> 
> > After 2 hours and 49 minutes from the start of the test, the rx bitrate
> > dropped to 1 MBit/s:
> > 
> 
> Interesting, I'm experiencing the same behavior after roughly 3 hours after
> the machine is turned on and connected.
> I have a Lenovo P50, (Intel Corporation Wireless 8260 (rev 3a)) kernel
> 5.16.2 and I'm experiencing this issue quite regularly since a lot of time.
> Oddly enough, after several disconnections the issue solves itself.
> 
> I'm going to try some of the suggestions in this thread to see if something
> changes. I have no problem into patching the kernel itself, I'm only not
> sure which patch to try, this thread is really something huge :)

Open the file drivers/net/wireless/intel/iwlwifi/mvm/mvm.h,
and change the value of 
IWL_MVM_MISSED_BEACONS_THRESHOLD_LONG 
much larger, for examle, from 16 to 256 or more.

(In reply to how from comment #279)
> what do you mean by downgrade ucode? There are several Intel wifi cards
> mentioned. The initial report is for 8260. Each card has different firmware,
> downgrade which?

9260, it's in the logs I included -> "9260-th-b0-jf-b0-46.ucode"

(In reply to NHonda from comment #281)
> (In reply to Fabio Coatti from comment #280)
> > (In reply to Yury Pakin from comment #235)
> > 
> > > After 2 hours and 49 minutes from the start of the test, the rx bitrate
> > > dropped to 1 MBit/s:
> > > 
> > 
> > Interesting, I'm experiencing the same behavior after roughly 3 hours after
> > the machine is turned on and connected.
> > I have a Lenovo P50, (Intel Corporation Wireless 8260 (rev 3a)) kernel
> > 5.16.2 and I'm experiencing this issue quite regularly since a lot of time.
> > Oddly enough, after several disconnections the issue solves itself.
> > 
> > I'm going to try some of the suggestions in this thread to see if something
> > changes. I have no problem into patching the kernel itself, I'm only not
> > sure which patch to try, this thread is really something huge :)
> 
> Open the file drivers/net/wireless/intel/iwlwifi/mvm/mvm.h,
> and change the value of 
> IWL_MVM_MISSED_BEACONS_THRESHOLD_LONG 
> much larger, for examle, from 16 to 256 or more.

Since I applied the patch (a couple of days) the behavior did not repeated and no issues with wifi connections. Thanks!

Since I removed my AX200 from my Thinkpad, threw it in the bin and installed an RTL8852AE for a few bucks, I have had no problems at all.
I can finally use WiFi again.

Hi. I've had this problem for a very long time, but just now found that THIS bug report is really the place to be.
To sum up key points from this 3 year saga of a bug:

1) The patch enabling IWL_MVM_MISSED_BEACONS_THRESHOLD_LONG to be an exposed parameter (configurable in modprobe options; possibly even writable under /sys/modules/iwlmvm/parameters) seems to be *harmless*. There is debate about whether it fixes it for everyone, and whether a high setting may cause other delays. Linux is all about YMMV. I ask that this patch, leaving the default as-is, but making the setting configurable, be considered for merge.

2) It's about the access point driver. My google wifi hockey puck access point never gives me a problem, but my ISP-provided access point does.
I totally agree it's an AP driver bug, but that's not helpful. I'd like to be able to function when I'm in an airport, bookstore, etc. where I don't own the AP. 
As others have said, LOTS of other wifi adapters handle this particular access point driver "bug" without a problem. So inflexibility in THIS driver is a bug too. Note, even, the Windows driver for this same hardware handles this situation just fine.

3) Please be decent to each other ;)

(In reply to Troy Volin from comment #285)
> I ask that this patch, leaving the default as-is, but making the setting
> configurable, be considered for merge.

At this point I'm a bit out of the loop when it comes to this bug, but if you're serious about getting the patch merged I'm guessing it might get more attention from people that matter on the linux wireless mailing list than here.

(In reply to mikezackles from comment #286)
> (In reply to Troy Volin from comment #285)
> > I ask that this patch, leaving the default as-is, but making the setting
> > configurable, be considered for merge.
> 
> At this point I'm a bit out of the loop when it comes to this bug, but if
> you're serious about getting the patch merged I'm guessing it might get more
> attention from people that matter on the linux wireless mailing list than
> here.

Thanks Mike.
How do you feel about submitting the patch you wrote, as per https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ?
attachment 294585 [details]

Even if you feel out of the loop on the symptoms etc, this is still a "make a parameter out of what used to be a static value" patch.
If you'd rather, I can do it.

(In reply to Troy Volin from comment #287)
> (In reply to mikezackles from comment #286)
> How do you feel about submitting the patch you wrote, as per
> https://wireless.wiki.kernel.org/en/developers/documentation/
> submittingpatches ?

Ha I guess I was being lazy :) Sure, I will do my best to submit it over the weekend and CC you.

I don't know, if my comment here is on the right place, because I have the "no beacon" message in dmesg very seldom, but all the symptoms are the same as described.

My router is a Fritz.Box 7530 XU - and 2 laptops with  MX-Linux 5.10.0-9-amd64


1) Acer R5-131T with AC 3165

intel wifi iwlwifi 0000:02:00.0: Detected Intel(R) Dual Band Wireless AC 3165, REV=0x210

2) Toshiba Portege X30-D with AC 8265

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

The Acer works without any problems, when the router is set to use 2.4 GHz and 5 GHz on the same ssid. When I start beside the router it uses 5 GHz, when I walk away it switches to 2.4 GHz and I even don't notice, when watching a film and it stays on 2.4 GHz

The Portege works, when I set the router to use only 2.4 GHz without any problems - the same on Win Pro 10, when the router is set to 2.4 + 5 GHz.

in Linux I have freezes - films are stopping sometime breakdowns etc...

when I look in wavemon, it starts with 2.4 GHz and after about 45 sec it changes to 5 GHz and there the drops are starting.

So I thought, lets tell Network Manager to use only 2.4 GHz -  so I edited /etc/NetworkManager/system-connections under the [wifi] section, edit the band field to the following [wifi]): band=n

but this does not work - it is overruled the same behavior as before - so looking to something other possibility

modinfo iwlwifi | grep disable
                parm:           11n_disable:disable 11n functionality, bitmap: 1: full, 2: disable agg TX, 4: disable agg RX, 8 enable agg TX (uint)
                parm:           uapsd_disable:disable U-APSD functionality bitmap 1: BSS 2: P2P Client (default: 3) (uint)
                parm:           power_save:enable WiFi power management (default: disable) (bool)
                parm:           disable_11ac:Disable VHT capabilities (default: false) (bool)
                parm:           disable_11ax:Disable HE capabilities (default: false) (bool)


gives the possibility to add iwlwifi.disable_11ac=1 iwlwifi.disable_11ax=1 to grub

it still does not use the 2.4 GHz, it switches to 5 GHz after 45 sec, but it starts switching back to 2.4 GHz when the connection is lost - so its a permanent switching between 2.4 GHz and 5 GHz  - and the good thing is, that the film is not stopping - sometimes there are artefacts, but it continues

I think - to really use the card, it should be possible that iwlwifi uses the boot parameters to disable ac and ax.

And in the long term the AC 8265 should behave like the AC 3165

Created attachment 300577 [details]
attachment-10582-0.html

Dear sender,


I am out of office and have limited access to my e-mail. I will be back on March 21.


In urgent cases, please contact Christian Banse (christian.banse@aisec.fraunhofer.de).



Best regards


Mathias Morbitzer

Kernel  5.17.3-arch1-1

problem still persist

[130573.479815] iwlwifi 0000:02:00.0: No beacon heard and the session protection is over already...


it is really annoying already.... 2 years and still it is NOT FIXED!

try higher beacon_loss_count in iwlwifi modprobe. Should help a bit. I have no more beacon lost message to be found in system logs

Hello,

I had the same issues with my WiFi in 2021

      lspci -kvnn | sed -n '/Network/,/^$/ p'
04:00.0 Network controller [0280]: Intel Corporation Wireless 7260 [8086:08b2] (rev 83)
        Subsystem: Intel Corporation Wireless-N 7260 [8086:4270]
        Flags: bus master, fast devsel, latency 0, IRQ 49
        Memory at f0500000 (64-bit, non-prefetchable) [size=8K]
        Capabilities: [c8] Power Management version 3
        Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [40] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        
since I patch

a/drivers/net/wireless/intel/iwlwifi/mvm/utils.c b/drivers/net/wireless/intel/iwlwifi/mvm/utils.c
index d2cada0ab4264..3303fc85d76f5 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/utils.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/utils.c
@@ -1029,9 +1029,6 @@ bool iwl_mvm_rx_diversity_allowed(struct iwl_mvm *mvm)

        lockdep_assert_held(&mvm->mutex);

-       if (iwlmvm_mod_params.power_scheme != IWL_POWER_SCHEME_CAM)
-               return false;
-
        if (num_of_ant(iwl_mvm_get_valid_rx_ant(mvm)) == 1)
                return false;

--
2.33.0

my self build kernel WiFi works like a charm. 

I think it has somethink to do with antennas in energy saving mode, and WiFi module switch to other antenna to early without energizing it before using other antenna. So for me it seems that there are no checks if antenna has energy and is ready for use. After switching to other antenna without energy connection will not work well ...

Maybe I'll be wrong, but for me it worked. I'm not a developer, so I'm not able to implement such checks correctly

regards

You're suggesting that reverting https://lore.kernel.org/all/iwlwifi.20211017113927.fc896bc5cdaa.I1d11da71b8a5cbe921a37058d5f578f1b14a2023@changeid/ fixes the issue?

If this code is related to power saving, might be fine for desktops but perhaps not laptops or other portables where power saving is more important

This could be the first step. I dont suggest reverting this, but doing this prevents the described problems for me. My suggestion is to implement checks to not use the antenna(s) if there is no power on it. It shold be used only if its powered up. For me stability is more importend then powersaving. I know other like longer runs of battery driven device, but it's no fun if WiFi don't work and maybe you need to reboot, which consumes eventually more energy.

Many comments here switch off powersavings to get stable WiFi, other put WiFi in debug-mode which also switch of powersavings and get more stable WiFi-device. Attemps to make time longer to wake up for the antennas in energy-saving mode helped a bit, but problems still present. The logical decission is to first power up antenna and then use it. Not to hope because signal is comming it switches on. It has to be check if its energized before using it.

I use this since November 2021 and at the moment at kernel 5.17.5. I had never seen any error messages after using this. 

regards

(In reply to mikezackles from comment #288)
> (In reply to Troy Volin from comment #287)
> > (In reply to mikezackles from comment #286)
> > How do you feel about submitting the patch you wrote, as per
> > https://wireless.wiki.kernel.org/en/developers/documentation/
> > submittingpatches ?
> 
> Ha I guess I was being lazy :) Sure, I will do my best to submit it over the
> weekend and CC you.

https://patchwork.kernel.org/project/linux-wireless/patch/20220226045047.643695-1-mikezackles@gmail.com/ is this the patch that you created?

(In reply to Matt from comment #296)
> (In reply to mikezackles from comment #288)
> > (In reply to Troy Volin from comment #287)
> > > (In reply to mikezackles from comment #286)
> > > How do you feel about submitting the patch you wrote, as per
> > > https://wireless.wiki.kernel.org/en/developers/documentation/
> > > submittingpatches ?
> > 
> > Ha I guess I was being lazy :) Sure, I will do my best to submit it over
> the
> > weekend and CC you.
> 
> https://patchwork.kernel.org/project/linux-wireless/patch/20220226045047.
> 643695-1-mikezackles@gmail.com/ is this the patch that you created?

Yes, that's the one! :)

Hmm, after firing up 5.15.43, this issue has come back with a vengeance - it's disconnecting with "No beacon heard and the session protection is over already..." literally every 10 seconds like clockwork even though I have the patch from comment #172 and have tried values from 256 to 1024 in /sys/module/iwlwifi/parameters/beacon_timeout

Seems like turning off power management helps though…

(In reply to triffid.hunter from comment #298)
> Hmm, after firing up 5.15.43, this issue has come back with a vengeance -
> it's disconnecting with "No beacon heard and the session protection is over
> already..." literally every 10 seconds like clockwork even though I have the
> patch from comment #172 and have tried values from 256 to 1024 in
> /sys/module/iwlwifi/parameters/beacon_timeout
> 
> Seems like turning off power management helps though…

Don't confuse both the kernel messages
"No beacon heard and the session protection is over already"
and
"No beacon heard and the time event is over already",
because they are different kinds of timeout caused 
by different reasons or bugs.
The patch is irrelevant and has no effect
with the former "session protection timeout", I think.

I had a similar issue with Intel AX200 on Ubuntu 20.04 and 5.4.0-125-generic. My motherboard, ASUS B550-F gaming, had an antenna attachment for the WiFi port. I tried disabling IPv6 and power savings, but strangely enough, removing the antenna was the best fix for me, which makes it believable that it's related to the physical properties of the antenna.

Created attachment 301675 [details]
attachment-29102-0.html

Dear sender,


I am out of office and have limited access to my e-mail. I will be back on September 8.

In urgent cases, please contact my group leader, Gerd Brost (gerd.brost@aisec.fraunhofer.de).


Best regards

Mathias Morbitzer

Created attachment 301757 [details]
Log showing apparent race if beacon is lost during association

I'd really like to see this issue fixed.  I am not so concerned about the reason for beacon loss.  The real issue for me is that the system will drop offline permanently in some situations.  The attached log shows evidence of what I believe to be a race that occurs when the beacon is lost during re-association after a previous loss.  When this happens, the authorization fails with 'no-secrets' and will not restart.  I have confirmed that restarting the NetworkManager service will cause reconnection (I did this by setting a cron script to restart the NetworkManager at a specified time each day).  Instead of having to do this, the NetworkManager should be able to recover from this race and not drop permanently offline.

I have the same issue with Intel 7265D. I have enabled debug flags for iwlwifi and installed the debug firmware. Which debug flags (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/wireless/intel/iwlwifi/iwl-debug.h#n129) would be interesting to enable to help debugging?

Hi folks,

I managed to fix this problem. Had this issue with the 7260 and 8260 and AX200, the fix I found that worked was to change the channel to 52 which is a DFS channel, I tried different channels that were not DFS and those channels had the problem, No beacon heard at this time and constant disconnecting, reconnecting. 

Can some of you guys try a DFS channel if either the Access Point or Router supports it please, as I believe that it could be a problem with normal channels as such interference problems or nearby APs and Routers knocking you off 5Ghz, I live in a heavily populated location and there are not any APs and Routers that uses DFS channels. 

Something to note, the Laptop with the Intel 7260 had the antenna around the wrong way as HP labelled the cables wrong so check this as this was a issue on my old HP 4540s as some WIFI Cards have the antenna connections reversed.

Tested this with Ubuntu Desktop 18.04, 20.04 and 22.04. No tweaks have been made with Power Management or other configuration were changed.

Keep me updated.

Regards

Jack

This issue appears fairly reproducible for me between a TP-Link router running OpenWRT and an Intel Corporation Wireless 8260 chipset.

When using Linux 6.0.0-5-amd64 the issue causes a wifi disconnection; NetworkManager attempts reconnection/re-authentication and this fails.

When using Linux 5.10.0-19-amd64 the issue either does not occur -- or it is silently handled: no disconnection occurs.

I haven't yet recompiled a kernel with iwlwifi firmware debugging support enabled but may do soon.

I've recently begun experiencing this issue on an Asus T300CHI with 7265D that has, for the last several years, been entirely well behaved. Using mainline kernel builds, most recently v6.2.9, with Kubuntu 22.04, NetworkManager, wpa_supplicant, and:

tj@t300chi:~$ uname -r
6.2.9-tj+
tj@t300chi:~$ lspci -nnk -d ::280
02:00.0 Network controller [0280]: Intel Corporation Wireless 7265 [8086:095a] (rev 59)
        Subsystem: Intel Corporation Dual Band Wireless-AC 7265 [8086:5100]
        Kernel driver in use: iwlwifi
        Kernel modules: iwlwifi
tj@t300chi:~$ journalctl -k --grep 'iwlwifi.*Firmware loaded'
Apr 01 08:36:05 t300chi kernel: iwlwifi 0000:02:00.0: Firmware loaded: iwlwifi-7265D-29.ucode
$ iwconfig wlp2s0
wlp2s0    IEEE 802.11  ESSID:"AP"  
          Mode:Managed  Frequency:2.412 GHz  Access Point: B8:27:EB:4D:55:39   
          Bit Rate=57.8 Mb/s   Tx-Power=22 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=42/70  Signal level=-68 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:200   Missed beacon:0

I have a couple of access points, both using Debian or Debian-based distro. Currently mostly see this with a RasPi operating on 2.4GHz with no other WiFi devices within range (I'm on a farm in midst of fields):

tj@noc:~$ uname -r
5.15.32-v7+
tj@noc$ cat /sys/firmware/devicetree/base/model
Raspberry Pi 3 Model B Rev 1.2

The RasPi doesn't log any messages when the client is failing.

When the repeated disconnects occur client logs show:

Apr 01 07:39:58 t300chi wpa_supplicant[730]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 01 07:39:58 t300chi kernel: wlp2s0: Connection to AP b8:27:eb:4d:55:39 lost
...
Apr 01 07:39:59 t300chi wpa_supplicant[730]: wlp2s0: CTRL-EVENT-DISCONNECTED bssid=b8:27:eb:4d:55:39 reason=4 locally_generated=1
...
Apr 01 07:40:00 t300chi wpa_supplicant[730]: wlp2s0: SME: Trying to authenticate with b8:27:eb:4d:55:39 (SSID='soggy' freq=2412 MHz)
Apr 01 07:40:00 t300chi kernel: wlp2s0: authenticate with b8:27:eb:4d:55:39
...
Apr 01 07:40:00 t300chi kernel: wlp2s0: associate with b8:27:eb:4d:55:39 (try 1/3)
Apr 01 07:40:00 t300chi kernel: wlp2s0: RX AssocResp from b8:27:eb:4d:55:39 (capab=0x411 status=0 aid=1)
Apr 01 07:40:00 t300chi kernel: wlp2s0: associated
...
Apr 01 07:40:00 t300chi kernel: wlp2s0: Connection to AP b8:27:eb:4d:55:39 lost
Apr 01 07:40:00 t300chi wpa_supplicant[730]: wlp2s0: WPA: Key negotiation completed with b8:27:eb:4d:55:39 [PTK=CCMP GTK=CCMP]
Apr 01 07:40:00 t300chi wpa_supplicant[730]: wlp2s0: CTRL-EVENT-CONNECTED - Connection to b8:27:eb:4d:55:39 completed [id=0 id_str=]
...
Apr 01 07:40:00 t300chi wpa_supplicant[730]: wlp2s0: CTRL-EVENT-DISCONNECTED bssid=b8:27:eb:4d:55:39 reason=4 locally_generated=1

At this point the entire connect - authenticate - disconnect loop constantly repeats every few seconds with IP addresses being gained and lost immediately.

I initially had occasional success by removing the PCI device and then rescanning, but mostly even that does not help:

$ iwl=$(readlink -e /sys/class/net/wlp2s0/device)
$ echo 1 | sudo dd of=${iwl}/remove
$ echo 1 | sudo dd of=${iwl%/*}/rescan

Log then shows:

Apr 01 07:53:50 t300chi kernel: pci 0000:02:00.0: [8086:095a] type 00 class 0xffffff
Apr 01 07:53:50 t300chi kernel: pci 0000:02:00.0: Max Payload Size set to 128 (was 16384, max 128)
Apr 01 07:53:50 t300chi kernel: pci 0000:02:00.0: 2.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x1 link at 0000:00:1c.3 (capable of 3969.945 Gb/s...
...
Apr 01 07:53:50 t300chi kernel: pci 0000:02:00.0: buffer not found in pci_save_pcie_state
...
Apr 01 07:53:50 t300chi libvirtd[844]: internal error: Unknown PCI header type '127' for device '0000:02:00.0'
...
Apr 01 07:55:21 t300chi kernel: pci 0000:02:00.0: buffer not found in pci_save_pcie_state
Apr 01 07:55:22 t300chi kernel: pci 0000:02:00.0: timed out waiting for pending transaction; performing function level reset anyway
Apr 01 07:55:23 t300chi kernel: pci 0000:02:00.0: not ready 1023ms after FLR; waiting
Apr 01 07:55:24 t300chi kernel: pci 0000:02:00.0: not ready 2047ms after FLR; waiting
Apr 01 07:55:26 t300chi kernel: pci 0000:02:00.0: not ready 4095ms after FLR; waiting
Apr 01 07:55:31 t300chi kernel: pci 0000:02:00.0: not ready 8191ms after FLR; waiting
Apr 01 07:55:39 t300chi kernel: pci 0000:02:00.0: not ready 16383ms after FLR; waiting
Apr 01 07:55:56 t300chi kernel: pci 0000:02:00.0: not ready 32767ms after FLR; waiting
Apr 01 07:56:32 t300chi kernel: pci 0000:02:00.0: not ready 65535ms after FLR; giving up
Apr 01 07:56:32 t300chi kernel: pci 0000:02:00.0: buffer not found in pci_save_pcie_state

At this point a complete power-off to cold (not a warm reboot) resets the device to working condition.

As others have recently pointed out this does seem to be some interaction between firmware and driver.

Having followed the instructions for Firmware Debugging from:

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

And triggering a coredump the expected sysfs devcoredump node doesn't appear. Is the core dump only created if there is an error detected by the driver?

$ uname -r;
6.2.9-tj+

$ grep -E 'COREDUMP|IWLWIFI_DEBUG' /boot/config-$(uname -r);
CONFIG_COREDUMP=y
CONFIG_WANT_DEV_COREDUMP=y
CONFIG_ALLOW_DEV_COREDUMP=y
CONFIG_DEV_COREDUMP=y
CONFIG_IWLWIFI_DEBUG=y
CONFIG_IWLWIFI_DEBUGFS=y

$ journalctl -k --grep 'iwlwifi.*Firmware loaded'
Apr 01 11:09:45 t300chi kernel: iwlwifi 0000:02:00.0: Firmware loaded: iwlwifi-7265D-29.ucode

$ ls -l /usr/lib/firmware/iwlwifi-7265D-29*
-rw-r--r-- 1 root root 1036644 Apr  1 10:00 /usr/lib/firmware/iwlwifi-7265D-29.debug.ucode
-rw-r--r-- 1 root root 1036772 Mar 24 08:09 /usr/lib/firmware/iwlwifi-7265D-29.release.ucode
lrwxrwxrwx 1 root root      28 Apr  1 10:02 /usr/lib/firmware/iwlwifi-7265D-29.ucode -> iwlwifi-7265D-29.debug.ucode

$ cat /sys/class/devcoredump/disabled;
0

$ echo 1 | sudo dd of=/sys/kernel/debug/iwlwifi/0000:02:00.0/iwlmvm/fw_dbg_collect

$ journalctl -k --grep 'iwlwifi.*Collecting data';
Apr 01 11:17:13 t300chi kernel: iwlwifi 0000:02:00.0: Collecting data: trigger 1 fired.

$ ls /sys/devices/virtual/devcoredump
ls: cannot access '/sys/devices/virtual/devcoredump': No such file or directory

It seems I followed the instructions a little too assiduously before testing it - and the udev rule + shell script were always triggered and writing the dump to /var/log/ and then - of course - clearing the /sys/devices/virtual/devcoredump/devcd*/data node. I didn't realise that would cause the /sys/devices/virtual/devcoredump/ node to be removed as well!

So, debug is ready to go. I have a hunch this may be related to power-saving since I'm almost convinced I've only seen it when the system has been running on battery (this morning's bug report was when the battery was at 47%), but much of the time the system is on AC charger power. So, I'm currently keeping it on AC for a few days without any suspend/resume cycles, then if no failures, will do some suspend/resume cycles and then let it run for another few days. After that I'll do a cold boot to battery power and give it a few days, etc.

Interesting occurrence overnight. Did a cold boot at 19:35 and left it with GUI logged into my regular user account with screen locked. Came back to it at 10:13 and found there had been a prolonged period of "connection lost" - 544 in fact - between 08:21 and 08:44 at which point it connected successfully again and remained connected (and was usable when I returned). Theree were  

tj@t300chi $ journalctl -k --since="08:21" --until="08:44" --grep 'Connection to AP.*lost'  | wc -l
544

Apr 02 08:21:07 t300chi kernel: wlp2s0: Connection to AP b8:27:eb:4d:55:39 lost
Apr 02 08:21:09 t300chi kernel: wlp2s0: authenticate with b8:27:eb:4d:55:39
Apr 02 08:21:09 t300chi kernel: wlp2s0: 80 MHz not supported, disabling VHT
Apr 02 08:21:09 t300chi kernel: wlp2s0: send auth to b8:27:eb:4d:55:39 (try 1/3)
Apr 02 08:21:09 t300chi kernel: wlp2s0: authenticated
Apr 02 08:21:09 t300chi kernel: wlp2s0: associate with b8:27:eb:4d:55:39 (try 1/3)
Apr 02 08:21:09 t300chi kernel: wlp2s0: RX AssocResp from b8:27:eb:4d:55:39 (capab=0x411 status=0 aid=1)
Apr 02 08:21:09 t300chi kernel: wlp2s0: associated
Apr 02 08:21:09 t300chi kernel: wlp2s0: Connection to AP b8:27:eb:4d:55:39 lost
Apr 02 08:21:13 t300chi kernel: wlp2s0: authenticate with b8:27:eb:4d:55:39
Apr 02 08:21:13 t300chi kernel: wlp2s0: 80 MHz not supported, disabling VHT
Apr 02 08:21:13 t300chi kernel: wlp2s0: send auth to b8:27:eb:4d:55:39 (try 1/3)
Apr 02 08:21:13 t300chi kernel: wlp2s0: authenticated
Apr 02 08:21:13 t300chi kernel: wlp2s0: associate with b8:27:eb:4d:55:39 (try 1/3)
Apr 02 08:21:13 t300chi kernel: wlp2s0: RX AssocResp from b8:27:eb:4d:55:39 (capab=0x411 status=0 aid=1)
Apr 02 08:21:13 t300chi kernel: wlp2s0: associated
Apr 02 08:21:13 t300chi kernel: wlp2s0: Connection to AP b8:27:eb:4d:55:39 lost

There were no firmware crashes and no udevd derived dumps.

At those times, on the AP, hostapd reports repeated "disassociated" messages. What is interesting there is that for each client "connection lost" hostapd shows two "disassociated" reports. I wonder if this is 'normal' or some kind of clue.

tj@noc:~$ journalctl --since="08:21" --until="08:44" --grep 'disassociated'  | wc -l
1097

Apr 02 08:21:07 noc hostapd[545]: wlan0: STA 34:02:86:fc:ad:55 IEEE 802.11: disassociated
Apr 02 08:21:07 noc hostapd[545]: wlan0: STA 34:02:86:fc:ad:55 IEEE 802.11: disassociated
Apr 02 08:21:09 noc hostapd[545]: wlan0: STA 34:02:86:fc:ad:55 IEEE 802.11: associated
Apr 02 08:21:09 noc hostapd[545]: wlan0: STA 34:02:86:fc:ad:55 RADIUS: starting accounting session 8FEA9E8CA240D5D6
Apr 02 08:21:09 noc hostapd[545]: wlan0: STA 34:02:86:fc:ad:55 WPA: pairwise key handshake completed (RSN)
Apr 02 08:21:09 noc hostapd[545]: wlan0: STA 34:02:86:fc:ad:55 IEEE 802.11: disassociated
Apr 02 08:21:09 noc hostapd[545]: wlan0: STA 34:02:86:fc:ad:55 IEEE 802.11: disassociated
Apr 02 08:21:13 noc hostapd[545]: wlan0: STA 34:02:86:fc:ad:55 IEEE 802.11: associated
Apr 02 08:21:13 noc hostapd[545]: wlan0: STA 34:02:86:fc:ad:55 RADIUS: starting accounting session D373C9B8EA96D736
Apr 02 08:21:13 noc hostapd[545]: wlan0: STA 34:02:86:fc:ad:55 WPA: pairwise key handshake completed (RSN)
Apr 02 08:21:13 noc hostapd[545]: wlan0: STA 34:02:86:fc:ad:55 IEEE 802.11: disassociated
Apr 02 08:21:13 noc hostapd[545]: wlan0: STA 34:02:86:fc:ad:55 IEEE 802.11: disassociated

In the immediate previous report I neglected to include info on the beacon loss. Not many were reported:

tj@t300chi:~$ journalctl --since="08:21" --until="08:44" --grep "CTRL-EVENT-BEACON-LOSS" 
Apr 02 08:21:00 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 02 08:21:06 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 02 08:21:31 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 02 08:22:11 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 02 08:22:13 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 02 08:22:14 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 02 08:22:28 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 02 08:22:39 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 02 08:22:59 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 02 08:36:14 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 02 08:36:16 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 02 08:41:57 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 02 08:42:00 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 02 08:42:02 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 02 08:42:46 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS

> I've recently begun experiencing this issue on an Asus T300CHI with 7265D
> that has, for the last several years, been entirely well behaved

This sounds like a hardware issue.

I don't think it is hardware. Had another episode of loss that recovered fine with very few BEACON_LOSS events:

$ journalctl -k  --since="01:30" --until=02:00 | grep 'Connection to AP.*lost'  | wc -l
535

Apr 04 01:36:08 t300chi kernel: wlp2s0: Connection to AP b8:27:eb:4d:55:39 lost
Apr 04 01:36:10 t300chi kernel: wlp2s0: Connection to AP b8:27:eb:4d:55:39 lost
Apr 04 01:36:14 t300chi kernel: wlp2s0: Connection to AP b8:27:eb:4d:55:39 lost
...
Apr 04 01:59:50 t300chi kernel: wlp2s0: Connection to AP b8:27:eb:4d:55:39 lost
Apr 04 01:59:54 t300chi kernel: wlp2s0: Connection to AP b8:27:eb:4d:55:39 lost
Apr 04 01:59:58 t300chi kernel: wlp2s0: Connection to AP b8:27:eb:4d:55:39 lost

$ journalctl  --since="00:00" -u wpa_supplicant --grep CTRL-EVENT-BEACON-LOSS
Apr 04 01:37:12 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 04 01:37:19 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 04 01:42:44 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 04 01:47:18 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 04 01:47:20 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 04 01:47:35 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 04 01:58:20 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS

One more incident, system not powered down or suspended yet.

tj@t300chi:~$ uname -r
6.2.9-tj+

tj@t300chi:~$ uptime
 09:49:49 up 5 days, 14:14,  9 users,  load average: 0.05, 0.08, 0.10

$ journalctl -b --grep 'Connection.* lost|CTRL-EVENT-BEACON-LOSS' --since="2023-04-05" --until="2023-04-06" | awk '{lines[NR] = $0; if(NR>=5){delete lines[NR-5]}} NR<5 || /CTRL-EVENT-BEACON-LOSS/{print;next}END{for(l in lines){print lines[l]}}'
Apr 05 04:42:20 t300chi kernel: wlp2s0: Connection to AP b8:27:eb:4d:55:39 lost
Apr 05 04:42:21 t300chi kernel: wlp2s0: Connection to AP b8:27:eb:4d:55:39 lost
Apr 05 04:42:28 t300chi kernel: wlp2s0: Connection to AP b8:27:eb:4d:55:39 lost
Apr 05 04:42:30 t300chi kernel: wlp2s0: Connection to AP b8:27:eb:4d:55:39 lost
Apr 05 04:44:43 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 05 04:44:44 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 05 04:44:46 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 05 04:48:16 t300chi wpa_supplicant[698]: wlp2s0: CTRL-EVENT-BEACON-LOSS
Apr 05 04:51:14 t300chi kernel: wlp2s0: Connection to AP b8:27:eb:4d:55:39 lost
Apr 05 04:51:16 t300chi kernel: wlp2s0: Connection to AP b8:27:eb:4d:55:39 lost
Apr 05 04:51:18 t300chi kernel: wlp2s0: Connection to AP b8:27:eb:4d:55:39 lost
Apr 05 04:51:19 t300chi kernel: wlp2s0: Connection to AP b8:27:eb:4d:55:39 lost
Apr 05 04:51:23 t300chi kernel: wlp2s0: Connection to AP b8:27:eb:4d:55:39 lost

I'm going to complete a full week (7 days) like this, then remove external power and do a cold start -  only recharging to 100% when battery level drops to around 20%.