search

morrownr / 88x2bu

Linux Driver for USB WiFi Adapters that are based on the RTL8812BU and RTL8822BU Chipsets
435 stars 74 forks source link

(solved) Cudy WU1300S, ARM, Debian 9.3 #78

Closed nwetter2 closed 2 years ago

nwetter2 commented 2 years ago

I'm trying to get a USB wifi dongle working with our device, which uses a board called the Nitrogen6_max, running Debian 9.3 and kernel 4.9.74. We like the WU1300S because the manufacturer says they will be able to give us reports from some regulatory tests, but I've also ordered a couple adapters from your list of in-kernel adapters as a fallback or baseline. Any help would be greatly appreciated.

I install your driver without any difficulty, and I'm able to scan (nmcli d wifi list ifname $WLX), but when I try to connect (nmcli d wifi connect $SSID password $PASS ifname $WLX), I get Error: Connection activation failed: (7) Secrets were required, but not provided.. journalctl reveals the following messages, which support a problem with credentials:

Aug 09 15:01:00 nitrogen wpa_supplicant[586]: wlxb44bd62b497a: CTRL-EVENT-DISCONNECTED bssid=2c:4d:54:5c:f2:50 reason=15
Aug 09 15:01:00 nitrogen wpa_supplicant[586]: wlxb44bd62b497a: WPA: 4-Way Handshake failed - pre-shared key may be incorrect

However, I know the credentials are good because I can connect with no trouble using the same exact command, but with the onboard interface instead of the Cudy (nmcli d wifi connect $SSID password $PASS ifname wlan0)

nwetter2 commented 2 years ago

After enabling logging in the driver's config, I was able to get a little bit more info on the 4-way handshake:

[  156.026526] RTW: recv eapol packet 1/4
[  156.028131] RTW: send eapol packet 2/4
[  157.028433] RTW: recv eapol packet 1/4
[  157.029113] RTW: send eapol packet 2/4
[  157.607268] RTW: Turbo EDCA =0x5ea42b
[  158.027552] RTW: recv eapol packet 1/4
[  158.028235] RTW: send eapol packet 2/4
[  159.028301] RTW: recv eapol packet 1/4
[  159.028991] RTW: send eapol packet 2/4
[  159.296593] RTW: rtw_aes_decrypt(wlxb44bd62b497a) no_gkey_bc_cnt:3, no_gkey_mc_cnt:0
[  162.029497] RTW: OnDeAuth(wlxb44bd62b497a) - Start to Disconnect
[  162.029544] RTW: OnDeAuth(wlxb44bd62b497a) reason=15, ta=2c:4d:54:5c:f2:50, ignore=0
[  162.029563] RTW: receive_disconnect

Seem to be failing on the first response, which would make sense if they key was incorrect, but the onboard wifi works fine with the same key.

bernhara commented 2 years ago

May be my problem is related...

I'm using a Raspberry PI as hostspot with an EasyULT wifi dongle. After a long time an many hesitations in configuring the parameters for hostapd, I got a working AP.

However, while all my devices (PC, tablet, ...) are able to connect to the AP, my Samsung A40 is behaving in a strange way. I get many authentication errors and I have to insist to connect that phone. After forcing 4 or 5 times the connection on the phone, it finishes to connect to the AP.

I've no idea what can lead to this kind of behavior. May be bad delays or timing in the frame exchanges...

nwetter2 commented 2 years ago

At least with my issue, it doesn't appear to be related to timing. I'm looking at the packets in Wireshark, and the Cudy is responding with message 2 faster than the onboard module which authenticates successfully. My hypothesis is that something in message 2 is incorrect, so I'm working on verifying that content. Below, packets 1-4 are a successful authentication using the onboard module, and 32 on are the attempts by the Cudy. eapol

nwetter2 commented 2 years ago

Using this Python code, I first verified the MIC from the successful handshake using the onboard wifi module, then I found that the MIC sent by this driver is incorrect:

SSID/PASS:  nate-HP-EliteBook-840-G3 / riZls0ZD
PMK:        ccd9fa13bfad7851bee9beccfbf12fb00248a00469a0baf283508fbbbb200dca
AP-MAC:     f4:8c:50:0f:d5:9d
STA-MAC:    b4:4b:d6:2b:49:7a
AP-NONCE:   206432e0db5d53cca265fce2b0b7cd56a32ce11e990092eaf303bd90ec04a471
STA-NONCE:  28db48651a06efb39e90fbd2a2d091cc74e1abc0c7b05fdfeecc7f9e6a4a3dd4
KCK:        ec44ec95fe1249f38f7d42027dca99a9
MIC-found:  7e83e03672a610a62864723acffd34b7
MIC-calc:   95b39e691659b41d147d141b8c83d505
Result:     ERROR: MIC does not match

@morrownr This is pretty far out of my domain of expertise. Does it surprise you? Is there reasonable hope for fixing it or should I move on and explore other options? I tried a couple adapters from your in-kernel list and didn't have much luck on this platform. Today I ordered a couple from your list of those that have been tested with this driver. It would be great if we could get this adapter working though because Cudy will give us the regulatory test reports.

morrownr commented 2 years ago

@nwetter2 Just found time to stop by. This is interesting. I see a lot of moving parts here. It may take me a while to wrap my mind around this. Here are some random thoughts and questions:

This wifi stuff is about as complicated as anything I have ever worked with. When I started this project I had to blow the dust off of my old C books. I have found that it can take a long time to get to the bottom of some things.

No, not at all. Working on these Realtek drivers has motivated me to encourage folks to take a hard look at adapters that use in-kernel drivers. A few months back another guy here and I worked on trying to get WPA3 working on these Realtek drivers. He got it working but it is not something we can add or support because it required many changes to things external to these drivers. These Realtek drivers have a lot of non-standard things going on. It would be nice if Realtek would build standards compliant drivers and work them into the kernel.

I have some other irons in the fire but I'll try to help as I can. I'd really like to know which adapters you got that use in-kernel drivers.

nwetter2 commented 2 years ago

I think you mentioned you are using kernel 4.9. Some of the drivers for adapters on my in-kernel list did not make it into the kernel until 4.19 (2018). I can probably be of help sort what works with what but... what is the reason for using a kernel as old as 4.9?

We use operating system images from Boundary Devices, the manufacturer of our single board computer. When we started the project, Debian 9 with kernel 4.9 was the newest they offered. Since then they have released a Debian 10 image, but it's still only kernel 4.14. I'm sure at some point we will have to upgrade, but the main reason for not doing so has been the technical burden I anticipate getting everything to work after, especially with the Linux device tree and an in-kernel device driver I've customized. There would also be some regulatory over head as we are a medical device.

Our CPU is a 32-bit armV7

Other adapters I've played with: Cudy WU650 Panda PAU03 Linksys AE6000 tp-link Archer T2U nano

I haven't completely ruled these out, but when I hit blocks I came back to the WU1300S, which I've put the most time into so far.

I have a TRENDnet TEW-808UBM coming tomorrow. I ordered a TP-Link Archer T3U but didn't realize until now that it's backordered.

morrownr commented 2 years ago

The situation is starting to clear up. I have a good understanding of some of the issue you are or will have to deal with.

It appears from your list that you want a nano or thumb sized wifi adapter. The Linksys AE6000 is a dandy small adapter but the mt7610u driver first appeared in the Linux kernel with v4.19 so you would have seen nothing with kernel 4.9. There are backports available but it would need to be investigated.

The Panda PAU03 should work with 4.9. What did you see?

What are your requirements? 5 GHz / 2.4 GHz ? WPA3?

How locked down will the system be? The reason I am asking is that if it is a system that does allow security updates, you need to carefully consider the implications of using Realtek drivers.

nwetter2 commented 2 years ago

Looking closer at the Panda PAU03, I'm getting a different sort of error:

debian@nitrogen:~$ sudo nmcli d wifi connect $SSID password $PASS ifname $WLX
wlx9cefd5fac64d
Error: Connection activation failed: (53) The Wi-Fi network could not be found.

I'll start my dive into that tomorrow.

We'd be fine with 2.4 GHz and WPA2.

The system will be completely locked down and the only updates will be full partition images that come from us.

Thanks so much for the help!

morrownr commented 2 years ago

So, 2.4 GHz, WPA2 and very small. Probably also "runs cool and 24/7/365 rock solid".

I have a Panda PAU03. I can do some testing if you can provide enough info for me to duplicate an AP. I have an old notebook system with kernel 4.9. I've used the little Panda for a long time. It is solid and it even supports WPA3.

Let me know if I can help.

morrownr commented 2 years ago

Quote: "Error: Connection activation failed: (53) The Wi-Fi network could not be found."

I know you know this but I'm going to say it anyway:

When I see the error above, I run:

$ nmcli dev wifi list

...to make sure the adapter is seeing mySSID. If it is showing a good signal, you might try without variables:

$ sudo nmcli dev wifi connect mySSID password 'myPassword' ifname 'wlxabcdabcdabcd'

I tested the little Panda here with kernel 5.11 and all worked fine. I'll try to dig out the system with kernel 4.9 tomorrow.

nwetter2 commented 2 years ago

A colleague remembered that we have seen this behavior before, and the solution is to add these two lines to /etc/NetworkManager/NetworkManager.conf:

[device]
wifi.scan-rand-mac-address=no

And just like that, it's working! Thank you so much for the help!

morrownr commented 2 years ago

I had forgot all about that. I haven't seen that in a long time.

Glad you have the little Panda going.