CTRL-EVENT-ASSOC-REJECT status_code=16 #38
Comments
|
Is there anybody who can comment on this issue? The wifi experience on the cm4 is really really bad. We have so many customers complaining with all kinds of issues. So the above is the not the only problem. |
|
The problem with many of these reported WiFi problems is that they lack sufficient information to reproduce them - as you say, it depends on the environment, and clearly our environments don't tickle the problem. One thing that might be worth a try is disabling the firmware's roaming capability. Does adding |
|
Oh I have already done that. Doesn't make any difference. We have thousands of customers, so they have many diverse wifi environments. I personally also don't have the problem, so it does seem to be environment related. But one of my colleagues has the problem on a daily basis. It manifests in a different way, but it mostly comes down to 4way handshake problems. And I think they almost always originate in the wifi driver. We are already testing the newly released infineon driver but that doesn't improve the situation. This is one of the other failures: This apparently means that the client (cm4) did not respond to one of the first messages of the handshake. |
|
This sums the situation up pretty well: https://rachelbythebay.com/w/2023/11/06/wpa3/ How can you start selling a brand new product with a driver that is so extremely outdated and bad? Raspberry Pi really needs to make a proper plan for this and get Infineon on board in updating this driver to the latest standards. |
@pelwell Using a RPi 0W2 with the latest 64bit image (tried both desktop & lite) I can consistently reproduce this error trying to connect to 3 different Mikrotik devices running two different software versions (routeros latest v7 using wifiwave2 & latest v6). The 0W2 connects fine to a hotspot on my phone, but I just cannot connect to any of those 3 Mikrotik ap's. The only thing the mikrotik devices report is that
After much more searching I came accross this SO, and indeed turning off fast roaming & disabling SAE for the brcmfmac module made the 0W2 finally connect succesfully |
|
@pimlie Thx, it helped with my RPi 0W2, too. Btw also using Mikrotik RouterOS v7. |
|
Hi together, I had same error code 18 with my Dell Latitude 6520 Laptop (Linux Mint 21.3 Virginia base: Ubuntu 22.04 jammy / Kernel: 5.15.0-101-generic x86_64 bits) and Mikrotik router RB4011iGS / Firmware v7.14.1 configured with CAPsMAN. Beside this, I have this additional settings, which I'm not sure, if it makes sense or not... but it works fine on my end now. Maybe this helps others :-) |
Same pi, same hardware, the mikrotik worked on both my pi3's also my pi5, but not my zeros, your fix worked, i sunk 2 whole days into this. If i could i'd buy you a coffee |
|
I have a similar issue, but it seems to only impact raspberry pi 3 units. Both units have static IPs, both I've checked the router and the DHCP lease is set for one day. I have two Pi3 and two Pi4 running on the local network and the problem always occurs at 38 minutes past the hour and only impacts the Pi3 units, and always with Restarting the NetworkManager service temporarily resolves this issue. Wired connections are not impacted. The Pi4 and Pi3 are configured using the same minimal setup. All four devices are on the same release: Here's a sample of the wpa_supplicant errors occurring at 38 minutes past the hour: Here's the full error output: |
this worked for me, on Raspberry Pi 5, thanks @pelwell! |
|
Had the same problem when connecting USB3 HDD , https://forums.raspberrypi.com/viewtopic.php?t=328248 |
|
I eventually found that the problem stemmed from the Group Rekey Interval on the APs. The reason the the problem reappeared every hour was related to the rekey interval being 3600 seconds. I changed the rekey interval to 1800 seconds and the problem disappeared. After a few weeks of stability, I moved the rekey interval back to 3600 and the problem has not returned. I honestly have no idea why this would have anything to do with anything, but it solved my problem.
|
|
Thanks - that's a useful observation. |
Same here with a Raspberry Pi 4. Edit: wifi stopped working again after unplugging the ethernet cable (I suppose that was acting as a sort of antenna too?), but started working again after using a different sd card adapter (the "USB drive" I was using was actually an sd card in an adapter). |
Heads-up: this is a cross post from the
raspberrypi/firmwarerepo because I realized it belonged here.The internet is filled with this issue. We have been trying to find and fix this problem for weeks now. But there is no solution yet. We have a consumer product using the cm4. It has the cypress/infineon 43455 chip and the problem we're facing appears to come from the firmware on this chip. Some customers have this problem, others do not experience it (so it seems to depend on the wifi environment as well).
Every now and then the system log starts spewing these messages:
It then fails to connect to the AP. We would like to know what this
status=16means. Maybe when we know this we can try to work around it. It is not easily reproducable in a lab environment unfortunately.I attached a full log of the problem where it sometimes connects but also gets this error quite often.
1ED95DB6-github.txt
System
cat /etc/rpi-issue)?vcgencmd version)?uname -a)?Linux hostname 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/LinuxThe text was updated successfully, but these errors were encountered: