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 :-(