(Realtek has to fix this, good luck finding a way to report it) No luck on connecting a WPA3 AP when it performs as a client on raspberry pi 4B

[kkbyron]

wpa_supplicant version is 2.8-devel by default along with latest raspberry pi OS. Not sure if this is a known issue or not.

WPA3-SAE (Personal) is listed as part of features though it's not mentioned in client mode... need some help and clarity here.

BTW, gave it a try on macOS driver provided by Dlink https://support.dlink.com/ProductInfo.aspx?m=DWA-181-US on my macbook and both my Dlink DWA-181 and TPlink T3U were able to connect the same WPA3 AP.

[morrownr]

It is a known issue as it has been in discussion in another of my repos here. Realtek says WPA3 is supported. I have been working to find out why we are not seeing good results. I don't have a router capable of WPA3 at this time so I have an rpi4b setup with hostapd serving as a bridged access point. I'm working the issue but it is not clear to me what the problem is. If you run across any info that could help, let me know.

[kkbyron]

@morrownr , thanks for quick reply.

Here's what I got during wpa_supplicant bringing up when debug log level is enabled.

_nl80211: Set mode ifindex 4 iftype 2 (STATION) nl80211: Subscribe to mgmt frames with non-AP handle 0x1715f10 nl80211: Register frame type=0xb0 (WLAN_FC_STYPE_AUTH) nl_handle=0x1715f10 match= nl80211: kernel reports: Authentication algorithm number required nl80211: Register frame command failed (type=176): ret=-22 (Invalid argument) nl80211: Register frame match - hexdump(len=0): [NULL] nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0x1715f10 match=0104 nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nlhandle=0x1715f10 match=040a

Looks like the WLAN_FC_STYPE_AUTH is not registered successfully, and reference code https://elixir.bootlin.com/linux/latest/source/net/wireless/mlme.c helps indicate that cfg80211_mlme_register_mgmt() got failed.

wpa_supplicant was still up and running but such error could always be seen. A concern here that how MFP/PMF works in this case.

And here's the ultimate error that blocks the authentication/association,

_SAE: own commit-scalar - hexdump(len=32): c1 31 17 39 76 e9 fa 6c 25 45 55 0b 51 9b b7 59 8c 4c 34 c2 65 db 1b d9 49 e5 81 fb a1 de 2a 3e SAE: own commit-element(x) - hexdump(len=32): d5 b8 fb 41 a4 16 d2 9c cb ef cc 17 2d 94 f4 3e 7c 93 77 36 f9 f8 48 da 1d 36 3d 4b 40 83 41 b1 SAE: own commit-element(y) - hexdump(len=32): f7 ed 68 b5 97 d1 fb d2 22 6b 12 91 e5 d1 5d b0 f5 e7 e2 21 b4 40 6c 39 65 b1 92 50 34 59 ad ca nl80211: send_mlme - da= e4:bf:fa:fe:80:b9 noack=1 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0xb0 (WLAN_FC_STYPE_AUTH) nlmode=2 nl80211: send_mlme -> send_frame nl80211: send_frame - Use bss->freq=0 nl80211: send_frame -> send_frame_cmd nl80211: CMD_FRAME freq=0 wait=0 no_cck=0 no_ack=1 offchanok=0 CMDFRAME - hexdump(len=128): b0 00 00 00 e4 bf fa fe 80 b9 f0 b4 d2 b1 4f 30 e4 bf fa fe 80 b9 10 00 03 00 01 00 00 00 13 00 c1 31 17 39 76 e9 fa 6c 25 45 55 0b 51 9b b7 59 8c 4c 34 c2 65 db 1b d9 49 e5 81 fb a1 de 2a 3e d5 b8 fb 41 a4 16 d2 9c cb ef cc 17 2d 94 f4 3e 7c 93 77 36 f9 f8 48 da 1d 36 3d 4b 40 83 41 b1 f7 ed 68 b5 97 d1 fb d2 22 6b 12 91 e5 d1 5d b0 f5 e7 e2 21 b4 40 6c 39 65 b1 92 50 34 59 ad ca nl80211: Frame command failed: ret=-22 (Invalid argument) (freq=0 wait=0)

wpa_supplicant gets SAE scalar and etc prepared and tried to send the SAE commit and somehow I don't think it sends out by any chance...

Hope your comments.

[morrownr]

After your report yesterday I came up with a plan to narrow things down a bit. I had ordered a new adapter and it came in a couple of days ago. It is an adapter based on the mt7612u chipset. That makes to two adapters that I have based on that chipset now which allows me to totally take Realtek out of the testing if I need to do so. Here is the setup and what I found:

Access Point: Raspberry Pi 4 with up to date Raspberry Pi OS. It runs hostapd and uses the onboard wifi for 2g and a AC1200 mt7612u based adapter for 5g.

Client: Desktop system using a Alfa AWUS036ACM, also a mt7612u based AC1200 adapter, for wifi. OS is Ubuntu 20.10.

Result: When hostapd used settings for WPA3-SAE only, I had a solid WPA3 connection. It worked flawlessly. I then tried to connect other systems to the access point. The other systems were using Realtek drivers for the wifi. None would connect.

I then dropped the settings in hostapd down to WPA3 transitional which means WPA2 is allowed if that is all that a client supports. Same result. The only client that would connect is the one with the mt7612u chipset and in-kernel driver.

The result tells us something. The operating systems used during testing are capable of WPA3. That includes the current 32 bit version of Raspberry Pi OS and Ubuntu 20.10. Tests when drivers on the access point and client systems were the my7612u driver, WPA3 always worked. When the client system used a Realtek driver, no go.

Conclusion so far: The Realtek drivers are not supporting WPA3 right now. This very disappointing. The 5 Realtek drivers that I maintain here are all the most recent versions that I can find. We have no idea when or if Realtek will release new versions since they do not publish a schedule and for that matter, they do not even release the drivers to the public.

I changed the README. I appreciate the info you sent and I will try to use it but this could take some time if we can solve it at all. I am going to wax poetic for a moment...

I support systems with a variety of wifi adapters. Over the last few months, it has become apparent to me that the majority of people using Linux and WiFi adapters would be better served using Mediatek based adapters rather than Realtek. The Mediatek drivers are in-kernel and are Linux WiFi standards compliant. This is how it should be done. I recently started the following site to help folks find adapters that use in-kernel drivers:

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

The AC1200 class adapter that I recommend is the Alfa AWUS036ACM.

Probably more than you wanted to know.

[kkbyron]

@morrownr , thx a lot for letting me know. Definitely I'll give it a try on the working one and it may ease me quite a bit. :)

One more thing that I've mentioned and would like to bring attention to you again though it has nothing to do with linux driver you maintain here. The mac OS driver I got from Dlink webpage for DWA 181 actually works well when connecting to a WPA3 AP... So it comes to me that it should work but somehow sth messes up.

Feel free to close the issue here and I'll keep you posted if I have any progress.

[morrownr]

Thanks for the info on the MAC OS driver. The more information we have, the better. I'm going to leave this open for now so information can be added.

[kkbyron]

Got the alfa AWUS036ACM handy and gave it a try...Connected as WPA3 client smoothly but a bittersweet part is that it can't hold long if there's other usb hub connected on my rpi 4b, more likely a power management issue but overall it matches my expectation. Thx again.

And then I compared the wpa_supplicant logs between good mediatek and bad realtek. The significant diff between two in terms of wpa_supplicant area is that mediatek is SME enabled while realtek is SME disabled. So the whole path for these two is totally different when authentication needs to happen. I guess that's the benefit for so-called in-kernel driver and it deals with those parts itself or more...

I took a look at os_dep/linux/ioctl_cfg80211.c in 88x2bu driver and the cfg80211_rtw_auth/cfg80211_rtw_assoc are commented out and looks like there's only one way to go with cfg80211_rtw_external_auth(). Will have a deep dive next week and see anything we may do to turn it around.

If alfa doesn't have power management issue, I may embrace it and can't get out of that... but now I'm still looking forwarding to bringing realtek up cuz its size and potential non-compatibility issue on power management. :)

[morrownr]

Try testing that Alfa ACM without the powered hub connected. The RasPi4b does not work well with most powered hubs because of backfeeding. Also, one other thing I have noticed is the onboard wifi is making for some ugliness in dmesg. In fact, there is other ugliness. It seems the 4b is somewhat of a mess right now. Hopefully the foundation will get it cleaned up. Here are the changes I have made to config.txt. Some are just to save power, some are to clean up ugliness in config.txt:

#dtoverlay=vc4-fkms-v3d
#max_framebuffers=2

# turn off Mainboard LEDs
dtoverlay=act-led

# disable Activity LED
dtparam=act_led_trigger=none
dtparam=act_led_activelow=off

# disable Power LED
dtparam=pwr_led_trigger=none
dtparam=pwr_led_activelow=off

# turn off Ethernet port LEDs
dtparam=eth_led0=4
dtparam=eth_led1=4

# turn off Bluetooth
dtoverlay=disable-bt

# turn off WiFi
dtoverlay=disable-wifi

# turn off onboard audio
dtparam=audio=off

# overclock CPU
over_voltage=1
arm_freq=1600

A really good thing about the Alfa ACM and use on RasPi4b's is that it uses less power than other AC1200 classes adapters. I have measured it to use 180 mA to 380 mA. I can run mine also with a SSD directly from the Pi USB 3 ports and that just can't happened with adapters based on 8814au and 8812au as they can and do pull 800+ mA.

I have not seen an power management or power saving issues witn my Alfa ACM. I will be interested to see what you find when you have time to take a deeper dive into the Realtek driver.

[kkbyron]

@morrownr Thanks for the info, will give it a try.

It's a beautiful day cuz my tplink t3u is able to connect to my WPA3 AP!!! I don't have proper fix yet but will provide info here at first and definitely we'll come up with a plan shortly.

First of all, major issue happens at line #7614 of https://github.com/morrownr/88x2bu/blob/5.8.7.4/os_dep/linux/ioctl_cfg80211.c. wpa_supplicant won't have freq info when sending back the NL80211_CMD_FRAME msg. Since wpa_supplicant is more common and I'm not quite sure if it's capable of freq info, I prefer to have change in 88x2u driver. Now I hardcoded the freq in use to get it going but I assume it should be easy to figure out the freq in use automatically in driver level. Yet to have official change for this.

Secondly, rekey offload is supported when CONFIG_GTK_OL is enabled. I added in Makefile and rebuilt .ko gives me the WPA3 connection right away.

That's all I have at the moment, may miss sth up in wpa_supplicant that I'm not aware of. I'll enjoy the rest of my weekend and wrap up later.

[kkbyron]

Almost forgot the piece that I doubted from very the beginning.

Most importantly, "Authentication algorithm number required" indicates that algorithm needs to be explicitly registered and I assume this needs a fix from wpa_supplicant world, will try to reach out to them.

The change is shown as below for reference,

wpa_supplicant.txt

[kkbyron]

Reached out to Jouni Malinen j@wi.fi and got the answer with an official fix as below, https://w1.fi/cgit/hostap/commit/?id=d046f2a9f93691215ed112080abd0954557cd90c

I guess we're on the right track.

[morrownr]

Great work! I will jump in as I have time this week to see if I can add anything that can help us get to a fix.

[kkbyron]

Here's the wrap up for this ticket,

We should have more changes from wpa_supplicant instead of this driver. :) This is all we need on driver level, just need to enable one more config and that's it. 88x2bu.diff.txt

And... regarding the outstanding issue I mentioned yesterday, I ended up with a fix on wpa_supplicant and this time I reviewed all previous changes on master branch of wpa_supplicant and again found out that was addressed by this https://w1.fi/cgit/hostap/commit/?id=aad414e956fdb463d3b45eb61c42792bf0c9f558 already, it exactly matches what I've found. Unfortunately this patch can't be applied on either wpa_supplicant 2.8 or 2.9 cuz master branch just goes too far.

After reviewing the master branch thoroughly, I do believe we will get benefit in terms of feature support but no idea on stability... So here's my solution if you don't like to have up-to-date master branch of wpa_supplicant,

• Download latest stable release of wpa_supplicant, https://w1.fi/releases/wpa_supplicant-2.9.tar.gz
• Applied the original patch to fix mgmt registration issue, https://w1.fi/cgit/hostap/commit/?id=d046f2a9f93691215ed112080abd0954557cd90c
• Applied my patch to fix freq info issue, add_freq_info.diff.txt

I also made some alternatives on my raspberry board to make sure wpa_supplicant I built will be the one in use on system level, should be easy for anyone interested in this.

And I've done some sanity test like turning on/off my AP and looks like my tplink t3u could always keep up with that and by far I didn't have any issues. Again, master branch of wpa_supplicant provides way more fixes and features than I initially thought but I'll go with stable release at the moment. May switch to that if something else pops up. Cheers.

[morrownr]

I have applied your suggested changes to the Makefile for this driver. I have pushed the changes so I need to go do some sanity checking. I learned a long time ago that we have this thing called the law of unintended consequences. This repo gets a lot of hits.

I'm not checking function. I am only checking that something else is not broken. I'll get back to you when I have time to function test. You appear to have done good work and it is much appreciated.

Tell me this: Why is the mt7612u driver working with existing wpa_supplicant and the Realtek drivers are not. That sort of tells me that there is a way to fix this with just changes to this driver. Thoughts?

[kkbyron]

Here's my understanding,

mt7612u gets supported cuz linux kernel accepts mt76x2u.ko as part of main stream and it's supposed to support SME(station management entity) though I don't have source code to verify.

wpa_supplicant code relies on snippet below to detect if there's SME,

if (info->auth_supported)
    drv->capa.flags |= WPA_DRIVER_FLAGS_SME;

So for me, the SME capacity depends on whether auth/assoc is supported in driver level and I see both are disabled in os_dep/linux/ioctl_cfg80211.c depsite it's in the scope of CONFIG_AP_MODE.

One more thing is that we could dump phy info by "iw phy phyX info" and check out "Supported commands:" area. If auth/assoc doesn't exist, most likely it will call external auth and wpa_supplicant will take care of that. I also mentioned earlier that "The significant diff between two in terms of wpa_supplicant area is that mediatek is SME enabled while realtek is SME disabled. So the whole path for these two is totally different when authentication needs to happen."

[kkbyron]

@morrownr I'll wait for your results till you changed the README.md to claim we're good on WPA3.

Hate to see "Note: WPA3-AES does not appear to be working." under this project. :)

[morrownr]

@kkbyron

I did not see any unwanted problems as a result of the changes to the Makefile. I need to take time now to fully process everything you discovered.

Something that might be of interest to you is this site:

https://github.com/neojou/rtw88-usb

What has happened at that site is the author cloned the rtw88 driver from the kernel and has added usb support. I am hopeful that we see in-kernel support for this chipset at some point. In-kernel support for this chipset will not come from the driver we are working on here as it is nowhere near Linux Wireless standards compliant. On the other hand, the support in rtw88 is standards compliant and the 8812bu basically just needs usb support added, which is what was taking place at the above link.

I haven't had time to check out the above rtw88-usb driver but if you happened to have time to check it out and give us a report, that would be great.

[kkbyron]

@morrownr

Thanks for letting me know. Actually I happened to check out the repos you mentioned here and noticed that rtw88 is part of master branch of linux kernel and for sure it's not finished yet.

However, it turns out to me that the owner of https://github.com/neojou/rtw88-usb is a realtek employee and I assume all experimental changes they've done out there MIGHT be contributed back or upstreamed. It sounds interesting but I'm not a big fan of that...

I'd rather see that they make it more publicly instead of this... that's just my two cents...

[morrownr]

@kkbyron

Back on the primary topic and back to work. I had been busy with other things.

As I took a fresh look at this thread, I decided to start documenting what we are doing so as to eventually condense it down to something other uses can do. I will post the documentation for you to look at as progress is made.

I have already committed the changes you recommended to the Makefile.

It seems now, correct me if I am wrong, that replacing wpa_supplicant with the current master is what is required. I lean toward that approach as opposed to patching the code of a release. Maybe I will change my mind as I work through the process.

Have you only tested with the Raspberry Pi OS?

[kkbyron]

@morrownr

Agreed and a recommendation on master or wpa_supplicant will be straightforward.

Unfortunately I don't have any pc and I only tested with Raspberry Pi OS.

[morrownr]

Yes, I am looking for the most straightforward solution possible. You and I may like to fiddle around with the complicated stuff but most users will appreciate a simple solution spelled out in a simple way.

After I have tested on the Raspberry Pi OS and we agree on simple documentation, I will then test on other platforms and let you know.

[morrownr]

@kkbyron

I'm running into a problem compiling wpa_supplicant on x86. Here is where it runs into trouble:

CC ../src/utils/radiotap.c CC ../src/drivers/linux_ioctl.c CC ../src/drivers/driver_wext.c CC ../src/drivers/drivers.c CC ../src/l2_packet/l2_packet_linux.c /usr/bin/ld: cannot find -lnl-route-3 collect2: error: ld returned 1 exit status make: *** [Makefile:1893: wpa_supplicant] Error 1

I'm going to have very limited time over the next few days to work this issue. Any information you can provide will be welcome.

Nick

[kkbyron]

Yep, I've seen this as well and "sudo apt install libnl-route-3-dev" may help.

Somehow this error happens without recommendation like sth else.

[morrownr]

Good job. I installed "libnl-route-3-dev" along with the other hostapd/wpa_supplicant dependencies and I now have a clean compile. In the doc file so far I am showing the following for dependencies:

$ sudo apt install build-essential libssl-dev pkg-config

$ sudo apt install dbus libdbus-1-dev libdbus-glib-1-2 libdbus-glib-1-dev

$ sudo apt install libreadline-dev libncurses5-dev

$ sudo apt install libnl-genl-3-dev libnl-3-dev libnl-route-3-dev

I have installed and tested but the test failed. My test systems:

AP: RasPi4b running hostapd with a mt7612u based adapter. I started with settings for WPA3 Transitional but it failed.

Client: Desktop running Linux Mint 20.1 and adapter based on a rtl8812bu chipset.

Comments: I know the AP is capable of WPA3 because it will do WPA3 with another system running another adapter based on a mt7612u chipset and it will work with my phone. I was careful to ensure I that I used the current driver here that has the mods to the Makefile. As I have time I will start working my way through log files on the failing client.

Your successful test was using a RasPi4b as the client. What are the relevant differences between the RasPiOS/Debian and Linux Mint/Ubuntu? If anyone has anything to add, please do as my time to work this issue is somewhat limited over the next few days.

[morrownr]

I am working on this issue again. I am hoping to make more progress by switching some things. I am working on the 8812au driver and am using Kali x86 as the client. Kali is close to Debian as is the Raspberry Pi OS. If I get things sorted out there, then I hope to port the fix to the rest of the drivers here.

[morrownr]

This issue should be solved now.

[beadon1]

given that wpa_suppliocant official page sees abandoned at https://w1.fi/wpa_supplicant/. is there any effort to maintain it for regular updates to fix something like this issue ?

[morrownr]

wpa_supplicant is actively developed. In fact, the current master of wpa_supplicant is fixed for this issue and the newest driver is fixed for this issue also. You can find the link to the new driver at the top of the README for this driver.

[beadon1]

oh ! Thanks for the update. I will check in to see how I can snag the latest - I'll need to spend a few mins dependency chasing, butthings didnlt work out-of-the-box with raspi /raspbian. So I suspect these updates haven't been pulled in just yet.