Wifi usb-adapter works well, but looses ip address later in 10-20 hours

[Crossplatform Vlad]

Armbianmonitor:

http://ix.io/2K6O

After about 10-20 hours of normal work the IP address on USB wifi adapter disappears. Ethernet adapter connected to the same router works well at the same time.

 

System diagnosis information is collected when IP address is missing.

 

After re-plug USB-adapter into the same USB port or reboot, the IP address appears back.

Board: Orange PI PC,
WIFI: EDUP dual-band on 8811CU chip, built-in drivers
Image: 20.11.3 focal
Router: Keenetic Ultra

Previously I used built-in wifi of Orange PI+ and I didn't have similar problem.

Is the problem specific to the WIFI adapter?

[Werner]

Maybe. hard to tell. Generally spoken only WiFi dongles mentioned at the download page are tested and support: https://www.armbian.com/orange-pi-pc/

[Crossplatform Vlad]

The adapter is mentioned on the Tested 3rd party hardware

Interesting name of the loaded ko-driver: It is 8821cu, but adapter is 8811cu.

Is there 8811cu specific driver or 8821cu module covers 8811cu also?

 

[Werner]

I see.

Well the drivers for this family are 3rd party. You can see here how they are implemented:https://github.com/armbian/build/blob/cb5175ab365e5e5d19d79e83d1feac750d699d9a/lib/compilation-prepare.sh#L322-L349

 

[38069.844312] usb 5-1: new high-speed USB device number 2 using ehci-platform
[38070.001245] usb 5-1: New USB device found, idVendor=0bda, idProduct=c811, bcdDevice= 2.00
[38070.001255] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[38070.001260] usb 5-1: Product: 802.11ac NIC
[38070.001264] usb 5-1: Manufacturer: Realtek
[38070.001269] usb 5-1: SerialNumber: 123456
[38070.201537] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[38070.207924] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[38070.794555] usbcore: registered new interface driver rtl8821cu
[38070.836665] rtl8821cu 5-1:1.0 wlxe84e06870185: renamed from wlan0
[38076.694351] IPv6: ADDRCONF(NETDEV_CHANGE): wlxe84e06870185: link becomes ready

Odd. No disconnect message...

[guidol]

just an idea.... you could try to (because wlan0 is renamed to wlxe84e06870185 ) disable power-save for your wifi-device:

iw dev wlxe84e06870185 set power_save off

 

[Igor]

1 hour ago, Crossplatform Vlad said:

The adapter is mentioned on the Tested 3rd party hardware

That means it works. But we have no means nor resources to fix performance issues. Keeping them aligned / buildable with the current kernel is already troublesome enough.

 

8811AU driver might not cover your 8811CU which means you are using hardware that was not even tested ... not our fault. We just try to keep things operational the best we can.

[Crossplatform Vlad]

In addition to RTL8811CU the same problem with Tenda MT7601U. It is also listed in Tested 3rd party hardware. http://ix.io/2Kbs

Yesterday I plugged-in the board and in the morning IP address is missing:
 

Spoiler

 

root@focal-armv7l ~ $ ifconfig -a
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:ab:b4:b5:9c  txqueuelen 0  (Ethernet)
        RX packets 2909  bytes 1388694 (1.3 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4013  bytes 1596831 (1.5 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.186  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::b3b3:4d9d:b29b:37f4  prefixlen 64  scopeid 0x20<link>
        ether 02:81:48:20:8d:27  txqueuelen 1000  (Ethernet)
        RX packets 165082  bytes 13010757 (13.0 MB)
        RX errors 0  dropped 704  overruns 0  frame 0
        TX packets 19293  bytes 2994564 (2.9 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 38

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 165  bytes 27786 (27.7 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 165  bytes 27786 (27.7 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vethc7899a0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 86:3c:fe:28:59:18  txqueuelen 0  (Ethernet)
        RX packets 2909  bytes 1429420 (1.4 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4013  bytes 1596831 (1.5 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlx502b73c0d63f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::e2:6214:e7e6:a845  prefixlen 64  scopeid 0x20<link>
        ether 50:2b:73:c0:d6:3f  txqueuelen 1000  (Ethernet)
        RX packets 70096  bytes 16697816 (16.6 MB)
        RX errors 0  dropped 571  overruns 0  frame 0
        TX packets 3544  bytes 462287 (462.2 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@focal-armv7l ~ $ iwconfig
lo        no wireless extensions.

eth0      no wireless extensions.

wlx502b73c0d63f  IEEE 802.11  ESSID:"Keenetic"
          Mode:Managed  Frequency:2.412 GHz  Access Point: 50:FF:20:2F:05:CA
          Bit Rate=135 Mb/s   Tx-Power=20 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=70/70  Signal level=-25 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:748   Missed beacon:0

docker0   no wireless extensions.

vethc7899a0  no wireless extensions.

 

 

By default power management is turned off for both USB adapter.
 

I had Orange PI+ with built-in wifi about 2 years ago and didn't have such trouble with on-board wifi. Something shifted during these two years in network manager?

P.S. Just found out that IPv6 still works. 

 

[Igor]

2 hours ago, Crossplatform Vlad said:

Something shifted during these two years in network manager?

There are certainly troubles associated with Network Manager (we didn't build), so there is little what we can do about. Which is why we keep old fashion networking as a failover. That you should try first.