Bug 1179517 - WLAN is constantly reconnecting
WLAN is constantly reconnecting
Status: NEW
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Network
Current
Other Other
: P5 - None : Major (vote)
: ---
Assigned To: openSUSE Kernel Bugs
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-12-02 10:26 UTC by Arvin Schnell
Modified: 2020-12-04 09:29 UTC (History)
2 users (show)

See Also:
Found By: Development
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
end of journalctl (13.31 KB, text/x-log)
2020-12-02 10:26 UTC, Arvin Schnell
Details
hwinfo (966.83 KB, text/x-log)
2020-12-02 12:08 UTC, Arvin Schnell
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Arvin Schnell 2020-12-02 10:26:24 UTC
Created attachment 844064 [details]
end of journalctl

The WLAN is constantly reconnecting.

I found several reports on bugzilla.kernel.org and other locations
but no solution AFAIS.
Comment 1 Takashi Iwai 2020-12-02 11:47:22 UTC
Is this a regression from the earlier releases?  If yes, which version worked?

The symptom is often related with the signal quality and/or the power-saving setup.  Try to check iwconfig about the signal quality and check whether you can have a better result when you test closer to the AP.

Also, some module options like

options iwlmvm power_scheme=1
options iwlwifi power_save=0

might help a bit.

In anyway, please give the hwinfo output.
Comment 2 Arvin Schnell 2020-12-02 12:05:10 UTC
The message "No beacon heard ..." shows up for the first time in journalctl
a week ago (Nov 27), and around 400 times since then. journalctl starts
months earlier.

Currently the connection is stable again and iwconfig outputs:

wlp3s0    IEEE 802.11  ESSID:"kerberos"  
          Mode:Managed  Frequency:2.452 GHz  Access Point: E4:3E:D7:3B:FB:C3   
          Bit Rate=144.4 Mb/s   Tx-Power=22 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=61/70  Signal level=-49 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:1  Invalid misc:238   Missed beacon:0
Comment 3 Arvin Schnell 2020-12-02 12:08:32 UTC
Created attachment 844070 [details]
hwinfo
Comment 4 Takashi Iwai 2020-12-02 12:56:36 UTC
(In reply to Arvin Schnell from comment #2)
> The message "No beacon heard ..." shows up for the first time in journalctl
> a week ago (Nov 27), and around 400 times since then.

Could you identify what relevant changes were around that update?
At least either kernel-default, kernel-firmware-* or network-related pacakges.

> Currently the connection is stable again and iwconfig outputs:
> 
> wlp3s0    IEEE 802.11  ESSID:"kerberos"  
>           Mode:Managed  Frequency:2.452 GHz  Access Point: E4:3E:D7:3B:FB:C3
> 
>           Bit Rate=144.4 Mb/s   Tx-Power=22 dBm   
>           Retry short limit:7   RTS thr:off   Fragment thr:off
>           Encryption key:off
>           Power Management:off
>           Link Quality=61/70  Signal level=-49 dBm  
>           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>           Tx excessive retries:1  Invalid misc:238   Missed beacon:0

The signal looks good for now, that might be the reason :)
Let's see whether the issue gets triggered again.
Comment 5 Arvin Schnell 2020-12-02 16:34:13 UTC
(In reply to Takashi Iwai from comment #4)

> Could you identify what relevant changes were around that update?
> At least either kernel-default, kernel-firmware-* or network-related
> pacakges.

The first time the "beacon..." error appears kernel 5.9.8-2-default
was running. That was first included in Tumbleweed snapshot 20201117.
Comment 6 Takashi Iwai 2020-12-02 16:52:46 UTC
Thanks.  And the last good kernel was?  5.9.x had some struggle for the snapshot release, so I don't know any longer which kernel had been released...
Comment 7 Arvin Schnell 2020-12-02 17:00:34 UTC
Kernel 5.9.1-2 was installed prior to 5.9.8-2.
Comment 8 Takashi Iwai 2020-12-03 13:18:16 UTC
The patches that are relevant with iwlwifi and wireless stack between those versions are:
  patches.kernel.org/5.9.2-362-iwlwifi-mvm-split-a-print-to-avoid-a-WARNING-in.patch
  patches.kernel.org/5.9.2-363-iwlwifi-dbg-remove-no-filter-condition.patch
  patches.kernel.org/5.9.2-364-iwlwifi-dbg-run-init_cfg-function-once-per-driv.patch

  patches.kernel.org/5.9.2-336-nl80211-fix-OBSS-PD-min-and-max-offset-validati.patch
  patches.kernel.org/5.9.2-370-nl80211-fix-non-split-wiphy-information.patch
  patches.kernel.org/5.9.2-674-mac80211-handle-lack-of-sband-bitrates-in-rates.patch

  patches.kernel.org/5.9.5-117-mac80211-add-missing-queue-hash-initialization-.patch
  patches.kernel.org/5.9.7-125-mac80211-fix-regression-where-EAPOL-frames-were.patch

The first three for iwlwifi fixes look all irrelevant: a kernel print change, and two debug stuff changes.  If any, it might be in the rest for wireless stack.
Comment 9 Arvin Schnell 2020-12-04 09:19:22 UTC
Right now I have the problem again. The signal is otherwise good:

wlp3s0    IEEE 802.11  ESSID:"kerberos"
          Mode:Managed  Frequency:2.452 GHz  Access Point: E4:3E:D7:3B:FB:C3
          Bit Rate=144.4 Mb/s   Tx-Power=22 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=67/70  Signal level=-43 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0
Comment 10 Arvin Schnell 2020-12-04 09:29:21 UTC
I checked journalctl again and now the "No beacon heard" message is often
not present. Looking for "Connection to AP [...] lost" shows that the
problem happened already on Nov 22.