morrownr / USB-WiFi

USB WiFi Adapter Information for Linux
2.41k stars 161 forks source link

Comfast CF-953AX impressions #133

Open bjlockie opened 1 year ago

bjlockie commented 1 year ago

It seems to be a bit faster than the Alfa mt7612. I couldn't get Bluetooth to work. I want to try it on my Raspberry Pi4 next.

Ryzen5 5600 server:

Wifi6 server (192.168.68.72):
$ uname -a
Linux lubuntu 5.19.0-19-generic #19-Ubuntu SMP PREEMPT_DYNAMIC Tue Sep 27 16:03:25 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

$ lsusb
lubuntu@lubuntu:~$ lsusb
Bus 002 Device 024: ID 0e8d:7961 MediaTek Inc. Wireless_Device

$ iwconfig
wlxe0e1a935d087  IEEE 802.11  ESSID:"garlic"  
          Mode:Managed  Frequency:5.24 GHz  Access Point: xxxxxxxxxx   
          Bit Rate=1.2009 Gb/s   Tx-Power=3 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=67/70  Signal level=-43 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:1   Missed beacon:0

rjl@james-aspirea51555:~$ iperf3 -c 192.168.68.72
Connecting to host 192.168.68.72, port 5201
[  5] local 192.168.68.73 port 56360 connected to 192.168.68.72 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  37.5 MBytes   315 Mbits/sec    2    609 KBytes       
[  5]   1.00-2.00   sec  36.2 MBytes   304 Mbits/sec    0    662 KBytes       
[  5]   2.00-3.00   sec  31.2 MBytes   262 Mbits/sec    1    509 KBytes       
[  5]   3.00-4.00   sec  32.5 MBytes   273 Mbits/sec    0    554 KBytes       
[  5]   4.00-5.00   sec  32.5 MBytes   273 Mbits/sec    0    600 KBytes       
[  5]   5.00-6.00   sec  36.2 MBytes   304 Mbits/sec    0    645 KBytes       
[  5]   6.00-7.00   sec  35.0 MBytes   294 Mbits/sec    1    518 KBytes       
[  5]   7.00-8.00   sec  31.2 MBytes   262 Mbits/sec    2    287 KBytes       
[  5]   8.00-9.00   sec  30.0 MBytes   252 Mbits/sec    1   1.75 MBytes       
[  5]   9.00-10.00  sec  41.2 MBytes   346 Mbits/sec    1   1.39 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   344 MBytes   288 Mbits/sec    8             sender
[  5]   0.00-10.02  sec   342 MBytes   286 Mbits/sec                  receiver

iperf Done.

Wifi5 server (192.168.68.79):
$ uname -a
Linux lubuntu 5.19.0-19-generic #19-Ubuntu SMP PREEMPT_DYNAMIC Tue Sep 27 16:03:25 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

lubuntu@lubuntu:~$ lsusb
Bus 002 Device 023: ID 0e8d:7612 MediaTek Inc. MT7612U 802.11a/b/g/n/ac Wireless Adapter

lubuntu@lubuntu:~$ iwconfig
wlx00c0caaa9c2b  IEEE 802.11  ESSID:"garlic"  
          Mode:Managed  Frequency:5.24 GHz  Access Point: xxxxxxxxxx   
          Bit Rate=866.7 Mb/s   Tx-Power=20 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=65/70  Signal level=-45 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0           
          Tx excessive retries:1  Invalid misc:71   Missed beacon:0          

rjl@james-aspirea51555:~$ iperf3 -c 192.168.68.79
Connecting to host 192.168.68.79, port 5201
[  5] local 192.168.68.73 port 53242 connected to 192.168.68.79 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  31.3 MBytes   262 Mbits/sec    0   1.55 MBytes       
[  5]   1.00-2.00   sec  28.8 MBytes   241 Mbits/sec    0   1.59 MBytes       
[  5]   2.00-3.00   sec  31.2 MBytes   262 Mbits/sec    2   1.23 MBytes       
[  5]   3.00-4.00   sec  28.8 MBytes   241 Mbits/sec    0   1.34 MBytes       
[  5]   4.00-5.00   sec  30.0 MBytes   252 Mbits/sec    4    721 KBytes       
[  5]   5.00-6.00   sec  28.8 MBytes   241 Mbits/sec    0    781 KBytes       
[  5]   6.00-7.00   sec  30.0 MBytes   252 Mbits/sec    0    820 KBytes       
[  5]   7.00-8.00   sec  28.8 MBytes   241 Mbits/sec    0    846 KBytes       
[  5]   8.00-9.00   sec  28.8 MBytes   241 Mbits/sec    0    860 KBytes       
[  5]   9.00-10.00  sec  30.0 MBytes   252 Mbits/sec    3    457 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   296 MBytes   249 Mbits/sec    9             sender
[  5]   0.00-10.01  sec   294 MBytes   246 Mbits/sec                  receiver

iperf Done.

NOTE: I couldn't get to work in Windows at all.

morrownr commented 1 year ago

It seems to be a bit faster than the Alfa mt7612.

Yes, that is my experience with the CF-951AX also. My main wifi router is a ZyXEL NBG6817 that is Wave 2 capable. I run 5 GHz on a DFS channel where there is zero other traffic. With the 951AX plugged into a client system I can sustain 650 Mb/s using AC. I can't try AX yet because the router can't do AX. All of the testing I have done so far indicates the mt7921au chipset is capable of very good speeds.

I couldn't get Bluetooth to work.

Not a surprise. No luck here either.

I want to try it on my Raspberry Pi4 next.

There are some thing you need to know. The RasPiOS is showing some age. Even the Sep. 22 release is still based on the Bullseye release of Debian so many components are not ready for this chipset. You will need to update several parts of the os:

wpa_supplicant_compile_guide.tar.gz

Upgrade_hostapd.tar.gz - if you use hostapd, you would need to install the version in the repos first and then upgrade it with this guide.

Upgrade_RasPiOS_Kernel.tar.gz

update_regdb.tar.gz

The instructions for updating the firmware are on the Main Menu.

There may be other things that I haven't run onto yet. The Buntu's that will be released next week should be in pretty good shape. The Lubuntu you are using should be in pretty good shape with most of the above.

I couldn't get to work in Windows at all.

I don't really follow Windows or MacOS but I do run across a little information here and there. This WiFi 6 thing seems to be a challenge across all OSs currently.

Nick

leezu commented 1 year ago

There are some thing you need to know. The RasPiOS is showing some age. Even the Sep. 22 release is still based on the Bullseye release of Debian so many components are not ready for this chipset. You will need to update several parts of the os:

with respect to hostapd and wpa_supplicant you can also install them from the Raspbian testing distribution:

Add this to /etc/apt/sources.list

deb http://raspbian.raspberrypi.org/raspbian/ testing main contrib non-free rpi
deb-src http://raspbian.raspberrypi.org/raspbian/ testing main contrib non-free rpi

Create /etc/apt/preferences.d/preferences.pref as

Package: *
Pin: release l=Raspbian-Security
Pin-Priority: 997

Package: *
Pin: release o=Raspbian,n=bullseye-updates
Pin-Priority: 995

Package: *
Pin: release o=Raspbian,a=testing
Pin-Priority: 10

Then sudo apt install -t testing wpasupplicant hostapd

bjlockie commented 1 year ago

The RasPiOS is showing some age.

I use ubuntu-server. I may just wait for the official release because the mt76 driver is in a separate package which may not be included in the base release.

morrownr commented 1 year ago

I use ubuntu-server.

How well does that Ubuntu server work on a Pi4B?

morrownr commented 1 year ago

@leezu

Thanks for the alternate upgrade method. I have a tendency to grab a compiler.

With all of the serious changes like WPA3, WiFi 6 and the new 6 GHz band working there way into user space, it is a pain to work with distros that are based on the last stable Debian.

bjlockie commented 1 year ago

How well does that Ubuntu server work on a Pi4B?

No problems. It's missing some of the wifi packages but that is not a deal breaker. It doesn't have a GUI but since I only have a 1GB Pi4B my options are limited.

morrownr commented 1 year ago

It's missing some of the wifi packages but that is not a deal breaker.

Is it missing just the firmware or the drivers as well?

It doesn't have a GUI but since I only have a 1GB Pi4B my options are limited.

$ sudo apt install xfce4

bjlockie commented 1 year ago
It's missing some of the wifi packages but that is not a deal breaker.

Is it missing just the firmware or the drivers as well?

I think everything about wifi is in extra packages.

Maybe I'll try a desktop distro there. :-)

bjlockie commented 1 year ago

$ sudo apt install xfce4

I was getting weird lockups but then I remembered I didn't configure any swap space. It shouldn't be using 1GB of ram but it might. :-(

morrownr commented 1 year ago

You might find some tips at the following site that will allow you to optimize:

https://easylinuxtipsproject.blogspot.com/p/1.html

bjlockie commented 1 year ago

I used a 2GB RPI4 and ubuntu works. I tried plugging the Confast in the cradle that came with the Alfa AWUS036ACM but it didn't recognize it. It works with my USB extension cable. I have that plugged in to a powered USB hub.

bjlockie commented 1 year ago

I don't know why RPi went with a Broadcom SOC with no Linux drivers.

morrownr commented 1 year ago

I don't know why RPi went with a Broadcom SOC

You are preaching to the choir. I cringed a few years ago when I saw that the Pi's were based on Broadcom products.

black-jmyntrn commented 1 year ago

I got it working on the 3b+, still having issues on the 4... I'm wondering where the driver for these other spots comes from.

: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 P: Vendor=0e8d ProdID=7961 Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C: #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=160mA A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01 I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms I: If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us I: If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us I:* If#= 3 Alt= 0 #EPs= 9 Cls=ff(vend.) Sub=ff Prot=ff Driver=mt7921u E: Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=08(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=09(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=86(I) Atr=03(Int.) MxPS= 2 Ivl=125us

fhteagle commented 1 year ago

Just got a CF-953AX. Connected to my x86_64 router running arch. Kernel modules for mt76, mt7921u, etc all loaded automagically.

Was able to get it to announce 802.11ax capability on 5GHZ with a custom complied hostapd instance. The packaged hostapd 2.10 still does not have the right compile flag on for that option. However, the actual phy link rate to an AX210 in my laptop is crazy low, usually in the 65-130mbps range. I probably have not gotten all the options right in my hostapd.conf yet.

6 ghz seems blocked (no-IR for all channels on iw phy output), need to figure out the right regulatory domain to make that work.

global
country US: DFS-FCC
        (902 - 904 @ 2), (N/A, 30), (N/A)
        (904 - 920 @ 16), (N/A, 30), (N/A)
        (920 - 928 @ 8), (N/A, 30), (N/A)
        (2400 - 2472 @ 40), (N/A, 30), (N/A)
        (5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
        (5250 - 5350 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
        (5470 - 5730 @ 160), (N/A, 24), (0 ms), DFS
        (5730 - 5850 @ 80), (N/A, 30), (N/A), AUTO-BW
        (5850 - 5895 @ 40), (N/A, 27), (N/A), NO-OUTDOOR, AUTO-BW, PASSIVE-SCAN
        (5925 - 7125 @ 320), (N/A, 12), (N/A), NO-OUTDOOR, PASSIVE-SCAN
        (57240 - 71000 @ 2160), (N/A, 40), (N/A)
amisix commented 1 year ago

@fhteagle I had an issue with slow throughput (~60Mbps) when the center channel was not set via he_oper_centr_freq_seg0_idx=71 idx= being 2 above channel. Example, channel 69, he_oper_centr_freq_seg0_idx=71 Maybe that has an impact on what you're experiencing.

FR seems to work if you want to go on a great vacation.

fhteagle commented 1 year ago

@amisix thank you for the "Nice" suggestion about what country to visit lol

But hostapd is refusing to start with any channel number that does not correspond to a 20 mhz channel set in hostapd.conf . Not sure if I missed a flag in my compile config, or if hostapd.conf is missing a line, or there's just a quirk of the CF-953AX? Attaching for you all to check my work:

hostapd compile .config: https://pastebin.com/WeYfcTp9

hostapd.conf working on 20mhz, does not work with non-20mhz channels, even changing the relevant he_oper_chwidth and idx lines: https://pastebin.com/Jnfwzdbp

iw phy for the CF-953AX: https://pastebin.com/6pb9wfv3

Any insights you all have would be greatly appreciated. I have run linux, dd-wrt, and a few one off projects using hostapd for a long time, but this building my own router and wireless AP from scratch project is definitely a stretch of my skills. Thanks!

morrownr commented 1 year ago

FR seems to work if you want to go on a great vacation.

DE makes for a great vacation as well.

I have a CF-951AX with the same mt7921au chipset as the 953. I posted a speed test:

Issue 139 - Speed Test with Specific USB WiFi Adapters

That is using WiFi 5 but it shows how fast this chipset can be.

I'm currently running my Pi4B as an AP with the 951 using WiFi 6. It works but is only showing around 235 Mb/s on channel 36 but that is about all I can get on channel 36 given the heavy congestion. I don't have another 6e device to test with yet but have been watching the posts of others. I have to wonder if the low speed tests are a symptom of running a 20 MHz channel width. I would experiment more to find out but that is hard to do without a second adapter. Hopefully I'll have that corrected soon.

FYI: I have compiled a new kernel on the RasPiOS, new hostapd, new wpa_supplicant and a couple of other things. The RasPiOS is lagging but, to be fair. many other things are lagging as well as it certainly isn't just Linux. We will get this figured out.

morrownr commented 1 year ago

@fhteagle

I am keeping example hostapd.conf files in this directory:

https://github.com/morrownr/USB-WiFi/tree/main/home/AP_Mode

hostapd-6g.conf is for WiFi 6 (it works) and hostapd-6eg.conf is for 6 GHz and I don't know if it works yet but I am trying to get it as close as I can for now. Some things to keep in mind:

fhteagle commented 1 year ago

@morrownr -

Thanks for pointing those out. I will give your 6eg.conf a try tomorrow. Fortunately, I am in possession of 3x copies of the same Framework mainboard temporarily, so I can do a lot of testing.

New issue is whenever the CF-953AX is bridged into the routers br0 interface, the whole system freezes within a minute of the first STA connecting to the 953AX. Will need to do more testing on a mainboard that is not acting as the main router for two houses when everyone is home..............

morrownr commented 1 year ago

New issue is whenever the CF-953AX is bridged into the routers br0 interface, the whole system freezes within a minute of the first STA connecting to the 953AX. Will need to do more testing on a mainboard that is not acting as the main router for two houses when everyone is home..............

I monitor linux-wireless and there is a lot of new and fixed code going into the driver on a regular basis. Heck there is a lot of code and fixes going into mac80211 and the rest of the stack. I'm actually amazed at how stable the mt7921u driver is given the complexity required for WiFi 6e. We are even seeing regular new drops of the firmware files. Hey, there was a series last week that added the start of their new WiFi 7 driver. Bottom line: mt7921u is not finished. A lot of additional capabilities are on the way and bugs will be found and fixed.

fhteagle commented 1 year ago

Did more testing today. Got the CF-953AX (MT7921U) and an MT7921K each able to make WPA3 6Ghz APs using your example hostapd-6eg.conf with a few tweaks.

amisix commented 1 year ago

@fhteagle Mind sharing those tweaks?

morrownr commented 1 year ago

able to make WPA3 6Ghz APs using your example hostapd-6eg.conf with a few tweaks.

And those tweaks are?

Also, Amazon has MT721K's on sale for $14 for Black Friday / Cyber Monday....

Got a link handy?

amisix commented 1 year ago

This is the vendor I went through. $13.96 for Cyber Monday. https://www.amazon.com/dp/B09MBMXNYB

fhteagle commented 1 year ago

@morrownr -

So I finally got properly sized MHF4 to RP-SMA wires so I could hook up better antennas to the MT7921K. Still having trouble with stability on the CF-953AX when it is connected to my Framework mainboard acting as the home router, but it does not crash when connected to the same spec mainboard and same arch install on my laptop. Real head scratcher there, so I am sticking to testing the MT7921K for now.

Here's my hostapd.conf work in progress, using 5ghz channels for testing at the moment: https://pastebin.com/0jR81q2X , using a custom compiled hostapd 2.11 from git. It does not seem to understand an he_capab config line, so I am probably missing a lot of tuning and performance options...

WPA3, 6ghz (if country code spoofed), 80MHz channel, up to 1200Mbps HE-MCS link rates are working according to wavemon on the laptop. iw phy for this card ( https://pastebin.com/7jJBpp5W ) leads me to believe that this will not do a 160Mhz channel as AP?

Actual throughput to the laptop (also with an MT7921K in it) is not awesome though: ~160Mbps +/- 30Mbps or so with ~-50 RSSI levels. If anyone has any suggestions on how to get the actual throughput up, I am all ears.

bjlockie commented 1 year ago

That chipset doesn't support 160Mhz wide channels in any mode. Not sure it is needed but there apparently is a 7922 somewhere.

morrownr commented 1 year ago

@fhteagle

FYI: In my AP_Mode folder, I am building new WiFi6 and WiFi6e hostapd.conf files:

https://github.com/morrownr/USB-WiFi/tree/main/home/AP_Mode

The 6g file seems to be working well. The 6eg file is still a work in progress. Recommend you take a look at hostapd-6g.conf as it has some differences with your file.

It does not seem to understand an he_capab config line

I have not found where he_capab exists.

Keep in mind that we are the ones figuring this stuff out as there are basically no examples out there.

fhteagle commented 1 year ago

@morrownr Tried two of the options from your example file:

he_default_pe_duration=0 adding only this config option cut throughput almost in half

he_basic_mcs_nss_set=2
adding this added maybe 30Mbps in average throughput over my previous baseline config I pastebin'd in my previous message, but wavemon says VHT-MCS in use instead of HE-MCS. Interesting.

using both was the same as just the nss_set config value

I did not see anything else in my config above that I was missing except the he_6ghz line, which obviously is not germane to 5ghz testing....

morrownr commented 1 year ago

auth_algs=3

need that.

Still trying to figure things out here.

whitslack commented 1 year ago

New issue is whenever the CF-953AX is bridged into the routers br0 interface, the whole system freezes within a minute of the first STA connecting to the 953AX.

Is there any resolution to this? I have an ALFA AWUS036AXML (based on the MT7921AUN chipset), and I can run an AP on it using hostapd, but the very moment a client station associates, the driver crashes the kernel. The kernel log complains of an illegal opcode, presumably because the instruction pointer register was overwritten to an address that doesn't contain executable code, perhaps due to a buffer overflow that overwrote a return address on the stack. The mt7921 interface is bound to a software Ethernet bridge that also hosts a wired Ethernet interface and an OpenVPN TAP interface. I have tested up to kernel 6.2.2, and the problem remains. This effectively makes my brand new ALFA adapter an expensive (and not so effective) paperweight.

bjlockie commented 1 year ago

Could that be due to firmware? I would try the latest dev kernel.

morrownr commented 1 year ago

New issue is whenever the CF-953AX is bridged into the routers br0 interface, the whole system freezes within a minute of the first STA connecting to the 953AX.

Is there any resolution to this?

I'll give this a test here.

What hardware and distro and you using?

The kernel log complains of an illegal opcode, presumably because the instruction pointer register was overwritten to an address that doesn't contain executable code, perhaps due to a buffer overflow that overwrote a return address on the stack.

Any indication of what was running that could have led to this problem?

The mt7921 interface is bound to a software Ethernet bridge that also hosts a wired Ethernet interface and an OpenVPN TAP interface.

There are a lot of moving parts involved so please be specific and about your software and hardware so that I know what needs to be tested.

whitslack commented 1 year ago

Could that be due to firmware?

@bjlockie: I don't see how that would be possible. The firmware is running on the remote end of a USB link; it doesn't have any access to the system RAM, which is what is being corrupted here. There's something on the host side making a mess.

I would try the latest dev kernel.

Which dev kernel would that be? There are like a thousand of them. I've been testing with the mainline 6.2.2 release.

What hardware and distro and you using?

@morrownr: My router isn't running any distro, just a few pieces of software that I built myself.

That's irrelevant, though, because the crash is trivially reproducible on a Raspberry Pi running the stock 6.1.14 kernel and hostapd 2.10 built with the following config:

CC = armv6j-unknown-linux-gnueabihf-gcc
CONFIG_DRIVER_NL80211=y
CONFIG_LIBNL32=y
CONFIG_RSN_PREAUTH=y
CONFIG_OCV=y
CONFIG_IEEE80211R=y
CONFIG_WNM=y
CONFIG_IEEE80211AC=y
CONFIG_IEEE80211AX=y
CONFIG_DEBUG_SYSLOG=y
CONFIG_NO_ACCOUNTING=y
CONFIG_NO_RADIUS=y
CONFIG_NO_VLAN=y
CONFIG_NO_DUMP_STATE=y
CONFIG_NO_RANDOM_POOL=y
CONFIG_GETRANDOM=y
CONFIG_ELOOP_EPOLL=y
CONFIG_ACS=y
CONFIG_TAXONOMY=y
CONFIG_FILS=y
CONFIG_FILS_SK_PFS=y
CONFIG_NO_TKIP=y
CONFIG_SAE=y

(Note, some of those features, like RSN preauth, ACS, taxonomy, FILS, and SAE, I am not using yet, but I built support for them so I could play around with them. They're probably irrelevant.)

To reproduce the kernel crash:

# cat >/tmp/hostapd.conf <<EOF
interface=wlan0
bridge=br0
driver=nl80211
ssid=test
country_code=US
ieee80211d=1
ieee80211h=1
hw_mode=a
channel=149
auth_algs=1
ieee80211n=1
ht_capab=[LDPC][HT40+][HT40-][GF][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][MAX-AMSDU-7935]
require_ht=1
ieee80211ac=1
vht_capab=[MAX-MPDU-11454][RXLDPC][SHORT-GI-80][TX-STBC-2BY1][RX-STBC-1][SU-BEAMFORMEE][BF-ANTENNA-4][MAX-A-MPDU-LEN-EXP7][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN]
vht_oper_chwidth=1
vht_oper_centr_freq_seg0_idx=155
ieee80211ax=1
he_oper_chwidth=1
he_oper_centr_freq_seg0_idx=155
wpa=2
wpa_passphrase=open session me
wpa_key_mgmt=WPA-PSK WPA-PSK-SHA256
rsn_pairwise=CCMP CCMP-256
EOF

# ip link add br0 type bridge
# ip addr add <eth0's-IPv4-addr>/<prefix-len> dev br0
# ip link set br0 up && ip link set eth0 master br0
# hostapd /tmp/hostapd.conf

(If you're seated directly on your Pi, then you probably don't need to add your eth0's IP address to the new bridge interface. I do because my Pi runs headless, and I would strand my SSH connection if I didn't.)

hostapd should start up just fine and begin broadcasting beacons. Then just connect a client station — I'm using an Android phone — and kaboom!

morrownr commented 1 year ago

@whitslack

I have an ALFA AWUS036AXML (based on the MT7921AUN chipset), and I can run an AP on it using hostapd, but the very moment a client station associates, the driver crashes the kernel. The kernel log complains of an illegal opcode, presumably because the instruction pointer register was overwritten to an address that doesn't contain executable code, perhaps due to a buffer overflow that overwrote a return address on the stack.

That's irrelevant, though, because the crash is trivially reproducible on a Raspberry Pi running the stock 6.1.14 kernel and hostapd 2.10 ...

Let me see if I can reproduce this.

maheralbashek3 commented 1 year ago

Very good

morrownr commented 1 year ago

@whitslack

That's irrelevant, though, because the crash is trivially reproducible on a Raspberry Pi running the stock 6.1.14 kernel and hostapd 2.10 ...

Let me see if I can reproduce this.

I was not able to reproduce this.

RasPi4B RasPiOS 2023-02-21 64 bit Kernel 6.1 as compiled from the RasPiOS repo hostapd as compiled two days ago from its home wpa_supplicant as compiled two days ago from its home using WPA3 using the Access Point guide as shown on the Main Menu here

Rock solid.

whitslack commented 1 year ago

I was not able to reproduce this.

Both of the systems that I have tried (and failed) to run this on are 32-bit. Do you have any 32-bit systems you can use? An older Raspberry Pi model maybe?

Kernel 6.1 as compiled from the RasPiOS repo

I'm not familiar with "RasPiOS." Have you tried the pre-built stock kernel?

using WPA3

So you weren't following my steps to reproduce. Maybe try with the hostapd.conf that I provided.

using the Access Point guide as shown on the Main Menu here

There's a heck of a lot of systemd and NetworkManager crud in that guide. Have you tried the straightforward four command lines that I provided?

I may dig out a spare SD card and give your guide a try. If it works, then I can probably find the root of the problem by titration.

Note, I'm not the only one seeing this crash.

morrownr commented 1 year ago

I was not able to reproduce this.

Both of the systems that I have tried (and failed) to run this on are 32-bit. Do you have any 32-bit systems you can use? An older Raspberry Pi model maybe?

I have a RasPi3B. I'm moving and it is packed but I'll see if I can dig it out tomorrow.

Kernel 6.1 as compiled from the RasPiOS repo

I'm not familiar with "RasPiOS."

https://www.raspberrypi.com/software/

Have you tried the pre-built stock kernel?

No

using WPA3

So you weren't following my steps to reproduce.

I was not in this case. I wanted to see if a known good configuration worked first and it did which tells me this is likely not an issue with the driver. I can now go back and include certain things to try to narrow down the cause. I suspect that I know the cause but let me prove it first.

Maybe try with the hostapd.conf that I provided.

I plan to do as much.

using the Access Point guide as shown on the Main Menu here

There's a heck of a lot of systemd and NetworkManager crud in that guide.

That crud makes for an extremely stable AP. I did not pull that guide out of my backside over a weekend. It was built over 2 years and almost every part in it has had extrensive testing.

Have you tried the straightforward four command lines that I provided?

Not yet.

I may dig out a spare SD card and give your guide a try. If it works, then I can probably find the root of the problem by titration.

This sounds like a sound plan. If I am able to dig out my Pi3B, I'll use the current RasPiOS 32 bit version and see what happens. There are a lot of differences between what you did and what I did. I don't think 32 bit is problem but it could be. I am using a slightly different hostapd.conf and I also compiled wpa_supplicant. The .config I used to compile hostapd was basically identical. The prime suspects would be the distro you are using, wpa_supplicant and the hostapd.conf file.

Note, I'm not the only one seeing this crash.

I understand.

whitslack commented 1 year ago

https://www.raspberrypi.com/software/

Hmm, I wonder if they use the kernel images from raspberrypi/firmware.

That crud makes for an extremely stable AP.

Sorry, I was overly offensive in my choice of language. I am strongly opposed to systemd and its takeover of the Linux ecosystem, so using it is a nonstarter for me. I see a system that is using traditional SysV init (or in the case of my router, Busybox init) as being much simpler and less prone to bugs and failures than a system that is using the complex and poorly documented Hydra that is systemd. Kudos to you for slogging through it all to put together your guide.

I also compiled wpa_supplicant.

Why, may I ask? wpa_supplicant is for running in client/managed/station mode. Whether you compiled it or not has no bearing on hostapd, and you'd only need it if you were trying to implement something like a range extender where you need to bridge a managed/station interface and a master/AP interface.

The prime suspects would be the distro you are using, wpa_supplicant and the hostapd.conf file.

That would all be userspace, though. It shouldn't be possible for userspace to panic the kernel†. Since it is, there is definitely a kernel bug. Maybe your userspace configuration isn't triggering it, but it's there lurking.

_____ † barring obviously destructive actions like dd if=/dev/zero of=/dev/mem.

morrownr commented 1 year ago

I have a RasPi3B. I'm moving and it is packed but I'll see if I can dig it out tomorrow.

That did not work out as it is packed and appears to have departed already. Moving is always a challenge.

However, I don't know why I was looking for a Pi3B because it is 64 bit also. I guess using a 32 bit verion of RasPiOS is what should be used to check this theory.

Note, https://github.com/openwrt/openwrt/issues/11796.

I use OpenWRT 22.03.3 on my main wifi router. I have a mt7921au based adapter in the USB3 port. It does WiFi 6.

The reported you posted is somewhat dated. The only package that needs to be installed these days is:

kmod-mt7921u

That installs all that is required to support mt7921au based adapters on OpenWRT. The OpenWRT were kind enough to backport the driver to the 5.10 kernel they use. I've seen no crashes. I'd like to see a crash so we can figure out why you are having a problem but so far, nothing. I suspect an issue with the distro you are using.

whitslack commented 1 year ago

I have a mt7921au based adapter in the USB3 port.

Could it be because I have the AWUS036AXML in a USB2 port?

I suspect an issue with the distro you are using.

Again, I'm not using a "distro" on my router. The kernel there is the vanilla kernel from kernel.org, i.e., the most "upstream" you can get (aside perhaps from Linus's own development workstation). It has a very minimal configuration, only as much as I need for my use case, a minimized attack surface. The kernel on my Raspberry Pi is the official pre-built image from the Raspberry Pi organization. It is possible that your distribution has patched a bug in the kernel and has not contributed that patch back upstream.

The hostapd I am running is unmodified from the 2.10 sources available from https://w1.fi/hostapd/. For both my x86-based router box and my ARM-based Raspberry Pi, I compiled hostapd from those sources using GCC 12.2.1. I could potentially try someone else's build of hostapd if you suspect a compiler bug, though again, it should not be possible for a bug in a userspace application to trigger a kernel panic.

morrownr commented 1 year ago

https://www.raspberrypi.com/software/

Hmm, I wonder if they use the kernel images from raspberrypi/firmware.

They use the kernels from the following location:

https://github.com/raspberrypi/linux

My guide takes you to the above location and walks you through compiling 6.1.

That would all be userspace, though. It shouldn't be possible for userspace to panic the kernel†.

That is the theory.

Since it is, there is definitely a kernel bug. Maybe your userspace configuration isn't triggering it, but it's there lurking.

There are a lot of kernel bugs just waiting to be discovered.

Why, may I ask? wpa_supplicant is for running in client/managed/station mode. Whether you compiled it or not has no bearing on hostapd, and you'd only need it if you were trying to implement something like a range extender where you need to bridge a managed/station interface and a master/AP interface.

You certainly may ask. I've spent a considerable amount of time since the first mt7921au based adapter was available for purchase last July working some of the issues out. Eventually users want to get all the way to where they can do WiFi 6e. WPA3 is mandatory for WiFi 6e and the version of wpa_supplicant in the current shipping RasPiOS needs to be upgraded. You may have a later version. If so, good, this does not apply to you.

The kernel there is the vanilla kernel from kernel.org,

I am very familiar with Linus' kernel. I compile it regularly for non-RasPiOS systems.

I get that you are using a custom operating system and if you give me a name to call it, I will use that name instead of distro. There is likely a difference between Linus' kernel and what I am pulling from the Raspberry Pi location that I pull from. I would say that I am pulling code with a lot of RasPi specific patches. While it might appear to be easy to blame mt7921u as being at fault for the crash you are seeing, there is one hell of a lot of interaction among the parts of the kernel.

When kernel 6.0 was released, the mt7612u and mt7610u drivers crashed. The fix took some time. The patch went into the mac80211 compoent of the stack. It wasn't the mt drivers causing the problem. It was a patch that an Intel dev made to mac80211. A Mediatek dev repatched mac80211 and fixed a few things while he was at it. No code was touched in the mt drivers but they were blamed.

I will continue to see if I can find the problem on the basis of "if I am doing something related, I'll keep an eye open" but I do not have the time to work with a custom operating system that does not use systemd. I can almost guarantee you that if you follow the path that set forth, your adapter will work. I'll bet that the seller will give you your money back for a return.

Good luck.

whitslack commented 1 year ago

Using netconsole on my RPi, I was able to obtain (at least the beginning of) a stack trace of the crash:

[  812.240667] br0: port 2(wlan0) entered blocking state
[  812.242143] br0: port 2(wlan0) entered disabled state
[  812.244562] device wlan0 entered promiscuous mode
[  812.667502] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  812.670106] br0: port 2(wlan0) entered blocking state
[  812.671736] br0: port 2(wlan0) entered forwarding state
[  823.254581] skbuff: skb_under_panic: text:bf7cd4e4 len:421 put:64 head:c6075380 data:c6075366 tail:0xc607550b end:0xc6075da0 dev:wlan0
[  823.257823] ------------[ cut here ]------------
[  823.259438] kernel BUG at net/core/skbuff.c:120!
[  823.261031] Internal error: Oops - BUG: 0 [#1] ARM
[  823.262621] Modules linked in: ctr aes_arm aes_generic ccm netconsole bridge md5 hmac nls_utf8 cifs cifs_arc4 cifs_md4 z3fold lz4 lz4_compress rpcsec_gss_krb5 iptable_filter ip_tables xt_LED ip6table_filter ip6_tables x_tables 8021q garp stp llc ipv6 mt7921u mt7921_common mt76_connac_lib mt76_usb mt76 mac80211 libarc4 sha256_generic libsha256 cfg80211 btusb btrtl btintel btbcm bluetooth bcm2835_codec(C) bcm2835_v4l2(C) bcm2835_isp(C) v4l2_mem2mem ecdh_generic ecc bcm2835_mmal_vchiq(C) videobuf2_vmalloc videobuf2_dma_contig videobuf2_memops rfkill libaes videobuf2_v4l2 videobuf2_common snd_bcm2835(C) videodev snd_pcm raspberrypi_hwmon binfmt_misc snd_timer snd mc vc_sm_cma(C) uio_pdrv_genirq fixed uio
[  823.277312] CPU: 0 PID: 1801 Comm: mt76-tx phy0 Tainted: G         C         6.1.16+ #1636
[  823.280923] Hardware name: BCM2835
[  823.282799] PC is at skb_panic+0x58/0x64
[  823.284691] LR is at skb_panic+0x58/0x64
[  823.286510] pc : [<c08c3f68>]    lr : [<c08c3f68>]    psr: 60000013
[  823.288374] sp : e0649d50  ip : 00057fa8  fp : c1b89774
[  823.290203] r10: 00000002  r9 : 00000002  r8 : 00000001
[  823.291988] r7 : c1b89908  r6 : c2961740  r5 : c2886180  r4 : c6075380
[  823.293805] r3 : 95cac319  r2 : 95cac319  r1 : e0649c88  r0 : 0000007a
[  823.295638] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[  823.297513] Control: 00c5387d  Table: 019c4008  DAC: 00000055
[  823.299352] Register r0 information: non-paged memory
[  823.301186] Register r1 information: 2-page vmalloc region starting at 0xe0648000 allocated at kernel_clone+0xac/0x31c
[  823.304701] Register r2 information: non-paged memory
[  823.306479] Register r3 information: non-paged memory
[  823.308198] Register r4 information: non-slab/vmalloc memory
[  823.309860] Register r5 information: slab skbuff_head_cache start c2886180 pointer offset 0 size 48
[  823.312977] Register r6 information: non-slab/vmalloc memory
[  823.314607] Register r7 information: slab kmalloc-4k start c1b89000 pointer offset 2312 size 4096
[  823.317712] Register r8 information: non-paged memory
[  823.319398] Register r9 information: non-paged memory
[  823.321066] Register r10 information: non-paged memory
[  823.322710] Register r11 information: slab kmalloc-4k start c1b89000 pointer offset 1908 size 4096
[  823.325903] Register r12 information: non-paged memory
[  823.327585] Process mt76-tx phy0 (pid: 1801, stack limit = 0x20ad001c)
[  823.329300] Stack: (0xe0649d50 to 0xe064a000)
[  823.330984] 9d40:                                     00000040 c6075380 c6075366 c607550b
[  823.334155] 9d60: c6075da0 c4058000 00000002 c0705174 c60a05f8 bf7cd4e4 c60a05f8 00000001
[  823.337387] 9d80: 00000002 00000000 c139a41c c347f620 bf7cd414 c2961740 00000000 c0c2f02c
[  823.340792] 9da0: 00000003 bf7a9648 c1b89774 e0649db8 c35ec928 c1b89908 00000000 00000000
[  823.344436] 9dc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[  823.348144] 9de0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[  823.351956] 9e00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[  823.355930] 9e20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[  823.360169] 9e40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[  823.364464] 9e60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[  823.368863] 9e80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[  823.373355] 9ea0: 00000000 00000000 00000000 00000000 00000000 00000000 c2886180 00000000
[  823.377893] 9ec0: 00000000 95cac319 c4058580 c1b89774 c347f620 000008c2 bf7a95b4 c2961740
[  823.382436] 9ee0: c1b8809c c2961740 c2962740 bf7906bc c1b89908 c1b89774 c1b8809c c1b89908
[  823.386976] 9f00: c2886180 c2961e90 c347f620 bf790af8 c1b89774 e0649f33 00000002 00000002
[  823.391535] 9f20: c2961740 00000000 c1b880a8 c2961758 00000093 95cac319 c2962e90 00000003
[  823.396085] 9f40: c2961740 c2961e90 c2962e90 df831e88 c1a05140 00000000 00000000 bf790c54
[  823.400630] 9f60: c2961740 c2965e90 c2961e90 bf7d34d0 c2962e90 00000001 c1a05140 bf78a668
[  823.405166] 9f80: c2a09ec0 c2bbe240 bf78a5cc c0042c84 c2a09ec0 c0042bc4 00000000 00000000
[  823.409703] 9fa0: 00000000 00000000 00000000 c0008300 00000000 00000000 00000000 00000000
[  823.414237] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[  823.418776] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[  823.423322]  skb_panic from skb_push+0x44/0x48
[  823.425691]  skb_push from mt7921_usb_sdio_tx_prepare_skb+0xd0/0x18c [mt7921_common]
[  823.430401]  mt7921_usb_sdio_tx_prepare_skb [mt7921_common] from mt76u_tx_queue_skb+0x94/0x1c8 [mt76_usb]
[  823.435133]  mt76u_tx_queue_skb [mt76_usb] from __mt76_tx_queue_skb+0x4c/0xcc [mt76]
[  823.440046]  __mt76_tx_queue_skb [mt76] from mt76_txq_schedule.part.3+0x250/0x374 [mt76]
[  823.444997]  mt76_txq_schedule.part.3 [mt76] from mt76_txq_schedule_all+0x24/0x30 [mt76]

Sure looks like an mt76 driver bug.

I do not have the time to work with a custom operating system that does not use systemd.

Perfectly reasonable. You've already devoted way more time to this than I could have asked for.

I'll bet that the seller will give you your money back for a return.

Indeed, they have already offered to accept a return, and they have even offered to extend their return window from 30 days to 90 days to see if we can get a resolution from MediaTek.

Good luck.

Thanks.

whitslack commented 1 year ago

I may dig out a spare SD card and give your guide a try. If it works, then I can probably find the root of the problem by titration.

Nope, still crashes using RasPiOS and systemd. Here's how to make it happen…

Kernel Crash in a Can 🥫

  1. Download Raspberry Pi OS Lite (bullseye, 32-bit) release 2023-02-21.
  2. Write it to an SD card. (Replace /dev/disk/… with the path to your SD card.)
    $ xzcat 2023-02-21-raspios-bullseye-armhf-lite.img.xz |
        sudo dd iflag=fullblock of=/dev/disk/… oflag=direct bs=1M status=progress
  3. Boot the SD card in your Raspberry Pi. (You'll need to have a keyboard, monitor, and Ethernet attached.)
  4. Complete the initial setup process and log in.
  5. Run this script as root. (Apologies if you have to type the hex string in by hand.)
    $ curl -L https://gist.github.com/whitslack/7e29e4f0befa9c05a4f978e652ad3433/raw/ | sudo bash
  6. Wait for the script to run. If everything worked, the last line of output you see should say Now reboot..
  7. sudo poweroff, plug in the Wi-Fi adapter, and power on.
  8. Once hostapd has started up, your client station should see a Wi-Fi network named test. Join that network. The passphrase is open session me.
  9. You'll see a crash (in mt7921_usb_sdio_tx_prepare_skb) dump to the console on your Pi.

Bonus fun: sudo rpi-update rpi-6.2.y and reboot to see a different crash (in mt7921_check_offload_capability) that prevents the wlan0 interface from instantiating at all.

morrownr commented 1 year ago

Bonus fun:

hostapd-6g.conf.tar.gz

The above hostapd.conf is proving to be very solid for up to and including WiFi 6 with my mt7921au based adapter on my Pi4B with the 64 bit RasPiOS. It might need a little tweaking but this WiFi 6 stuff is a little more complicated than WiFi 5.

I'll download and burn the 32 bit RasPiOS Lite and see where it goes. It may be sometime next week before I have time. Somewhere in this thread I think you said what RasPi hardware you have but I'm not finding it. Is it a RasPi3B?

whitslack commented 1 year ago

"6g", meaning 6 GHz, would be Wi-Fi 6E, right? "Wi-Fi 6" is just 802.11ax, which can run on either the 2.4 GHz or the 5 GHz band. I don't have any other 6E hardware to test with yet, but when I do, I'm sure I'll be coming back here for information about hostapd settings for 6E. Given the low transmit power constraints in the 6 GHz band under U.S. regulatory rules, I may not actually use 6 GHz even when I have a client device that supports it, but it'll be fun to play with.

Somewhere in this thread I think you said what RasPi hardware you have but I'm not finding it. Is it a RasPi3B?

Raspberry Pi Model B, PCB Rev 2.0. (It's the BCM2708 revision 000F with 512 MB RAM, manufactured by Qisda.) See this table. I also own an original-release Model B, PCB Rev 1.0, with 256 MB RAM, but I am not currently using it for anything.

morrownr commented 1 year ago

"6g", meaning 6 GHz, would be Wi-Fi 6E, right?

I noticed after posting the file here that my previous naming scheme was not going to work so I changed it to hostapd-WiFi6.conf. I'll use hostapd-WiFi6e.conf for 6 GHz and it is far from done. I figured I'd better get a really good example for WiFi 6 first. WiFi6e will really be a challenge.

Given the low transmit power constraints in the 6 GHz band under U.S. regulatory rules, I may not actually use 6 GHz even when I have a client device that supports it, but it'll be fun to play with.

That is an issue. I think 5 GHz and 2.4 Ghz is going to stay popular for many uses, maybe most. Interestingly, this mt7921au chipset is Wave 2 capable so if you have a wifi router that is Wave 2 capable, you can burn up the air. I see about 650 Mbps in tests.

Thanks for the info on your Pi's. I'll have to test with the 32 bit distro only as I don't have that hardware.

whitslack commented 1 year ago

Bonus fun: sudo rpi-update rpi-6.2.y and reboot to see a different crash (in mt7921_check_offload_capability) that prevents the wlan0 interface from instantiating at all.

This alternate crash appears to have been fixed. I now see the same crash on 6.2.6 as I see on 6.1.19.

morrownr commented 1 year ago

Currently my lab is packed due to a move so my options to test are limited and I been sick over the last few days,

I have burned the 32 bit RasPiOS Lite version that you said you were now using but I need time to work the issue.

I am not necessarily convinced I can duplicate it easily. In the world of bugs, we have to think about what devs are using while working and we have to consider what testers and users have as far as hardware and software is concerned. I can say confidently that almost no development and almost no testing is being done on systems with only 512 mb of ram. There is also the 32 bit issue. There is no way to avoid bit rot as far as 32 bit support is concerned but use of 32 bit kernels continues to decline and with fewer users, there is less opportunity to catch problems. I'm struggling to find hardware that is close to the situation so as to duplicate the problem. Once my lab is set up again, I can test on a 32 bit CPU system with 512 mb of ram but it is a intel CPU, not arm. RasPiOS does come in a 32 bit x86 release but will it allow me to pinpoint the problems? I don't know. This is probably a situation where the problem would have to be pinpointed and a patch submitted because the devs likely do not have the hardware to duplicate the problem.

On another subject: I have posted hostapd-WiFi6.conf in a menu item and made a couple of minor changes:

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

Look under menu item 9.

I have been testing and it seems to be very solid. It is providing WiFi 6 AP mode that is testing as rock solid here. The complexity of the hostapd.conf for WiFi 6 is a far cry from back in the WiFi 4 only days.