[SOLVED] Wifi not working after update in February 2020

llesudb · 2020-06-11 05:02:08

Hello,

After an upgrade on Feb 2, 2020, my laptop wifi stopped working. As in, the system is generally unable to interact with the wifi card. After some searching on the forums, I initially thought that the issue was related to this bug in the Linux kernel: https://bbs.archlinux.org/viewtopic.php?id=252635

However, that was reportedly fixed in 5.5.11. I am using the current version of `linux` and am still experiencing this issue.

Wifi card:

$ lspci -nnk | grep -A4 Network
00:14.3 Network controller [0280]: Intel Corporation Wireless-AC 9560 [Jefferson Peak] [8086:a370] (rev 10)
        DeviceName: Onboard - Ethernet
        Subsystem: Intel Corporation Device [8086:0034]
        Kernel driver in use: iwlwifi
        Kernel modules: iwlwifi

$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp60s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:d8:61:09:83:84 brd ff:ff:ff:ff:ff:ff
3: wlo1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 66:22:e6:83:9e:77 brd ff:ff:ff:ff:ff:ff permaddr 48:89:e7:16:c6:32
    altname wlp0s20f3
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:c5:fa:ae:18 brd ff:ff:ff:ff:ff:ff
5: docker_gwbridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 02:42:6a:7d:6c:6b brd ff:ff:ff:ff:ff:ff
11: vethb3aff08@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker_gwbridge state UP mode DEFAULT group default 
    link/ether ba:69:89:aa:54:49 brd ff:ff:ff:ff:ff:ff link-netnsid 1
21: veth251c53c@if20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker_gwbridge state UP mode DEFAULT group default 
    link/ether 16:64:27:1d:1d:46 brd ff:ff:ff:ff:ff:ff link-netnsid 6
$ sudo ip link set wlo1 up
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp60s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:d8:61:09:83:84 brd ff:ff:ff:ff:ff:ff
3: wlo1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 66:22:e6:83:9e:77 brd ff:ff:ff:ff:ff:ff permaddr 48:89:e7:16:c6:32
    altname wlp0s20f3
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:c5:fa:ae:18 brd ff:ff:ff:ff:ff:ff
5: docker_gwbridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 02:42:6a:7d:6c:6b brd ff:ff:ff:ff:ff:ff
11: vethb3aff08@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker_gwbridge state UP mode DEFAULT group default 
    link/ether ba:69:89:aa:54:49 brd ff:ff:ff:ff:ff:ff link-netnsid 1
21: veth251c53c@if20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker_gwbridge state UP mode DEFAULT group default 
    link/ether 16:64:27:1d:1d:46 brd ff:ff:ff:ff:ff:ff link-netnsid 6

$ sudo journalctl -b

https://pastebin.com/WE4JbCHD

$ sudo dmesg

https://pastebin.com/kZnim2CK

Any ideas what could be wrong?

Last edited by llesudb (2020-06-13 04:20:09)

V1del · 2020-06-11 07:15:14

You have at least one instance of wpa_supplicant@ and a seperate instance of NetworkManager running. These are conflicting services. Stop one, enable the other, only one networking service should be active at any given time. What's your output for for

find /etc/systemd -type l -exec test -f {} \; -print

llesudb · 2020-06-12 04:11:07

Ah, that did it! I disabled my wpa_supplicant services, and now things are back to normal. Not sure why that update spontaneously caused a problem, but very glad that the issue is finally resolved.

Since you asked,

$ find /etc/systemd -type f -exec test -f '{}' ';' -print
/etc/systemd/network/25-wireless.network
/etc/systemd/network/20-wired.network
/etc/systemd/journal-remote.conf
/etc/systemd/user.conf
/etc/systemd/networkd.conf
/etc/systemd/system.conf
/etc/systemd/timesyncd.conf
/etc/systemd/pstore.conf
/etc/systemd/journald.conf
/etc/systemd/logind.conf
/etc/systemd/resolved.conf
/etc/systemd/sleep.conf
/etc/systemd/journal-upload.conf
/etc/systemd/coredump.conf

Thanks for the help!

Last edited by llesudb (2020-06-12 04:11:29)

V1del · 2020-06-12 07:32:08

This has always been explicitly recommended against and causes a race condition for the network controller and can lead to various kinds of undefined behaviour (the most extreme case I've seen was a kernel panic with a specific interface driver) note the Note. There have been some changes to the service file and how the daemon of wpa_supplicant is started in february which likely unearthed this misconfiguration more explicitly.

Please mark as [SOLVED] by editing the title in the subject line.

Btw, that's not quite the output I asked for, not the -type l instead of f

Arch Linux

#1 2020-06-11 05:02:08

[SOLVED] Wifi not working after update in February 2020

#2 2020-06-11 07:15:14

Re: [SOLVED] Wifi not working after update in February 2020

#3 2020-06-12 04:11:07

Re: [SOLVED] Wifi not working after update in February 2020

#4 2020-06-12 07:32:08

Re: [SOLVED] Wifi not working after update in February 2020

Board footer