1

So I have Debian 9 installed on my laptop and it keeps bugging me with this annoying malfunction.

Sometimes, (say, one every three/four times) when I suspend the session and then wake up after some time, the wifi will not work no matter what I try. I usually depend on nmcli to connect to networks, and nmcli dev wifi list returns an empty list. At first I thought it could be an issue with nmcli since there is a well-known bug on wifi not working after suspending, but restarting NetworkManager via systemd didn't do the trick, as it seems it does in other cases. So I resorted to plain old wpa_supplicant with no more luck. wpa_cli gives this output

wpa_cli v2.4
Copyright (c) 2004-2015, Jouni Malinen <j@w1.fi> and contributors

This software may be distributed under the terms of the BSD license.
See README for more details.



Interactive mode

Could not connect to wpa_supplicant: (nil) - re-trying

Looks like NetworkManager is not the culprit this time. lshw marks the device as DISABLED

  *-network DISABLED
       description: Wireless interface
       product: RTL8723AE PCIe Wireless Network Adapter
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:05:00.0
       logical name: wlp5s0
       version: 00
       serial: d2:95:44:e0:af:6e
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
       configuration: broadcast=yes driver=rtl8723ae driverversion=4.9.0-4-amd64 firmware=N/A latency=0 link=no multicast=yes wireless=IEEE 802.11
       resources: irq:17 ioport:c000(size=256) memory:f7800000-f7803fff

while rfkill says it's not

0: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no
4: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no

ip link says the interface is DOWN, and I can't set it up 

3: wlp5s0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether d2:95:44:e0:af:6e brd ff:ff:ff:ff:ff:ff

This is the output of iwconfig:

wlp5s0    IEEE 802.11  ESSID:off/any
          Mode:Managed  Access Point: Not-Associated   Tx-Power=20 dBm
          Retry short limit:7   RTS thr=2347 B   Fragment thr:off
          Encryption key:off
          Power Management:off

and here are some relevant logs from the syslog:

Dec 30 22:21:25 null NetworkManager[540]: <info>  [1514668883.2236] device (wlp5s0):
 set-hw-addr: set MAC address to 0E:21:14:A7:BA:04 (scanning)                       
Dec 30 22:21:25 null NetworkManager[540]: <warn>  [1514668883.2942] device (wlp5s0):
 device not up after timeout!                                                       
Dec 30 22:21:25 null NetworkManager[540]: <warn>  [1514668883.2951] sup-iface[0x7fcb
2c004ab0,wlp5s0]: connection disconnected (reason -3)                               
Dec 30 22:21:25 null NetworkManager[540]: <info>  [1514668883.2952] device (wlp5s0):
 supplicant interface state: completed -> disconnected                              
Dec 30 22:21:26 null NetworkManager[540]: <warn>  [1514668883.2981] sup-iface[0x7fcb
2c004ab0,wlp5s0]: connection disconnected (reason -3)                               
Dec 30 22:21:26 null wpa_supplicant[591]: nl80211: deinit ifname=wlp5s0 disabled_11b
_rates=0
Dec 30 22:21:26 null NetworkManager[540]: <info>  [1514668883.2982] device (wlp5s0):
 supplicant interface state: disconnected -> disabled
Dec 30 22:21:26 null NetworkManager[540]: <info>  [1514668883.2986] device (wlp5s0):
 state change: disconnected -> unmanaged (reason 'sleeping') [30 10 37]
Dec 30 22:21:26 null NetworkManager[540]: <info>  [1514668883.2988] device (wlp5s0):
 set-hw-addr: reset MAC address to 54:27:1E:9D:59:F0 (unmanage)
[...]
Dec 30 22:21:28 null NetworkManager[540]: <info>  [1514668888.0173] manager: wake re
quested (sleeping: yes  enabled: yes)
Dec 30 22:21:28 null NetworkManager[540]: <info>  [1514668888.0174] manager: waking
up...
Dec 30 22:21:28 null NetworkManager[540]: <info>  [1514668888.0174] device (enp4s0):
 state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Dec 30 22:21:28 null kernel: [22510.411179] IPv6: ADDRCONF(NETDEV_UP): enp4s0: link
is not ready
Dec 30 22:21:28 null kernel: [22510.411746] IPv6: ADDRCONF(NETDEV_UP): enp4s0: link
is not ready
Dec 30 22:21:28 null NetworkManager[540]: <info>  [1514668888.0199] device (wlp5s0):
 state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Dec 30 22:21:28 null kernel: [22510.413409] IPv6: ADDRCONF(NETDEV_UP): wlp5s0: link
is not ready
[...]
Dec 30 22:21:28 null NetworkManager[540]: <warn>  [1514668888.0917] device (wlp5s0): device not up after timeout!
Dec 30 22:21:28 null NetworkManager[540]: <info>  [1514668888.0920] device (wlp5s0): set-hw-addr: set MAC address to 0E:21:14:A7:BA:04 (scanning)
Dec 30 22:21:28 null NetworkManager[540]: <info>  [1514668888.0925] manager: NetworkManager state is now DISCONNECTED
Dec 30 22:21:28 null wpa_supplicant[591]: Could not set interface wlp5s0 flags (UP): Resource temporarily unavailable
Dec 30 22:21:28 null wpa_supplicant[591]: nl80211: Could not set interface 'wlp5s0'
UP
Dec 30 22:21:28 null wpa_supplicant[591]: nl80211: deinit ifname=wlp5s0 disabled_11b_rates=0
Dec 30 22:21:28 null wpa_supplicant[591]: Could not set interface wlp5s0 flags (UP): Resource temporarily unavailable
Dec 30 22:21:28 null wpa_supplicant[591]: WEXT: Could not set interface 'wlp5s0' UP
Dec 30 22:21:28 null wpa_supplicant[591]: wlp5s0: Failed to initialize driver interface
Dec 30 22:21:29 null NetworkManager[540]: <error> [1514668889.4298] sup-iface[0x5563737e3020,wlp5s0]: error adding interface: wpa_supplicant couldn't grab this interface.
==============================[^ repeats 5 more times]==============================
Dec 30 22:22:20 null NetworkManager[540]: <info>  [1514668940.1438] device (wlp5s0): supplicant interface state: starting -> down
Dec 30 22:22:20 null NetworkManager[540]: <info>  [1514668940.1438] device (wlp5s0): supplicant interface keeps failing, giving up

I can usually fix this just by rebooting. However, there are times (like this one) where even rebooting won't fix it. Moreover, the wifi device will disappear completely (rfkill doesn't list it, no logs in dmesg). Even if I try rebooting 2-3 times the problems persists. Then I need to do a hard poweroff, completely unplug it from the current, and wait for about 10-30 seconds for the circuits to uncharge. When I boot again everything is back to normal. I've come to think it might be related to some corrupt state in the hardware that goes away only when the circuit is depleted and thus forgets the corrupt state, but I had never faced this kind of behaviour in this very same computer. It could be it's getting old but, again, other OSs work just fine in this respect.

I guess there will be some totally unrelated and useless information above, but since I can't reproduce the issue consistently I thought I would collect all the data I thought could give a clue about what's happening.

Thank you very much in advance for your help and patience and please do ask for more information if needed. I will try to provide it as soon as the bug shows up again, which often times is sooner that I'd like.

cronos2
  • 203
  • 1
    please see https://unix.stackexchange.com/questions/413334/power-management-not-working-with-realtek-wifi-card and https://unix.stackexchange.com/questions/252210/wi-fi-problems-using-asus-usb-n13-adapter/252215 – Rui F Ribeiro Dec 31 '17 at 15:32
  • Well thank you, you seem to be well versed in this area. Just a couple of doubts. You mentioned that these chipsets usually work better on Windows because of some hacks. While that's true, I also managed to have it working with no major issues on other Debian-based OSs and I think Arch too. And then there's the fact that both posts deal with problems with USB adapters, while in my case it's the internal chipset the one that causes problems (it doesn't appear under lsusb but under lspci). Any thoughts? – cronos2 Jan 02 '18 at 21:17
  • Also, both of them were about RLT8192CU while mine is RTL8723AE, although it looks like there is a general consensus about Realtek's products quality. – cronos2 Jan 02 '18 at 21:20
  • The "wake up" part of your post got my attention. The energy management system is often documented as notoriously buggy in many realtek chipsets, and I suspect you are suffering because of it. I would try another brand. I also do not contest realtek works well enough for the needs of some people, nonetheless they can be unstable/unreliable. I would try removing and inserting the interface/kernel module when waking up to see if it helps. – Rui F Ribeiro Jan 02 '18 at 21:39
  • I have the same issue, but without the (nil) – Alex Dec 18 '19 at 14:08

0 Answers0