RTL8723BS wifi no longer functioning

[stanhebben]

I have 3 devices with identical hardware and software. However, I am experiencing some issues regarding their wifi connection:

• Device 1 works properly and is connected to its wifi network.
• Device 2 can't activate its wifi modem; attempting to bring the interface up with ifup wlan0 fails. Scanning also fails (network isn't up)
• Device 3 was working properly (not connected to wifi but capable of wifi scanning) until I rebooted it. Then it experienced the same issue as device 2.

This issue has been seen before and back then it disappeared for no apparent reason.

When testing on device 2 and 3, attempting to bring the interface up with ifup wlan0 results in the following error:

Code: Select all

wpa_supplicant: /sbin/wpa_supplicant daemon failed to start
run-parts: /etc/network/if-pre-up.d/wpasupplicant exited with return code 1
ifup: failed to bring up wlan0

Checking journalctl as for why wpa_supplicant fails shows me something's when wpa_supplicant attempts to communicate with the driver: (journalctl | grep wpa_supplicant)

Code: Select all

Jul 01 09:47:20 debian wpa_supplicant[1514]: Successfully initialized wpa_supplicant
Jul 01 09:47:21 debian wpa_supplicant[1514]: Could not set interface wlan0 flags (UP): Operation not permitted
Jul 01 09:47:21 debian wpa_supplicant[1514]: nl80211: Could not set interface 'wlan0' UP
Jul 01 09:47:21 debian wpa_supplicant[1514]: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Jul 01 09:47:21 debian wpa_supplicant[1514]: Could not set interface wlan0 flags (UP): Operation not permitted
Jul 01 09:47:21 debian wpa_supplicant[1514]: WEXT: Could not set interface 'wlan0' UP
Jul 01 09:47:21 debian wpa_supplicant[1514]: wlan0: Failed to initialize driver interface

The system is a debian 9 installation with the Liquorix kernel (5.0.0.0-9.2-liquorix-amd64) to make sure I have the latest staging drivers for the wifi interface.

What has already been tried, with no effect:

• Rebooting the system using the reboot command
• Unloading and reloading the driver (modprobe -r rtlwifi r8723bs; modprobe rtlwifi r8723bs)

Other things worth mentioning:

• This appears to happen when the device was on but the wifi hasn't been used for several days or weeks. These are devices that are always on.
• After posting this, I turned the device off physically and had it rest for a couple minutes. Then turned it on, and wifi is fine. This was device 2. However, this doesn't solve my root issue - I'll need to be able to fix this without restarting the device.

Does anyone recognize this issue, and how could it be fixed?

Thanks

[trinidad]

Code: Select all

Jul 01 09:47:21 debian wpa_supplicant[1514]: nl80211: Could not set interface 'wlan0' UP
Jul 01 09:47:21 debian wpa_supplicant[1514]: nl80211: deinit ifname=wlan0 disabled_

wlan0 is probably not the interface name.

Code: Select all

ifconfig -a

Code: Select all

wlx9cefd5fe43e9: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

Should have a newer style name like above.

TC

[stanhebben]

Pretty sure it is; below ifconfig -a

Code: Select all

enp1s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 24:1c:04:0a:92:7d  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 271  bytes 34545 (33.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 271  bytes 34545 (33.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.233.112.18  netmask 255.255.255.255  destination 0.0.0.0
        ppp  txqueuelen 3  (Point-to-Point Protocol)
        RX packets 13563  bytes 7098576 (6.7 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 14970  bytes 2171814 (2.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4098<BROADCAST,MULTICAST>  mtu 1500
        ether 00:e0:4c:b7:23:00  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[trinidad]

Just to be old school sure that there's not two configurations run like below:

Code: Select all

dbtspub@amdserver1:~$ networkctl | awk '/wlan/ {print $2}'
WARNING: systemd-networkd is not running, output will be incomplete.

wlx9cefd5fe43e9

[stanhebben]

Doesn't seem like it:

Code: Select all

WARNING: systemd-networkd is not running, output will be incomplete.

wlan0

[trinidad]

Looks ok. Commonly people setup systemd networkd and forget that ifup and ifdown don't work anymore.
Next questions is did you configure with NetworkManager, WICd, or manually with the CLI?

TC

[stanhebben]

For the wired and wifi interfaces, I configured /etc/network/interfaces and /etc/wpa_supplicant.conf and let the standard Debian services do their thing.

In case it matters, the 4G modem is managed by NetworkManager, but NetworkManager automatically excludes interfaces configured through /etc/network/interfaces so it shouldn't touch wifi.

Code: Select all

$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug enp1s0
iface enp1s0 inet dhcp

allow-hotplug wlan0
iface wlan0 inet dhcp
  wpa-conf /etc/wpa_supplicant.conf

Can't provide the contents of wpa_supplicant.conf, but it's certainly a valid file as it has already functioned properly (and still does on the other devices).

[Head_on_a_Stick]

Try

Code: Select all

# rfkill unblock all

https://packages.debian.org/stretch/rfkill

EDIT: you have the firmware-realtek package installed, right?

[stanhebben]

There are no rfkill blocks; so rfkill unblock all didn't have any effect. (I did try anyways, but it doesn't change anything)

Firmware-realtek is installed; but the respective files for this interface seemed not to be included (firmware-realtek is pretty old...). I ended up installing the respective files manually from the Linux Firmware Repository.

[stevepusser]

If you have a newer kernel than Debian provides, such as the 5.0 Liquorix you mention, you certainly should be trying the newer firmware packages from stretch-backports along with it! BTW, Liquorix has been building 5.1 kernels for a while, too.

[trinidad]

Sorry I got called away, but if you wish to continue let's check what connections you actually configured with Network Manager.

Code: Select all

$ nmcli -p -m multiline -f all con show

Also for future reference since systemd there is a naming protocol for such devices:

(1) Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
(2) Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
(3) Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
(4) Names incorporating the interfaces's MAC address (example: enx78e7d1ea46da)
(5) Classic, unpredictable kernel-native ethX naming (example: eth0)

Which follows an order:

(1) if that information from the firmware is applicable and available, falling back to:
(2) if that information from the firmware is applicable and available, falling back to:
(3) if applicable, falling back to:
(5) in all other cases.
Policy (4) is not used by default, but is available if the user chooses so.

Your firmware may be out of date as the others suggested, but you can manually use the IF MAC address method yourself.

TC

[stanhebben]

Continuing work on this issue now.

Below the output of nmcli connection list:

Code: Select all

===============================================================================
                      NetworkManager connection profiles
===============================================================================
NAME:                                   ModemConnection
UUID:                                   45d103c3-9894-4f79-b46f-804f9d0b310b
TYPE:                                   gsm
TIMESTAMP:                              1562301421
TIMESTAMP-REAL:                         Fri 05 Jul 2019 06:37:01 AM CEST
AUTOCONNECT:                            yes
AUTOCONNECT-PRIORITY:                   0
READONLY:                               no
DBUS-PATH:                              /org/freedesktop/NetworkManager/Settings/1
ACTIVE:                                 yes
DEVICE:                                 ttyUSB0
STATE:                                  activated
ACTIVE-PATH:                            /org/freedesktop/NetworkManager/ActiveConnection/4
SLAVE:                                  --
-------------------------------------------------------------------------------

Which I can confirm is indeed the connection setup for mobile.

Thanks for the information regarding the naming scheme. Considering there is only one wifi interface on this device, the naming scheme is not an issue, but does that indicate we're dealing with an old wifi driver or firmware version here? It seems like there is only this firmware version available, as it's the latest I could find (but that doesn't mean it's new...)

[trinidad]

Code: Select all

dbtspub@amdserver1:~$ cat /sys/class/net/wlx*/address 
9c:ef:d5:fe:43:e9

Please see if this command has a return with the system you have problems with. Also is the offending machine the one that is always on? If it is you should use hardware address scheme because the hardware will timeout (sometimes because of ISP, sometimes the particular chip itself) and wlan0 will sometimes need a reboot to address the hardware again when you use the kernel connection setting paradigm.

TC

[stanhebben]

That doesn't yield anything:

Code: Select all

cat: '/sys/class/net/wlx*/address': No such file or directory

This is indeed the machine that's always on. (yet so are its cousins) The problem appears to happen when they didn't connect to wifi for several days.

So you're saying using the hardware address scheme results in a more stable network interface setup?

• If a wlan reboot would "fix" something, what kind of reboot would it need? Ifdown / ifup clearly wasn't sufficient, and even the reboot command didn't fix it, only a full power cycle could fix the issue on the other device.
• How to properly enable hardware address names? I could test that to see if it helps.

[trinidad]

Not sure why you're showing the syntax change in the command, perhaps just the way your pasted the results. The command syntax as it appeared was correct for Debian stable which i am assuming we're discussing. Perhaps I'm wrong there.

Yes you are correct about powercycle. I meant shutdown and then boot again, not reboot.

Yes the saved hardware address, or any of the first four naming conventions can eliminate/improve upon the need to power cycle when WIFI times out because of your device or your ISP. What you are doing with this WIFI connection is probably outside the limitations of your particular device, and if it's a USB device hibernation and BIOS/ACPI/APIC and OEM values and settings come into play concerning the kernel if it was not native Linux/Unix hardware to begin with like system76 or Libre builds. All you need to configure the connection is the hardware address of the device and bring the interface up as wlx(address)... for Deb stable. Again this also calls into subject the firmware as well and the device's capabilities i/e does it need to be power cycled after long disconnects. Again wlan and eth are kernel produced addressing schemes which occur upon boot and subsequent device locating so timed out connections of that sort coupled to kernel induced hardware hibernation usually require power cycling to reset after connection failures.

Try:

Code: Select all

$ cat /sys/class/net/wlan*/address

TC

[stanhebben]

I didn't paste the command, only the output, perhaps hence the confusion... I'll make sure to include the command as well.

So here's the hardware address:

Code: Select all

$ cat /sys/class/net/wlan*/address
00:e0:4c:b7:23:00

[trinidad]

Bring up your interface as: wlx00e04cb72300. If it loads and works delete wlan0 settings. The difference will be that if a connection is dropped you will be able to reconnect without a shutdown and new boot. There are caveats like I mentioned before i/e the device hardware itself may require a power cycle to restart (which means because the machine is always on you would need to write a script to periodically timeout/disconnect the device and then reconnect it) A lot of these types of devices are not designed to operate for days on end ...even Roku TVs... and generally ISPs drop connections after long periods of inactivity... and most Windows 10 systems too.

TC

[stanhebben]

Alright, so I tried the following on that device:

Code: Select all

sudo ifup wlx00e04cb72300
ifup: unknown interface wlx00e04cb72300

That didn't work, so perhaps I had to configure my interface first by editing /etc/network/interfaces:

Code: Select all

$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug enp1s0
iface enp1s0 inet dhcp

allow-hotplug wlx00e04cb72300
iface wlx00e04cb72300 inet dhcp
  wpa-conf /etc/wpa_supplicant.conf

Code: Select all

$ sudo systemctl restart networking
$ sudo ifup wlx00e04cb72300
wpa_supplicant: /sbin/wpa_supplicant daemon failed to start
run-parts: /etc/network/if-pre-up.d/wpasupplicant exited with return code 1
ifup: failed to bring up wlx00e04cb72300
$ sudo journalctl | grep wpa_supplicant
Jul 06 20:16:37 debian wpa_supplicant[16865]: Successfully initialized wpa_supplicant
Jul 06 20:16:37 debian wpa_supplicant[16865]: Could not read interface wlx00e04cb72300 flags: No such device
Jul 06 20:16:37 debian wpa_supplicant[16865]: nl80211: Driver does not support authentication/association or connect commands
Jul 06 20:16:37 debian wpa_supplicant[16865]: nl80211: deinit ifname=wlx00e04cb72300 disabled_11b_rates=0
Jul 06 20:16:37 debian wpa_supplicant[16865]: Could not read interface wlx00e04cb72300 flags: No such device
Jul 06 20:16:37 debian wpa_supplicant[16865]: Could not read interface wlx00e04cb72300 flags: No such device
Jul 06 20:16:37 debian wpa_supplicant[16865]: WEXT: Could not set interface 'wlx00e04cb72300' UP
Jul 06 20:16:37 debian wpa_supplicant[16865]: wlx00e04cb72300: Failed to initialize driver interface

That doesn't seem to work. Tried to reboot the device (sudo reboot) but that didn't help either.

[trinidad]

Look to see if you have the file /lib/udev/rules.d/73-usb-net-by-mac.rules

TC

[stanhebben]

The file does exist and contains the following:

Code: Select all

$ cat /lib/udev/rules.d/73-usb-net-by-mac.rules
# Use MAC based names for network interfaces which are directly or indirectly
# on USB and have an universally administered (stable) MAC address (second bit
# is 0). Don't do this when ifnames is disabled via kernel command line or
# customizing/disabling 99-default.link (or previously 80-net-setup-link.rules).

IMPORT{cmdline}="net.ifnames"
ENV{net.ifnames}=="0", GOTO="usb_net_by_mac_end"

ACTION=="add", SUBSYSTEM=="net", SUBSYSTEMS=="usb", NAME=="", \
    ATTR{address}=="?[014589cd]:*", \
    TEST!="/etc/udev/rules.d/80-net-setup-link.rules", \
    TEST!="/etc/systemd/network/99-default.link", \
    IMPORT{builtin}="net_id", NAME="$env{ID_NET_NAME_MAC}"

LABEL="usb_net_by_mac_end"