search

morrownr / USB-WiFi

USB WiFi Adapter Information for Linux
2.48k stars 167 forks source link

(info) Need Testers for hostapd-WiFi6.conf #227

Open morrownr opened 1 year ago

morrownr commented 1 year ago

I have posted an example hostapd.conf for WiFi 6 for mt7921au based USB WiFi adapters:

https://github.com/morrownr/USB-WiFi/blob/main/home/AP_Mode/hostapd-WiFi6.conf

There is also a link on the Main Menu.

I have been working on this for a while. WiFi 6 is complicated. It will take some time to optimize this hostapd.conf example for the various situations where it can be used so I am asking everyone that has the time and capability to test and recommend improvements to the file.

One of the problems with moving to WiFi 6 is there have been no examples to follow so we are having to develop the examples ourselves.

Note that this is not for WiFi 6e (6 GHz). That will be even more complicated. If anyone would like to work with me on developing an example WiFi 6e example hostapd.conf, please let me know.

@morrownr

fhteagle commented 1 year ago

I'll give it another shot here soon, now that some other higher priority projects are better in hand.

morrownr commented 1 year ago

@fhteagle

Thanks. I think if enough of us work with it, we can get a good solid example available for others to use.

fhteagle commented 1 year ago

I did give your conf file a test against a CF-953AX making the AP, while using my android phones and laptop with MT7921K as STA. AP mode worked with quirks on both an x86_64 (kernel 6.2.y) and a raspberry pi 4 (kernel 6.1.y) host, each running a compiled hostapd from updated git sources.

80MHz channel, WPA3, and HE channels all confirmed. Link rates were upper 400's to as high as 867 with signals varying from -55 to -40 on various devices. However, actual throughput measured by iperf3 is only high 100's to low 200's mbps in both directions. This is consistent with other MT7921 based devices I have tested hostapd with, unfortunately.

I could not test bridging without trashing my network that other people are using in the house, so later on for that.

Having very weird intermittent packet fowarding issues. Works for the first connection after hostapd is stood up, but after any STA disconnects and reconnects for any reason, packet forwarding is nil. Kill hostapd, restart, reconnect, packet forwarding is back until the next STA disconnect. Not an issue with your .conf I do not think, but still a showstopper from using a CF-953AX as a daily driver AP source for sure. I do not have the same problem on an MT7921K that is making a pretty solid 2.4ghz AP for me for the last few months. Weird.

fhteagle commented 1 year ago

Bridging is definitely working for sure, by the way.

Also, I think you should add:

ctrl_interface=/var/run/hostapd
ctrl_interface_group=0

The hostapd_cli tool does not seem to work without those lines in the .conf

morrownr commented 1 year ago

Bridging is definitely working for sure, by the way.

Good

Also, I think you should add: ...

Both have been added. I just merged a patch that includes the lines you requested and it has some tweaks so you may need to check the patch.

AP mode worked with quirks on both an x86_64 (kernel 6.2.y) and a raspberry pi 4 (kernel 6.1.y) host, each running a compiled hostapd from updated git sources.

Remember to make sure and keep your two wifi firmware files up to date. New versions have been coming monthly and we just got updates.

80MHz channel, WPA3, and HE channels all confirmed.

Hold on a minute. We are working a hostapd.conf for WiFi 6, not 6e. We can work 6e after this file is stabilized... please.

actual throughput measured by iperf3 is only high 100's to low 200's mbps in both directions. This is consistent with other MT7921 based devices I have tested hostapd with, unfortunately.

We need to get to the bottom of this. This happens when the cf-953ax is in AP mode on RasPiOS?

fhteagle commented 1 year ago

"Hold on a minute. We are working a hostapd.conf for WiFi 6, not 6e. We can work 6e after this file is stabilized... please."

HE, as in HE-MCS as in 802.11ax features, which work on 2.4 and 5Ghz also... I was not referring to 6E /6Ghz.

Will update firmware and benchmark the CF-953 again.

morrownr commented 1 year ago

HE, as in HE-MCS as in 802.11ax features, which work on 2.4 and 5Ghz also... I was not referring to 6E /6Ghz.

Ah, okay, I reread what you said and I'm good. I'm a little jumpy about 6 GHz as that is a little more challenging.

morrownr commented 1 year ago

I am seeing solid results from the version that is up now: # 2023-04-15

fhteagle commented 1 year ago

The #Security section of the file is a bit hard to parse the comments / what should be on for WPA2/Transitional/WPA3. What about rearranging the #Security section to be organized as:

morrownr commented 1 year ago

I just merged some serious readability improvements, especially to the Security section.

Tell me what you think.

I'll start testing the new 2023-04-17 version now. The changes should not have affected any settings but stuff happens. I have seen superb stability and operation since the 2023-04-15 version. Let me know if you see other improvements that can be made.

fhteagle commented 1 year ago

I pulled my files up to match yours, pulled the latest .bin firmwares, re-complied hostapd with latest, etc...

With the RZ608 (MT7921K) in the NGFF slot of my x86_64 machine running arch, great stability, multiple days of uptime with really no issues.

With the CF-953AX (MT7921AU) in the rpi4 running rpiOS Buster, I get single digit hour stability, maybe low double digit hours if I'm lucky. Nothing in dmesg or journalctl -r that indicates why the adapter is going away temporarily (even with logger_syslog_level set to 0 for most verbose output), but that's what appears to be happening. No idea if it is a USB bus reset, or a kernel driver hiccup, or something else. Pretty annoying.

morrownr commented 1 year ago

With the CF-953AX (MT7921AU) in the rpi4 running rpiOS Buster, I get single digit hour stability...

Try using a USB2 port with the cf-953ax. That would help eliminiate USB3 as a factor.

I have seen and experienced a lot of issues with the USB3 hub in the Pi4B over the last few years. Pretty annoying.

With the RZ608 (MT7921K) in the NGFF slot of my x86_64 machine running arch, great stability, multiple days of uptime with really no issues.

I think hostapd-WiFi6.conf may be getting close to being stable. Hopefully the security section is more understandable now. Are there other sections that need better documentation or orgnization?

fhteagle commented 1 year ago

You were right, the USB2 port of the pi is much more stable. 24 hours and counting so far. Never got that long on the USB3 port.

Security section is more legible than before, yes. We could probably do more to demark the sections visually, such as ####### or writing section labels in all caps. But those are minor improvements for whenever.

I would be interested in trying to tackle improved performance in the Wifi6 config file also. I really have not seen it select higher than HE-MCS 6 or so between two RZ608s or an RZ608 and CF-953. I wonder if there is option(s) missing from the file preventing it from going up to HE-MCS 11 with 1024QAM.... Or does that require 160MHz channels from a MT7922 chip?

morrownr commented 1 year ago

the USB2 port of the pi is much more stable.

Yup. That makes it look like the Pi4B is the problem. It seems that the faster the adapter, the less likely it is to be stable in a USB3 port on the Pi4B. My Alfa ACM is totally stable but an adapter based on the rtl8812bu is not. Both are AC1200 devices but the rtl8812bu adapter is what I will call a 2nd generation of AC1200 adapters and it is somewhat faster.

The mt7921au chipset is really fast. I don't know what to do as I think the usb3 hub chipset is to blame and it may not be correctable in the driver. My opinion is that RasPi may have simply made a mistake in their hardware selection.

We could probably do more to demark the sections visually, such as ####### or writing section labels in all caps.

I'll keep that in mind.

I would be interested in trying to tackle improved performance in the Wifi6 config file also. I really have not seen it select higher than HE-MCS 6 or so between two RZ608s or an RZ608 and CF-953.

It very well may be settings. I'll keep working on it.

bjlockie commented 1 year ago

The good news is VIA is working on a firmware fix for the raspberry pi4 usb chipset. I wouldn't hold my breath though because they've been saying that for years. Broadcom stuff was a bad choice but I think the raspberry pi engineers are former Broadcom employees. Choosing a VIA chipset was a poor choice but maybe it was really cheap.

morrownr commented 1 year ago

Broadcom stuff was a bad choice.

Truer words have never been spoken.

Choosing a VIA chipset was a poor choice.

Same here.

The good news is VIA is working on a firmware fix for the raspberry pi4 usb chipset.

I'm not going to hold my breathe while we wait. However, that would make it seem that the RasPi engineers are aware of the issue so maybe the RasPi5B will have some better hardware in it. That VIA usb3 hub chipset sucks.