Bug 203709 - iwlwifi: 8260: frequently disconnects since Linux 5.1 "No beacon heard and the time event is over already" - WIFI-25906
Summary: iwlwifi: 8260: frequently disconnects since Linux 5.1 "No beacon heard and th...
Status: NEEDINFO
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Intel Linux Wireless
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-05-25 23:06 UTC by Denis Lisov
Modified: 2020-06-18 19:13 UTC (History)
31 users (show)

See Also:
Kernel Version: 5.1.5
Tree: Mainline
Regression: Yes


Attachments
concatenation of full dmesg and post-boot logs of kernel+NM+wpa_supplicant (377.13 KB, text/plain)
2019-05-25 23:06 UTC, Denis Lisov
Details
journal excerpt for intel 8265 NIC on iwd/networkd, iwlwifi debug=0x20 (37.00 KB, text/plain)
2019-07-26 19:24 UTC, Ronan Pigott
Details
iwlwifi trace (5.2.9 w/patch from comment 6) (1.71 MB, application/octet-stream)
2019-08-23 19:06 UTC, Denis Lisov
Details
trace-cmd: Intel Corporation Wireless 7260 (rev 83) (1.45 MB, application/x-xz)
2019-08-27 22:37 UTC, brian
Details
Intel 7260 syslog accompanying the trace (1.56 KB, text/plain)
2019-08-27 22:38 UTC, brian
Details
Core dump and syslog on Intel 7260 (41.89 KB, application/pgp-encrypted)
2019-11-11 17:50 UTC, Nathaniel Cook
Details
5.4.0: trace-cmd record -e iwlwifi -e mac80211 -e cfg80211 -e iwlwifi_msg (1.55 MB, application/pgp-encrypted)
2019-11-26 09:00 UTC, Denis Lisov
Details
log of AX200 (12.50 KB, text/plain)
2020-02-19 10:03 UTC, lukas.redlinger
Details
Reverted SAR refactor patch for kernel 5.5.9 (30.39 KB, patch)
2020-03-27 09:35 UTC, Francesco Giudici
Details | Diff

Description Denis Lisov 2019-05-25 23:06:34 UTC
Created attachment 282941 [details]
concatenation of full dmesg and post-boot logs of kernel+NM+wpa_supplicant

Hardware: Thinkpad P50 with Intel Corporation Wireless 8260 [8086:24f3]
Software: Gentoo Linux with vanilla kernel, NetworkManager using wpa_supplicant

In Linux 5.0 the WiFi connection to my home network is rather stable. In Linux 5.1 (5.1.5 at the moment) it's unstable with the following symptoms.

Ping check to the router looks like this
64 bytes from 192.168.183.1: icmp_seq=54 ttl=64 time=5.81 ms
64 bytes from 192.168.183.1: icmp_seq=55 ttl=64 time=1.00 ms
64 bytes from 192.168.183.1: icmp_seq=56 ttl=64 time=1.17 ms
64 bytes from 192.168.183.1: icmp_seq=57 ttl=64 time=3.31 ms
From 192.168.183.5 icmp_seq=58 Destination Host Unreachable
From 192.168.183.5 icmp_seq=59 Destination Host Unreachable
From 192.168.183.5 icmp_seq=60 Destination Host Unreachable
From 192.168.183.5 icmp_seq=65 Destination Host Unreachable
From 192.168.183.5 icmp_seq=66 Destination Host Unreachable
From 192.168.183.5 icmp_seq=67 Destination Host Unreachable
From 192.168.183.5 icmp_seq=68 Destination Host Unreachable
From 192.168.183.5 icmp_seq=69 Destination Host Unreachable
From 192.168.183.5 icmp_seq=70 Destination Host Unreachable
64 bytes from 192.168.183.1: icmp_seq=78 ttl=64 time=1.07 ms
64 bytes from 192.168.183.1: icmp_seq=79 ttl=64 time=0.940 ms
64 bytes from 192.168.183.1: icmp_seq=80 ttl=64 time=0.951 ms
64 bytes from 192.168.183.1: icmp_seq=81 ttl=64 time=0.950 ms
64 bytes from 192.168.183.1: icmp_seq=82 ttl=64 time=1.17 ms
and so on, changing from ok to host unreachable a few times per minute.

The dmesg output looks like this (full log in attachment):
[  408.580520] wlp4s0: associated
[  420.822273] wlp4s0: Connection to AP ec:43:f6:07:90:84 lost
[  423.420415] wlp4s0: authenticate with ec:43:f6:07:90:84
[  423.431798] wlp4s0: send auth to ec:43:f6:07:90:84 (try 1/3)
[  423.436016] wlp4s0: authenticated
[  423.438864] wlp4s0: associate with ec:43:f6:07:90:84 (try 1/3)
[  423.542285] wlp4s0: associate with ec:43:f6:07:90:84 (try 2/3)
[  423.550083] wlp4s0: RX AssocResp from ec:43:f6:07:90:84 (capab=0xc11 status=0 aid=3)
[  423.552862] wlp4s0: associated
[  424.045586] iwlwifi 0000:04:00.0: No beacon heard and the time event is over already...
[  424.045622] wlp4s0: Connection to AP ec:43:f6:07:90:84 lost
[  425.178388] wlp4s0: authenticate with ec:43:f6:07:90:84
[  425.188576] wlp4s0: send auth to ec:43:f6:07:90:84 (try 1/3)
[  425.191274] wlp4s0: authenticated
[  425.192183] wlp4s0: associate with ec:43:f6:07:90:84 (try 1/3)
[  425.202483] wlp4s0: RX AssocResp from ec:43:f6:07:90:84 (capab=0xc11 status=0 aid=3)
[  425.206217] wlp4s0: associated
[  425.802779] iwlwifi 0000:04:00.0: No beacon heard and the time event is over already...
[  425.802814] wlp4s0: Connection to AP ec:43:f6:07:90:84 lost
[  427.060487] wlp4s0: authenticate with ec:43:f6:07:90:84
[  427.069870] wlp4s0: send auth to ec:43:f6:07:90:84 (try 1/3)
[  427.072586] wlp4s0: authenticated
[  427.078966] wlp4s0: associate with ec:43:f6:07:90:84 (try 1/3)
[  427.185781] wlp4s0: associate with ec:43:f6:07:90:84 (try 2/3)
[  427.222630] wlp4s0: RX AssocResp from ec:43:f6:07:90:84 (capab=0xc11 status=0 aid=3)
[  427.225860] wlp4s0: associated
[  427.683876] iwlwifi 0000:04:00.0: No beacon heard and the time event is over already...
[  427.683911] wlp4s0: Connection to AP ec:43:f6:07:90:84 lost
[  440.104459] wlp4s0: authenticate with ec:43:f6:07:90:84
[  440.112495] wlp4s0: send auth to ec:43:f6:07:90:84 (try 1/3)
[  440.116197] wlp4s0: authenticated
[  440.119343] wlp4s0: associate with ec:43:f6:07:90:84 (try 1/3)
[  440.124865] wlp4s0: RX AssocResp from ec:43:f6:07:90:84 (capab=0xc11 status=0 aid=3)
[  440.129543] wlp4s0: associated
[  440.750534] IPv6: ADDRCONF(NETDEV_CHANGE): wlp4s0: link becomes ready
[  452.055008] wlp4s0: Connection to AP ec:43:f6:07:90:84 lost

The corresponding part of NetworkManager logs is attached too.
Comment 1 Ronan Pigott 2019-07-26 19:24:22 UTC
Created attachment 283993 [details]
journal excerpt for intel 8265 NIC on iwd/networkd, iwlwifi debug=0x20
Comment 2 Ronan Pigott 2019-07-26 19:26:16 UTC
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)
Comment 3 Ronan Pigott 2019-07-26 19:35:49 UTC
forgot to mention -- in my case,

$ uname -r
5.2.2-arch1-1-ARCH
Comment 4 bugzilla.kernel.org 2019-08-01 01:57:29 UTC
Can see this occuring Intel Corporation Wireless 7260 as well on `5.1.15-arch1-1-ARCH`.
Comment 5 kurmikon 2019-08-12 20:29:36 UTC
It's happening also on my Intel 3165, even on Linux 5.0.
Comment 6 Luca Coelho 2019-08-22 05:22:33 UTC
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/
Comment 7 kurmikon 2019-08-22 06:25:42 UTC
Already used that patch compiling the kernel, but I had same issues.
Comment 8 Ronan Pigott 2019-08-22 06:34:28 UTC
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.
Comment 9 Luca Coelho 2019-08-22 06:36:58 UTC
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
Comment 10 Luca Coelho 2019-08-22 06:38:56 UTC
Thanks for all the info, Ronan!

Can you also provide trace-cmd logs as explained in the wiki I linked in comment 9?
Comment 11 Ronan Pigott 2019-08-22 07:03:20 UTC
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.
Comment 12 Denis Lisov 2019-08-23 09:22:21 UTC
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?
Comment 13 Luca Coelho 2019-08-23 09:24:58 UTC
Thanks for testing, Denis.

So, if the issue is not related, we could use some traces as mentioned in comment #9.
Comment 14 Denis Lisov 2019-08-23 19:06:20 UTC
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
Comment 15 Luca Coelho 2019-08-26 06:19:56 UTC
Thanks again.  We will assign someone internally to look into this.
Comment 16 brian 2019-08-27 22:37:12 UTC
Created attachment 284643 [details]
trace-cmd: Intel Corporation Wireless 7260 (rev 83)

Trace from Intel 7260 in ThinkPad T440s attached!
Comment 17 brian 2019-08-27 22:38:43 UTC
Created attachment 284645 [details]
Intel 7260 syslog accompanying the trace

This may help correlate timestamps in the trace.
Comment 18 brian 2019-08-27 22:40:00 UTC
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
Comment 19 brian 2019-08-31 19:04:25 UTC
Confirmed likely a software issue. Just installed another 7260 in same machine. Same issue.
Comment 20 Denis Lisov 2019-09-18 19:58:09 UTC
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.
Comment 21 Karthik 2019-11-04 09:07:19 UTC
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
Comment 22 Denis Lisov 2019-11-04 09:20:14 UTC
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?
Comment 23 Nathaniel Cook 2019-11-11 17:50:53 UTC
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.
Comment 24 Denis Lisov 2019-11-26 08:59:40 UTC
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.
Comment 25 Denis Lisov 2019-11-26 09:00:55 UTC
Created attachment 286063 [details]
5.4.0: trace-cmd record -e iwlwifi -e mac80211 -e cfg80211 -e iwlwifi_msg
Comment 26 Denis Lisov 2019-12-15 12:22:42 UTC
Ping. Is anything else I can help with?
Comment 27 pirmin 2019-12-27 08:05:57 UTC
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.
Comment 28 Emmanuel Grumbach 2020-01-21 07:40:11 UTC
@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 |
Comment 29 mail 2020-01-21 13:35:51 UTC
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)
...
...
Comment 30 Emmanuel Grumbach 2020-01-21 18:01:06 UTC
Hi,

What firmware version do you use?
Comment 31 mail 2020-01-21 18:49:22 UTC
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
Comment 32 Emmanuel Grumbach 2020-01-25 18:28:16 UTC
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.
Comment 33 Emmanuel Grumbach 2020-01-29 12:04:05 UTC
Hi,

did you have a chance to test the patch?
Comment 34 mail 2020-01-29 13:48:03 UTC
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?
Comment 35 Emmanuel Grumbach 2020-01-29 13:53:27 UTC
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.
Comment 36 Denis Lisov 2020-01-29 16:57:46 UTC
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.
Comment 37 Emmanuel Grumbach 2020-01-29 17:17:37 UTC
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.
Comment 38 Denis Lisov 2020-01-29 17:47:30 UTC
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.
Comment 39 Emmanuel Grumbach 2020-02-03 20:57:35 UTC
That would be really strange..
Still no luck on reproduction ?
Comment 40 Andrey Vihrov 2020-02-03 21:21:22 UTC
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.
Comment 41 Emmanuel Grumbach 2020-02-04 06:03:39 UTC
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?
Comment 42 pirmin 2020-02-04 14:33:13 UTC
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.
Comment 43 Emmanuel Grumbach 2020-02-04 15:07:22 UTC
@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.
Comment 44 pirmin 2020-02-05 10:09:46 UTC
@Emmanuel

unfortunatelly not, no.
Comment 45 Mike Wilson 2020-02-09 17:57:12 UTC
@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.
Comment 46 Emmanuel Grumbach 2020-02-09 21:08:49 UTC
@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.
Comment 47 Andrey Vihrov 2020-02-10 18:59:46 UTC
(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.
Comment 48 Francisco Cribari 2020-02-11 17:37:36 UTC
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
Comment 49 Emmanuel Grumbach 2020-02-11 18:09:10 UTC
This is absolutely not related to this bug.
Comment 50 lukas.redlinger 2020-02-19 10:03:11 UTC
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
Comment 51 lukas.redlinger 2020-02-19 11:43:06 UTC
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
Comment 52 Kyriakos Fytrakis 2020-02-19 12:53:33 UTC
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
Comment 53 Danilo Cominotti Marques 2020-02-20 17:10:44 UTC
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.
Comment 54 Danilo Cominotti Marques 2020-02-20 17:20:17 UTC
(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.
Comment 55 WGH 2020-03-10 00:56:18 UTC
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.
Comment 56 MIC 2020-03-11 17:55:39 UTC
(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
Comment 57 Andre Jonas 2020-03-11 19:24:15 UTC
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.
Comment 58 iamrihan 2020-03-24 01:43:39 UTC
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.
Comment 59 Francesco Giudici 2020-03-27 09:29:06 UTC
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! :-)
Comment 60 Francesco Giudici 2020-03-27 09:35:35 UTC
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.
Comment 61 Andre Jonas 2020-03-28 22:17:24 UTC
(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).
Comment 62 Francesco Giudici 2020-03-29 08:22:11 UTC
(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.
Comment 63 Fitap 2020-04-24 01:30:06 UTC
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.
Comment 64 kotrfa 2020-04-26 13:06:31 UTC
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.
Comment 65 Konstantin 2020-06-04 12:08:56 UTC
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
Comment 66 Naruto windy 2020-06-06 15:00:14 UTC
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.
Comment 67 kotrfa 2020-06-17 14:10:00 UTC
I don't think there is any fix yet :-( . I am now on 5.7.2 (Arch Linux) and the problem is still there.
Comment 68 kotrfa 2020-06-17 14:15:29 UTC
It has `NEEDSINFO` status - what info is needed please?
Comment 69 mikezackles 2020-06-17 14:24:13 UTC
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.
Comment 70 brian 2020-06-17 14:48:19 UTC
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.
>
Comment 71 Naruto windy 2020-06-17 15:17:14 UTC
It's observed on Debian , Ubuntu all other distros not only  on Arch Linux.
Comment 72 kotrfa 2020-06-18 13:42:09 UTC
I downgraded to 5.4.46-1 on Archlinux too and it seems it doesn't happen there indeed.
Comment 73 mikezackles 2020-06-18 15:29:09 UTC
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).
Comment 74 Naruto windy 2020-06-18 19:09:23 UTC
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.
Comment 75 kotrfa 2020-06-18 19:13:24 UTC
OK, sorry for the confusion, I confirm it happens on 5.4 too :-(

Note You need to log in before you can comment on or make changes to this bug.