(stay in USB2 mode) Silently fails on Raspberry Pi 4

[ViRb3]

• Device: Raspberry Pi 4 8GB
• OS: Ubuntu 22.04
• Driver options:
  • options 88x2bu rtw_power_mgnt=0 rtw_ips_mode=0 rtw_enusbss=0 rtw_switch_usb_mode=1
• WiFi specs:
  • WPA 2 Personal
  • 5GHz

I've found the options above necessary to give me the best throughput. Apart from that, the driver works great for some time. I am downloading ~200GB of data, and it works for maybe the first 120GB. After that, I silently lose connectivity. Since this is a headless server, I had to unplug and replug the USB cable to make it work again. When I check dmesg, the only log I can see is of the device getting reconnected when I physically do it. Nothing at all regarding the failure otherwise. I ended up having to write the following cron job:

*/1 * * * * /root/wifi.sh

#!/bin/bash

for _ in 1 2 3 4 5; do
    if ping -c 1 "1.1.1.1" >/dev/null 2>&1; then
        exit 0
    fi
    sleep 5
done

usbreset "802.11ac NIC"
date >>/root/wifi.log

Any ideas on how to fix the issue in the first place? Anybody else experiencing it? Many thanks.

Some more debug info:

uname -a

Linux ubuntu 5.15.0-1012-raspi #14-Ubuntu SMP PREEMPT Fri Jun 24 13:10:28 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux

mokutil --sb-state

EFI variables are not supported on this system

lsusb

Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 003: ID 2357:0115 TP-Link Archer T4U ver.3 Bus 002 Device 002: ID 05e3:0626 Genesys Logic, Inc. USB3.1 Hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 05e3:0610 Genesys Logic, Inc. Hub Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

rfkill list all

1: phy1: Wireless LAN Soft blocked: no Hard blocked: no 2: hci0: Bluetooth Soft blocked: no Hard blocked: no 4: phy3: Wireless LAN Soft blocked: no Hard blocked: no

dkms status

rtl88x2bu/5.13.1, 5.15.0-1012-raspi, aarch64: installed

ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff 4: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff 78: wlxxxxxxxxxxxxx: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet 192.168.1.101/24 metric 600 brd 192.168.1.255 scope global dynamic wlxxxxxxxxxxxxx valid_lft 85707sec preferred_lft 85707sec inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope global dynamic mngtmpaddr noprefixroute valid_lft 86263sec preferred_lft 3463sec inet6 xxxx::xxxx:xxxx:xxxx:xxxx/64 scope link valid_lft forever preferred_lft forever

[morrownr]

Hi @ViRb3

In the FAQ there is a writeup about seeing this with AP mode with the RasPi4B. It also happens with managed mode. This problem is very specific to the RasPi4B. I suspect the USB3 chipset on the 4B is faulty or there is an engineering issue. The only known workaround is to keep the driver in USB2 mode:

rtw_switch_usb_mode=2 or rtw_switch_usb_mode=0

This happens to one degree or another with all usb wifi adapters and the Pi4B if using USB3 and 5 GHz.

Regards,

Nick

[ViRb3]

Oh no... I just ordered the COMFAST CF-953AX as per your recommendations, thinking this was a dongle/driver issue. I guess we'll find out. Thanks for the heads up though!

For context I have a powered hub with 3A/5V, that is the:

Bus 002 Device 002: ID 05e3:0626 Genesys Logic, Inc. USB3.1 Hub

Without the hub, I was getting cutouts due to current insufficiency. No other device on the same hub drops when the WiFi dies though, so I doubt it's a hub problem.

[morrownr]

Oh no... I just ordered the COMFAST CF-953AX as per your recommendations, thinking this was a dongle/driver issue. I guess we'll find out. Thanks for the heads up though!

This issue is most apparent on adapters with the 8812bu chipset. Most other Realtek based adapters may, at times show the issue, but it is less of an issue and many folks may not notice it. The 8812au adapter very rarely experiences the issue. Mediatek based adapters do tend to do better than Realtek adapters with this issue.

There are some tips to help:

• don't use powered hubs in an AP setup. Plug the adapter directly into one of the Pi4B ports.
• make sure you are not using more power than the Pi4B usb subsystem can provide. (the limit is 1200 mA)

The CF-953AX uses the new mt7921au chipset and my reading indicates that it uses less power than previous generations which may help. Also, if you are going to use 6 GHz channels, this issue may not be a problem at all. You have probably been reading the long thread over in USB-WiFi where people are sending in reports on the cf-953ax. So far most reports are positive. I'm hoping there is no problem with the Pi4B's but this is a problem with the Pi4B so please give us a report when you get your adapter.

For context I have a powered hub with 3A/5V, that is the: Bus 002 Device 002: ID 05e3:0626 Genesys Logic, Inc. USB3.1 Hub

Oh. Recommend you test without the powered hub connected. Powered hubs have a long history of not working well with RasPi's. I can discuss more in-depth if you want.

Without the hub, I was getting cutouts due to current insufficiency.

Let me suggest you start an issue over in USB-WiFi so we can get some additional eyes on the issue. One of the first things I will ask you when you start the new issue is to list all of the usb devices that are connected to the Pi.

No other device on the same hub drops when the WiFi dies though, so I doubt it's a hub problem.

Been there, seen this many times. See you over in the other thread.

Nick

[ViRb3]

Hello and sorry for the radio silence, I was away for a while. In the meantime, I can confirm that when forcing the WiFI adapter to USB2 mode, the Raspberry Pi has been running 24/7 with no internet cuts (ping google every 1 minute) since my last post (16 days!). My COMFAST arrived, so I will see you in the other thread after some initial testing!

[morrownr]

Hi @ViRb3

Your experience with the RasPi4B staying stable when the adapter is in USB2 mode is normal. For most people, that is more than fast enough but for us race car drivers, we have to have more.

I have good news also. I found a source for a CF-951AX and it should arrive early this coming week. I've been discussing the issue of how to update the RasPiOS to a 5.19 or later kernel so as to test. See issue 101 in USB-WiFi:

https://github.com/morrownr/USB-WiFi