Beware - Documentation - tp-link AXE5400 is a Realtek NOT a Mediatek Chip Unit

[reubenfarrelly]

According to the USB_WiFi_Adapters_that_are_supported_with_Linux_in-kernel-drivers document:

AXE5400 - USB3.0 - 2.4 GHz, 5 GHz and 6 GHz (WiFi 7) chipset - Mediatek mt7925 - supported in-kernel since Linux kernel 6.7 (2024) No adapters with this chipset are available to consumers yet. Expect adapters to be available at some point in 2024. If you see an adapter that uses the mt7925 chipset, please post in Issues.

So I thought I'd go ahead and purchase a tp-link AXE5400 Wi-Fi 6E Wireless USB Adaptor from Amazon in the hopes of obtaining a very decent MediaTek mt7925 based unit to use on my Raspberry Pi. I could not definitively find anything in any official documentation which suggests what chip it ran though.

But after attempting to use it I realised:

[ 156.401251] usb 1-1: New USB device found, idVendor=35bc, idProduct=0102, bcdDevice= 0.00 [ 156.401258] usb 1-1: Product: 802.11ax WLAN Adapter [ 156.401261] usb 1-1: Manufacturer: Realtek

So it actually has a RealTek chip - I believe it requires the rtw8852cu driver and not a Mediatek.

I now have a tp-link AXE5400, AX1800 and AX55-Nano all with Realtek chips, and all available for testing if you can use these for anything @morrownr :)

My Netgear AX3000 is the only decent MediaTek unit I can get my hands on, but it seems to suffer from latency issues.

[morrownr]

@reubenfarrelly

I am so sorry to hear this. I will modify the wording in the document this morning to make it very clear that even though the new driver for mt7925 is in the kernel as of 6.7, no adapters are on the market yet. AXE5400 is the class of adapter and speed of overall speed capability such as what link speeds the adapter is capable of in the 3 bands. It is capable of 2400 Mbps in the 6 GHz band and 2400 Mbps in the 5 GHz band and 600 Mbps in the 2.4 GHz band. Add the 3 numbers and you get 5400.

My Netgear AX3000 is the only decent MediaTek unit I can get my hands on,

The Netgear AX3000 is a router. Did you mean Netgear AX8000? If so, let's see if we can figure out why the performance is not as fast as you would like.

Do you mind if I ask where you are located?

@morrownr

[reubenfarrelly]

@morrownr I'm located in Australia.

The adaptor I have is this one: https://www.netgear.com/au/home/wifi/adapters/a8000/ - AXE3000 I don't know who runs the marketing there but the naming/model numbers are a bit of a confusing mess when the only difference between the client and router is one single letter!

In terms of performance, this is what pings look like:

PING temp-3 (2404:xxx:4626:12::72) 56 data bytes
64 bytes from 2404:xxx:4626:12::72: icmp_seq=1 ttl=63 time=103 ms
64 bytes from 2404:xxxx:4626:12::72: icmp_seq=2 ttl=63 time=23.4 ms
64 bytes from 2404:xxxx:4626:12::72: icmp_seq=3 ttl=63 time=44.3 ms
64 bytes from 2404:xxxx:4626:12::72: icmp_seq=4 ttl=63 time=69.0 ms
64 bytes from 2404:xxxx:4626:12::72: icmp_seq=5 ttl=63 time=89.9 ms
64 bytes from 2404:xxxx:4626:12::72: icmp_seq=6 ttl=63 time=6.55 ms
64 bytes from 2404:xxxx:4626:12::72: icmp_seq=7 ttl=63 time=35.6 ms
64 bytes from 2404:xxxx:4626:12::72: icmp_seq=8 ttl=63 time=54.6 ms
64 bytes from 2404:xxxx:4626:12::72: icmp_seq=9 ttl=63 time=79.0 ms
64 bytes from 2404:xxxx:4626:12::72: icmp_seq=10 ttl=63 time=101 ms
64 bytes from 2404:xxxx:4626:12::72: icmp_seq=11 ttl=63 time=22.4 ms
64 bytes from 2404:xxxx:4626:12::72: icmp_seq=12 ttl=63 time=44.1 ms
...
^C
--- temp-3 ping statistics ---
102 packets transmitted, 102 received, 0% packet loss, time 101143ms
rtt min/avg/max/mdev = 1.654/54.854/114.406/35.314 ms
thunderstorm ~ # 

So no actual loss, but just a lot of jitter. Same result for IPv4 as IPv6. Compare this to the onboard Wifi on the Pi in the same location which would get almost every ping under 5ms.

From the AP side:

Signal Strength: -40 dBm Signal Quality: 59 dB
Connection Speed: 516 Mbps
Ch BW(Negotiated/Capable): 40 MHz/80 MHz

From the client side:

root@temp-3:~# iw dev wlan0 link
Connected to 6c:71:0d:ea:bc:4d (on wlan0)
        SSID: REUB-PSK
        freq: 5500
        RX: 11188422 bytes (101609 packets)
        TX: 3435320 bytes (27707 packets)
        signal: -46 dBm
        rx bitrate: 309.7 MBit/s 40MHz HE-MCS 6 HE-NSS 2 HE-GI 0 HE-DCM 0
        tx bitrate: 516.0 MBit/s 40MHz HE-MCS 10 HE-NSS 2 HE-GI 0 HE-DCM 0
        bss flags:      short-slot-time
        dtim period:    1
        beacon int:     100
root@temp-3:~# 

Firmware slightly more up to date than ships with the Pi as a base:

[   11.046600] mt7921u 2-1:1.0: HW/SW Version: 0x8a108a10, Build Time: 20231109190918a
[   11.302936] mt7921u 2-1:1.0: WM Firmware Version: ____010000, Build Time: 20231109190959

I'm running a few modern Cisco Enterprise APs at home - the one that the client is connected to right now is a Cisco 9130 which supports 2.4/5 (and I have a couple of APs which also support 6GHz but had the same issue when connected to those).

[morrownr]

I modified the wording in the Plug and Play List to hopefully make it more clear that no adapters with the mt7925 chipset are available so far. The driver is in the kernel but no adapters on the market.

I'm located in Australia.

Cool.

I don't know who runs the marketing there but the naming/model numbers are a bit of a confusing mess

Yes, it can be a challenge. So, your adapter is the Netgear A8000 which has the mt7921au chipset. It is a tri-band adapter capable of 80 MHz channel width in the 5 and 6 GHz bands. The reviews and reports I have seen from users say this is a good adapter.

Let's work on that jitter.

[ 11.302936] mt7921u 2-1:1.0: WM Firmware Version: ____010000, Build Time: 20231109190959

There is now newer firmware. You know where the Firmware update guide is on the Main Menu? Section 3 is the one you are looking for.

What distro are you using?

What kernel is the distro using?

What hardware is in use as the client? I think mentioned a RasPi but can you clarify the details?

[reubenfarrelly]

I upgraded firmware yesterday - looks like just new out!

[   11.463862] usbcore: registered new interface driver mt7921u
[   11.490896] mt7921u 2-1:1.0: HW/SW Version: 0x8a108a10, Build Time: 20240219110958a
[   11.750133] mt7921u 2-1:1.0: WM Firmware Version: ____010000, Build Time: 20240219111038

Latency is still all over the place though:

64 bytes from 2404:e80:4626:12::72: icmp_seq=1 ttl=63 time=101 ms
64 bytes from 2404:e80:4626:12::72: icmp_seq=2 ttl=63 time=21.5 ms
64 bytes from 2404:e80:4626:12::72: icmp_seq=3 ttl=63 time=44.6 ms
64 bytes from 2404:e80:4626:12::72: icmp_seq=4 ttl=63 time=66.7 ms
64 bytes from 2404:e80:4626:12::72: icmp_seq=5 ttl=63 time=88.5 ms
64 bytes from 2404:e80:4626:12::72: icmp_seq=6 ttl=63 time=111 ms
64 bytes from 2404:e80:4626:12::72: icmp_seq=7 ttl=63 time=30.7 ms
64 bytes from 2404:e80:4626:12::72: icmp_seq=8 ttl=63 time=52.8 ms
64 bytes from 2404:e80:4626:12::72: icmp_seq=9 ttl=63 time=75.1 ms
64 bytes from 2404:e80:4626:12::72: icmp_seq=10 ttl=63 time=98.0 ms
64 bytes from 2404:e80:4626:12::72: icmp_seq=11 ttl=63 time=18.1 ms

Distro: Raspberry Pi OS (latest and fully up to date, 64 bit, minimal/headless)

Kernel: Linux temp-3 6.6.21-v8-16k+ #1741 SMP PREEMPT Fri Mar 8 13:44:12 GMT 2024 aarch64 GNU/Linux I had to upgrade to this (using rpi-update) to have support for WPA3 and the other wireless things I was testing.

Hardware: RPI-5/8G.

Load is almost zero: 11:05:22 up 3:04, 1 user, load average: 0.07, 0.04, 0.00

I had the same problem both with the unit in its current location as well as when it was on my desk, 2m away from another one of my APs. My controller is telling me that the AP is seeing no appreciable noise or interference on Ch100 which is the one that the wireless module is talking to the AP on (currently 2% channel utilisation as well).

[morrownr]

I don't have a Pi5B yet, only a Pi4B and Pi3B. I've seen many problems with the usb3 support in the Pi4B.

Run the following and tell me the result:

grep [[:alnum:]] /sys/module/mt76_usb/parameters/*

[reubenfarrelly]

root@temp-3:~# grep [[:alnum:]] /sys/module/mt76_usb/parameters/*
N
root@temp-3:~# 

[morrownr]

That means Scatter-Gather is on. Let's see turning it off helps:

Open a terminal (Ctrl + Alt + t)

sudo nano /etc/modprobe.d/mt76_usb.conf

add:

options mt76_usb disable_usb_sg=1

Save the file Reboot Retest

[reubenfarrelly]

Hard to say if this has improved things at all - certainly not the smoking gun:

root@temp-3:~# cat /etc/modprobe.d/mt76_usb.conf 
options mt76_usb disable_usb_sg=1
root@temp-3:~# 

rebooted

root@temp-3:~# grep [[:alnum:]] /sys/module/mt76_usb/parameters/*
Y
root@temp-3:~#

thunderstorm ~ # ping 192.168.12.72
PING temp-3 (192.168.12.72) 56(84) bytes of data.
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=1 ttl=63 time=101 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=2 ttl=63 time=25.0 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=3 ttl=63 time=46.5 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=4 ttl=63 time=69.6 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=5 ttl=63 time=91.3 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=6 ttl=63 time=10.6 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=7 ttl=63 time=1.81 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=8 ttl=63 time=1.88 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=9 ttl=63 time=1.94 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=10 ttl=63 time=155 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=11 ttl=63 time=123 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=12 ttl=63 time=50.3 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=13 ttl=63 time=6.41 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=14 ttl=63 time=1.79 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=15 ttl=63 time=105 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=16 ttl=63 time=1.76 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=17 ttl=63 time=6.26 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=18 ttl=63 time=79.7 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=19 ttl=63 time=3.56 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=20 ttl=63 time=22.6 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=21 ttl=63 time=3.87 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=22 ttl=63 time=66.3 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=23 ttl=63 time=89.1 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=24 ttl=63 time=113 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=25 ttl=63 time=31.9 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=26 ttl=63 time=54.9 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=27 ttl=63 time=75.4 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=28 ttl=63 time=99.5 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=29 ttl=63 time=19.3 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=30 ttl=63 time=40.7 ms
64 bytes from temp-3.ad.reub.net (192.168.12.72): icmp_seq=31 ttl=63 time=62.6 ms
^C
--- temp-3 ping statistics ---
31 packets transmitted, 31 received, 0% packet loss, time 30042ms
rtt min/avg/max/mdev = 1.763/50.358/154.960/43.232 ms
thunderstorm ~ # 

[morrownr]

I have an adapter with the same chipset. It is an Alfa AXML.

$ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=8.54 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=3.71 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=4.68 ms 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=4.61 ms 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=5.19 ms 64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=4.30 ms 64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=4.33 ms 64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=4.24 ms 64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=4.30 ms 64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=5.18 ms 64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=4.31 ms 64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=4.29 ms 64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=4.30 ms 64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=4.30 ms 64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=4.68 ms 64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=4.30 ms 64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=4.27 ms 64 bytes from 192.168.1.1: icmp_seq=18 ttl=64 time=4.05 ms 64 bytes from 192.168.1.1: icmp_seq=19 ttl=64 time=4.31 ms 64 bytes from 192.168.1.1: icmp_seq=20 ttl=64 time=4.30 ms 64 bytes from 192.168.1.1: icmp_seq=21 ttl=64 time=4.30 ms 64 bytes from 192.168.1.1: icmp_seq=22 ttl=64 time=4.30 ms 64 bytes from 192.168.1.1: icmp_seq=23 ttl=64 time=4.31 ms ^C --- 192.168.1.1 ping statistics --- 23 packets transmitted, 23 received, 0% packet loss, time 22034ms rtt min/avg/max/mdev = 3.707/4.568/8.543/0.901 ms

I pinged my main wifi router. What are you pinging?

[morrownr]

I thought would check with Google:

$ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=59 time=19.2 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=59 time=19.7 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=59 time=19.1 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=59 time=21.0 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=59 time=19.7 ms 64 bytes from 8.8.8.8: icmp_seq=6 ttl=59 time=21.1 ms 64 bytes from 8.8.8.8: icmp_seq=7 ttl=59 time=18.2 ms 64 bytes from 8.8.8.8: icmp_seq=8 ttl=59 time=20.7 ms 64 bytes from 8.8.8.8: icmp_seq=9 ttl=59 time=21.3 ms 64 bytes from 8.8.8.8: icmp_seq=10 ttl=59 time=18.0 ms 64 bytes from 8.8.8.8: icmp_seq=11 ttl=59 time=19.9 ms 64 bytes from 8.8.8.8: icmp_seq=12 ttl=59 time=19.8 ms 64 bytes from 8.8.8.8: icmp_seq=13 ttl=59 time=20.8 ms 64 bytes from 8.8.8.8: icmp_seq=14 ttl=59 time=20.3 ms 64 bytes from 8.8.8.8: icmp_seq=15 ttl=59 time=19.7 ms 64 bytes from 8.8.8.8: icmp_seq=16 ttl=59 time=19.6 ms 64 bytes from 8.8.8.8: icmp_seq=17 ttl=59 time=24.0 ms 64 bytes from 8.8.8.8: icmp_seq=18 ttl=59 time=20.2 ms 64 bytes from 8.8.8.8: icmp_seq=19 ttl=59 time=19.3 ms 64 bytes from 8.8.8.8: icmp_seq=20 ttl=59 time=19.4 ms 64 bytes from 8.8.8.8: icmp_seq=21 ttl=59 time=18.8 ms 64 bytes from 8.8.8.8: icmp_seq=22 ttl=59 time=20.3 ms 64 bytes from 8.8.8.8: icmp_seq=23 ttl=59 time=19.3 ms 64 bytes from 8.8.8.8: icmp_seq=24 ttl=59 time=19.9 ms 64 bytes from 8.8.8.8: icmp_seq=25 ttl=59 time=19.6 ms ^C --- 8.8.8.8 ping statistics --- 25 packets transmitted, 25 received, 0% packet loss, time 24042ms rtt min/avg/max/mdev = 18.005/19.952/24.026/1.158 ms

Again, very very low jitter. My wifi router is on DFS channel 116. There are no other APs on the channel so it is clear air.

[reubenfarrelly]

Pinging from my main Linux box, through a core switch and straight onto the VLAN that the wireless client is on. Latency through the switch is >1ms (it's a 10G Cisco...).

Food for thought - onboard RPi5 wifi - same SSID, same PSK, same configuration, same everything including joined to the same AP on the same channel:

thunderstorm ~ # ping -4 192.168.12.101
PING 192.168.12.101 (192.168.12.101) 56(84) bytes of data.
64 bytes from 192.168.12.101: icmp_seq=1 ttl=63 time=94.9 ms
64 bytes from 192.168.12.101: icmp_seq=2 ttl=63 time=8.19 ms
64 bytes from 192.168.12.101: icmp_seq=3 ttl=63 time=6.15 ms
64 bytes from 192.168.12.101: icmp_seq=4 ttl=63 time=5.96 ms
64 bytes from 192.168.12.101: icmp_seq=5 ttl=63 time=5.87 ms
64 bytes from 192.168.12.101: icmp_seq=6 ttl=63 time=6.04 ms
64 bytes from 192.168.12.101: icmp_seq=7 ttl=63 time=6.08 ms
64 bytes from 192.168.12.101: icmp_seq=8 ttl=63 time=5.98 ms
64 bytes from 192.168.12.101: icmp_seq=9 ttl=63 time=5.97 ms
64 bytes from 192.168.12.101: icmp_seq=10 ttl=63 time=5.94 ms
64 bytes from 192.168.12.101: icmp_seq=11 ttl=63 time=6.42 ms
64 bytes from 192.168.12.101: icmp_seq=12 ttl=63 time=5.96 ms
64 bytes from 192.168.12.101: icmp_seq=13 ttl=63 time=6.01 ms
64 bytes from 192.168.12.101: icmp_seq=14 ttl=63 time=5.42 ms
64 bytes from 192.168.12.101: icmp_seq=15 ttl=63 time=5.61 ms
64 bytes from 192.168.12.101: icmp_seq=16 ttl=63 time=6.14 ms
64 bytes from 192.168.12.101: icmp_seq=17 ttl=63 time=6.01 ms
64 bytes from 192.168.12.101: icmp_seq=18 ttl=63 time=5.89 ms
64 bytes from 192.168.12.101: icmp_seq=19 ttl=63 time=6.05 ms
64 bytes from 192.168.12.101: icmp_seq=20 ttl=63 time=6.12 ms
64 bytes from 192.168.12.101: icmp_seq=21 ttl=63 time=6.16 ms
64 bytes from 192.168.12.101: icmp_seq=22 ttl=63 time=6.03 ms
64 bytes from 192.168.12.101: icmp_seq=23 ttl=63 time=6.11 ms
64 bytes from 192.168.12.101: icmp_seq=24 ttl=63 time=5.72 ms
64 bytes from 192.168.12.101: icmp_seq=25 ttl=63 time=6.19 ms
64 bytes from 192.168.12.101: icmp_seq=26 ttl=63 time=3.09 ms
64 bytes from 192.168.12.101: icmp_seq=27 ttl=63 time=5.45 ms
64 bytes from 192.168.12.101: icmp_seq=28 ttl=63 time=6.01 ms
64 bytes from 192.168.12.101: icmp_seq=29 ttl=63 time=5.85 ms
64 bytes from 192.168.12.101: icmp_seq=30 ttl=63 time=5.00 ms
64 bytes from 192.168.12.101: icmp_seq=31 ttl=63 time=4.98 ms
64 bytes from 192.168.12.101: icmp_seq=32 ttl=63 time=5.11 ms
64 bytes from 192.168.12.101: icmp_seq=33 ttl=63 time=1.93 ms
64 bytes from 192.168.12.101: icmp_seq=34 ttl=63 time=4.95 ms
64 bytes from 192.168.12.101: icmp_seq=35 ttl=63 time=6.35 ms
64 bytes from 192.168.12.101: icmp_seq=36 ttl=63 time=5.04 ms
64 bytes from 192.168.12.101: icmp_seq=37 ttl=63 time=4.99 ms
64 bytes from 192.168.12.101: icmp_seq=38 ttl=63 time=5.04 ms
64 bytes from 192.168.12.101: icmp_seq=39 ttl=63 time=11.5 ms
64 bytes from 192.168.12.101: icmp_seq=40 ttl=63 time=5.65 ms
64 bytes from 192.168.12.101: icmp_seq=41 ttl=63 time=4.98 ms
64 bytes from 192.168.12.101: icmp_seq=42 ttl=63 time=5.16 ms
^C
--- 192.168.12.101 ping statistics ---
42 packets transmitted, 42 received, 0% packet loss, time 41057ms
rtt min/avg/max/mdev = 1.934/7.905/94.932/13.650 ms
thunderstorm ~ #

And now the mt7921:

thunderstorm ~ # ping -4 192.168.12.72
PING 192.168.12.72 (192.168.12.72) 56(84) bytes of data.
64 bytes from 192.168.12.72: icmp_seq=1 ttl=63 time=99.3 ms
64 bytes from 192.168.12.72: icmp_seq=2 ttl=63 time=6.01 ms
64 bytes from 192.168.12.72: icmp_seq=3 ttl=63 time=41.7 ms
64 bytes from 192.168.12.72: icmp_seq=4 ttl=63 time=63.8 ms
64 bytes from 192.168.12.72: icmp_seq=5 ttl=63 time=83.4 ms
64 bytes from 192.168.12.72: icmp_seq=6 ttl=63 time=109 ms
64 bytes from 192.168.12.72: icmp_seq=7 ttl=63 time=29.0 ms
64 bytes from 192.168.12.72: icmp_seq=8 ttl=63 time=52.3 ms
64 bytes from 192.168.12.72: icmp_seq=9 ttl=63 time=83.1 ms
64 bytes from 192.168.12.72: icmp_seq=10 ttl=63 time=98.1 ms
64 bytes from 192.168.12.72: icmp_seq=11 ttl=63 time=18.3 ms
64 bytes from 192.168.12.72: icmp_seq=12 ttl=63 time=40.9 ms
64 bytes from 192.168.12.72: icmp_seq=13 ttl=63 time=63.0 ms
64 bytes from 192.168.12.72: icmp_seq=14 ttl=63 time=86.1 ms
64 bytes from 192.168.12.72: icmp_seq=15 ttl=63 time=6.15 ms
64 bytes from 192.168.12.72: icmp_seq=16 ttl=63 time=26.5 ms
64 bytes from 192.168.12.72: icmp_seq=17 ttl=63 time=51.9 ms
64 bytes from 192.168.12.72: icmp_seq=18 ttl=63 time=5.97 ms
64 bytes from 192.168.12.72: icmp_seq=19 ttl=63 time=97.1 ms
64 bytes from 192.168.12.72: icmp_seq=20 ttl=63 time=13.7 ms
64 bytes from 192.168.12.72: icmp_seq=21 ttl=63 time=39.7 ms
64 bytes from 192.168.12.72: icmp_seq=22 ttl=63 time=62.0 ms
64 bytes from 192.168.12.72: icmp_seq=23 ttl=63 time=84.9 ms
64 bytes from 192.168.12.72: icmp_seq=24 ttl=63 time=108 ms
64 bytes from 192.168.12.72: icmp_seq=25 ttl=63 time=27.6 ms
64 bytes from 192.168.12.72: icmp_seq=26 ttl=63 time=50.3 ms
64 bytes from 192.168.12.72: icmp_seq=27 ttl=63 time=6.89 ms
64 bytes from 192.168.12.72: icmp_seq=28 ttl=63 time=94.1 ms
64 bytes from 192.168.12.72: icmp_seq=29 ttl=63 time=15.1 ms
64 bytes from 192.168.12.72: icmp_seq=30 ttl=63 time=39.8 ms
64 bytes from 192.168.12.72: icmp_seq=31 ttl=63 time=62.6 ms
64 bytes from 192.168.12.72: icmp_seq=32 ttl=63 time=82.8 ms
64 bytes from 192.168.12.72: icmp_seq=33 ttl=63 time=105 ms
64 bytes from 192.168.12.72: icmp_seq=34 ttl=63 time=24.6 ms
64 bytes from 192.168.12.72: icmp_seq=35 ttl=63 time=47.2 ms
64 bytes from 192.168.12.72: icmp_seq=36 ttl=63 time=69.3 ms
64 bytes from 192.168.12.72: icmp_seq=37 ttl=63 time=89.7 ms
64 bytes from 192.168.12.72: icmp_seq=38 ttl=63 time=114 ms
64 bytes from 192.168.12.72: icmp_seq=39 ttl=63 time=36.4 ms
64 bytes from 192.168.12.72: icmp_seq=40 ttl=63 time=58.1 ms
64 bytes from 192.168.12.72: icmp_seq=41 ttl=63 time=81.2 ms
64 bytes from 192.168.12.72: icmp_seq=42 ttl=63 time=104 ms
64 bytes from 192.168.12.72: icmp_seq=43 ttl=63 time=23.4 ms
^C
--- 192.168.12.72 ping statistics ---
43 packets transmitted, 43 received, 0% packet loss, time 42059ms
rtt min/avg/max/mdev = 5.970/58.182/114.008/33.053 ms
thunderstorm ~ # 

So a substantial change in performance just by changing from onboard to the external mediatek.

In case you are wondering why I'm not just using the onboard - well I'm trying to standardise on wireless network settings (and learn a few things while as I go) which includes having WPA3 support without mixed mode, and the onboard Wifi just doesn't work well with WPA3/SAE yet (although I know it's coming... but it wasn't when I started investigating). So my choices are WPA3 with lots of jitter or WPA2 with a great latency.

[morrownr]

onboard RPi5 wifi - same SSID, same PSK, same configuration, same everything including joined to the same AP on the same channel:

That still leaves things that are not the same. The RasPi5B is capable of WiFi 5 and the mt7921 (Netgear A8000) is capable of WiFi 6. Could this be a factor? If the AP is set to WiFi 6, try limiting it to WiFi 5 (AC) and do the test. Also, The onboard wifi is going through which bus? Try the mt7921 in a usb2 port and see if there is a difference. Try some thoughput tests. I'd like to see the results if you don't mind.

well I'm trying to standardise on wireless network settings (and learn a few things while as I go) which includes having WPA3 support without mixed mode, and the onboard Wifi just doesn't work well with WPA3/SAE yet (although I know it's coming...

Oh, the first thing I do when burning a new sd is turn off the onboard wifi. All I have to see is the name Broadcom and I run the opposite direction. Broadcom has NEVER had good Linux support. RasPi made a very bad decision to work with Broadcom for the Pi's.

I forgot to mention that the test results I posted earlier were from a x86_64 client with my mt7921 based usb wifi adapter connected. My Pi4B is busy doing another type of test and now is not a good time to interrupt but I can at some point if needed. The guy that did the review for your adapter in the Plug and Play List mentioned low latency. His github address is there if you want to bring him into the conversation.

@morrownr

[reubenfarrelly]

I've tried in a USB2 port on the Pi - no difference to latency.

Also just tried on Windows 11 physically in the same location as the Pi is right now:

C:\Users\reuben>ping -t 192.168.12.1

Pinging 192.168.12.1 with 32 bytes of data:
Reply from 192.168.12.1: bytes=32 time=4ms TTL=254
Reply from 192.168.12.1: bytes=32 time=9ms TTL=254
Reply from 192.168.12.1: bytes=32 time=4ms TTL=254
Reply from 192.168.12.1: bytes=32 time=5ms TTL=254
Reply from 192.168.12.1: bytes=32 time=3ms TTL=254
Reply from 192.168.12.1: bytes=32 time=4ms TTL=254
Reply from 192.168.12.1: bytes=32 time=3ms TTL=254
Reply from 192.168.12.1: bytes=32 time=3ms TTL=254
Reply from 192.168.12.1: bytes=32 time=4ms TTL=254
Reply from 192.168.12.1: bytes=32 time=4ms TTL=254
Reply from 192.168.12.1: bytes=32 time=4ms TTL=254
Reply from 192.168.12.1: bytes=32 time=6ms TTL=254
Reply from 192.168.12.1: bytes=32 time=4ms TTL=254
Reply from 192.168.12.1: bytes=32 time=3ms TTL=254
Reply from 192.168.12.1: bytes=32 time=4ms TTL=254
Reply from 192.168.12.1: bytes=32 time=3ms TTL=254
Reply from 192.168.12.1: bytes=32 time=3ms TTL=254
Reply from 192.168.12.1: bytes=32 time=5ms TTL=254
Reply from 192.168.12.1: bytes=32 time=4ms TTL=254
Reply from 192.168.12.1: bytes=32 time=5ms TTL=254
Reply from 192.168.12.1: bytes=32 time=5ms TTL=254
Reply from 192.168.12.1: bytes=32 time=3ms TTL=254
Reply from 192.168.12.1: bytes=32 time=4ms TTL=254
Reply from 192.168.12.1: bytes=32 time=3ms TTL=254
Reply from 192.168.12.1: bytes=32 time=4ms TTL=254
Reply from 192.168.12.1: bytes=32 time=3ms TTL=254
Reply from 192.168.12.1: bytes=32 time=4ms TTL=254
Reply from 192.168.12.1: bytes=32 time=4ms TTL=254
Reply from 192.168.12.1: bytes=32 time=4ms TTL=254
Reply from 192.168.12.1: bytes=32 time=16ms TTL=254
Reply from 192.168.12.1: bytes=32 time=9ms TTL=254
Reply from 192.168.12.1: bytes=32 time=5ms TTL=254
Reply from 192.168.12.1: bytes=32 time=6ms TTL=254
Reply from 192.168.12.1: bytes=32 time=3ms TTL=254

Ping statistics for 192.168.12.1:
    Packets: Sent = 34, Received = 34, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 3ms, Maximum = 16ms, Average = 4ms
Control-C
^C
C:\Users\reuben>

So that's all good too. I guess that rules out hardware and local LAN.

iperf3 in both send and receive (swap ends to confirm symmetry) gives around about 350MBit/s in both directions. It is consistent but I haven't tested it with anything other than default options (for now).

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   454 MBytes   380 Mbits/sec    0             sender
[  5]   0.00-10.01  sec   452 MBytes   379 Mbits/sec                  receiver

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   398 MBytes   334 Mbits/sec    0             sender
[  5]   0.00-10.01  sec   397 MBytes   333 Mbits/sec                  receiver

I guess there's something specific to the Pi that is causing this. I don't have a standalone Linux box around right now.

[reubenfarrelly]

Also - disabled the SSID on the 6GHz band (so it is only seen on the 5GHz band) - no change to the behaviour. And disabled WPA3 so w're doing WPA2 only and no change either. For the purposes of testing this is the only client device on that SSID so I can play about quite a bit...

[morrownr]

I don't have a standalone Linux box around right now.

Don't need one. Download Ubuntu 23.10 and burn it to a usb flash driver. Boot it and run. You don't have to install it. Ping away.

Changing variables is the only way to narrow down the cause. Move the AP, even if a little. Move the location of the adapter, even if not a large amount.

This may not be the adapter driver but something in the Linux stack. Also, there are a lot of settings in the router that could be treated differently by Linux than in Windows.

I am trying to bring a new Linux driver for the rtl8812au chipset to availability. One guy has been reporting latency issues. We have been beating on the problem for 2 months. I can't duplicate it. I'd have to go look but I think the guy was using a RasPi4B. I have been helping usb wifi adapter users for a few years in my spare time. I can write you a lot of horror stories about the usb subsystem in Pi's. It would be good if you burn that usb flash driver and see what you get with a x86_64 system.

Earlier you mentioned that updated your kernel to 6.6 to use WPA3. It should not be necessary to upgrade to kernel 6.6 to have WPA3. It is not necessary here with my adapters that use the same chipset and drivers as your Netgear adapter... you are using using the 2023-12-05 RasPiOS release? Right?

@morrownr

[reubenfarrelly]

I am trying to bring a new Linux driver for the rtl8812au chipset to availability. One guy has been reporting latency issues. We have been beating on the problem for 2 months. I can't duplicate it. I'd have to go look but I think the guy was using a RasPi4B. I have been helping usb wifi adapter users for a few years in my spare time. I can write you a lot of horror stories about the usb subsystem in Pi's. It would be good if you burn that usb flash driver and see what you get with a x86_64 system.

I think I've solved it with this:

root@temp-3:/etc/NetworkManager/conf.d# cat default-wifi-powersave-on.conf 
[connection]
wifi.powersave = 2
root@temp-3:/etc/NetworkManager/conf.d#

I'm now getting 1-2ms pings which is fantastic. Need to leave it for a while to confirm, but so far this seems to have done it. Without that setting in place, iwconfig shows Power Management:on (with that set, it shows it as 'off').

There were some posts about power saving being disabled upstream in the mt7921 which fixed this problem:

https://patchwork.kernel.org/project/linux-wireless/patch/20231212090852.162787-1-mario.limonciello@amd.com/#25636268

Earlier you mentioned that updated your kernel to 6.6 to use WPA3. It should not be necessary to upgrade to kernel 6.6 to have WPA3. It is not necessary here with my adapters that use the same chipset and drivers as your Netgear adapter... you are using using the 2023-12-05 RasPiOS release? Right?

Yes. See this: https://github.com/raspberrypi/firmware/commit/c700ec07c8c9b4bd25c47bfb22ee12e935ebbf26 and https://github.com/raspberrypi/linux/pull/5945

Which all comes back nicely to your comment about how terrible Broadcom chips are in the Pi ;-)

That was where my journey all started. Originally I wanted to use WPA3 on the onboard Broadcom Wifi, but I could not get it to work (either WPA3 or Mixed Mode WPA2/3), so I started looking for an external adaptor to play with and landed on the Netcomm where that all does work. I left the 6.6 kernel in place from my earlier attempts anyway, but according to your documentation it needs at least 6.4 anyway so it made sense to keep using it.

So it seems to me that the "fix" was to (a) upgrade the RPI kernel to 6.6+ using rpi-update, and (b) disable power save, and then it's all plug and play with the Netcomm after that.

[morrownr]

I think I've solved it with this:

This is great. I need to study what you have done.

iwconfig shows Power Management:on (with that set, it shows it as 'off').

iwconfig is very old and not maintained. It was depreciated years ago. The modern, maintained replacement utility is `iw".

$ iw wlan0 get power_save $ iw wlan0 set power_save off $ iw wlan0 set power_save on

A good example of using iw to being up interfaces:

$ iw

The utility ip also takes on some of the things iwconfig used to do so know it also helps. Example:

$ ip a

These modern replacements need less typing which is always a good thing ...

There were some posts about power saving being disabled upstream in the mt7921 which fixed this problem:

I saw that discussion when it started on linux-wireless but it was non-specific so I did not pay much attention. It appears that you have one of the APs that triggers this problem. I'll be paying attention to see if there is a cleaner resolution to this issue and I intend to document the issue.

I left the 6.6 kernel in place from my earlier attempts anyway, but according to your documentation it needs at least 6.4 anyway so it made sense to keep using it.

Speaking of documentation: Thanks for reading the docs. Your specific adapter does require kernel 6.4 to be fully plug and play as Netgear used a non-default vid/pid for the adapter so it had to be added which can take time.

Keep me posted so that I can add some good documentation for others to see. I'll wait for a report from you. Give it a few days.

@morrownr

[morrownr]

oh, one thing popped to mind:

None of the discussions I have read indicate what the AP/routers are doing that is causing this. Did you pick up on anything?

Would you be interested in checking the powersave related settings in your AP/router to see what settings are available and if changing any would solved this problem. That information would certainly be good for the documentation of this issue.

Thanks,

@morrownr

[reubenfarrelly]

None of the discussions I have read indicate what the AP/routers are doing that is causing this. Did you pick up on anything?

I'm seeing this with both a Cisco 9130I and 9166I AP. I tried dumbing down the config to absolute essentials a few days ago for this client but it made no difference (turned off PMF/802.11w, FT/802.11r, 6GHz, band steering etc). I believe these APs are now using their own custom silicon (not Marvell or Broadcom Wireless chips anymore, but a custom chip combined with a custom Linux build OS), so you might not see these radios anywhere else. I am running very recent firmware for these, currently based on IOS XE 17.13/17.14 . There doesn't appear to be any option to change this other than possibly some things like "BSS Target Wake Up Time". They are joined to a Cisco 9800 controller but I think it's likely to be the APs themselves not the controller which are at play here. The MACs of the radios in them are Cisco proper registered MACs too, so that doesn't give any clues as to the vendor either.

I've got around 30 other devices of a large mix and variety at the moment and all were performing well other than this one.

Still seeing ping times of between 1-3ms and ssh sessions are instantly responsive so after 24 hours I'm pretty certain that has now nailed it.

[reubenfarrelly]

Folllowing on from this, a new release of Raspberry Pi OS has come out on 12 March with the Linux 6.6 kernel. So for a new install (or upgrade) with the Netgear adaptor as long as the latest version is installed then it should work out of the box without any need for rpi-update. I haven't tested but presumably this might also include newer versions of other relevant drivers too. And one can only hope WPA3 with the included Broadcom Wifi now might work as well!

[morrownr]

@reubenfarrelly

a new release of Raspberry Pi OS has come out on 12 March with the Linux 6.6 kernel. So for a new install (or upgrade) with the Netgear adaptor as long as the latest version is installed then it should work out of the box without any need for rpi-update.

That is correct.

I haven't tested but presumably this might also include newer versions of other relevant drivers too.

Going from kernel 6.1 to 6.6 should provide MANY updated and new drivers.

And one can only hope WPA3 with the included Broadcom Wifi now might work as well!

I am so used to turning the onboard wifi off that I probably won't be checking this anytime soon.

Cheers,

@morrownr

[reubenfarrelly]

I am so used to turning the onboard wifi off that I probably won't be checking this anytime soon.

After a quick test today (revert back to using the built-in Broadcom Wifi but did not change any configuration) it appears that the in-built still isn't quite working with WPA3. This is on a pure WPA3 network - not mixed-mode:

temp-3 wpa_supplicant[814]: wlan0: WPA: Failed to select authenticated key management type temp-3 wpa_supplicant[814]: wlan0: WPA: Failed to set WPA key management and encryption suites

WPA3 PSK should really not be that tricky to get to work...seems that despite some updates upstream it's still not fully baked. This means I'll continue using the external Netgear for the foreseeable future, which is demonstrably a much better and capable device anyway and where this exact config works straight out of the box.

[lilkidsuave]

According to the USB_WiFi_Adapters_that_are_supported_with_Linux_in-kernel-drivers document:

AXE5400 - USB3.0 - 2.4 GHz, 5 GHz and 6 GHz (WiFi 7) chipset - Mediatek mt7925 - supported in-kernel since Linux kernel 6.7 (2024) No adapters with this chipset are available to consumers yet. Expect adapters to be available at some point in 2024. If you see an adapter that uses the mt7925 chipset, please post in Issues.

So I thought I'd go ahead and purchase a tp-link AXE5400 Wi-Fi 6E Wireless USB Adaptor from Amazon in the hopes of obtaining a very decent MediaTek mt7925 based unit to use on my Raspberry Pi. I could not definitively find anything in any official documentation which suggests what chip it ran though.

But after attempting to use it I realised:

[ 156.401251] usb 1-1: New USB device found, idVendor=35bc, idProduct=0102, bcdDevice= 0.00 [ 156.401258] usb 1-1: Product: 802.11ax WLAN Adapter [ 156.401261] usb 1-1: Manufacturer: Realtek

So it actually has a RealTek chip - I believe it requires the rtw8852cu driver and not a Mediatek.

I now have a tp-link AXE5400, AX1800 and AX55-Nano all with Realtek chips, and all available for testing if you can use these for anything @morrownr :)

My Netgear AX3000 is the only decent MediaTek unit I can get my hands on, but it seems to suffer from latency issues.

That AXE5400 can be worked around somewhat, but I'm having issues using 6ghz ap mode with it. I'm using a 8832cu which is a axe5400 variant of the 8852cu. Drivers exist for both atm.