Closed bill88t closed 9 months ago
Retested with latest master (commit 294c2bd70d3fc6e5fefee627a7f2007f7b255709). No changes (it's broken in master too).
@sarveshb14 @nachiketkukade Any update? Will v5.1.2 fix this issue?
@AxelLin sorry that not fix this in v5.1.2. Currently esp-idf consider WPA/WPA2/WPA3 an invalid auth mode. Will consider how to fix this, and add it in v5.2 and v5.1.3.
Hi @bill88t @AxelLin, Sorry for making you wait.
As per WPA3 Specification, AP shall not enable WPA version 1 on the same BSS with WPA3-Personal modes
.
I agree that scan results should not show authentication mode of such AP as OPEN
.
We will consider security of such AP as WPA2 WPA3
(i.e. ignoring the weaker WPA version 1 security) and will provide an update for this soon.
wpa_supplicant
is probably at fault.
I will try to file a bug to them too.
Also, the network KeyFalse
is set to WPA2, not WPA3.
I don't know if NetworkManager does something on it's own, but my phone thinks it's WPA3 too.
Does WiFi4 even support WPA3???
Hi @bill88t , Can you please 1) Check in which security mode does the esp-device gets connected with this AP and provide logs. 2) Provide wireless sniffer capture of the beacon transmitted by this AP.
ESP-device should be able to connect with WPA3-SAE security. This is a screenshot from my local run with AP configured with WPA-WPA2-WPA3 mode.
I don't know if NetworkManager does something on it's own, but my phone thinks it's WPA3 too.
If phone sees AKM suite SAE
and management frame protection capabilities
in beacons of AP, phone will consider this AP as a WPA3 AP. Packet capture will be helpful here in determining the security mode.
I ran the connection example from C6, S2 and C3, all of which say it's WPA2-PSK, which is correct.
The network configuration is as follows:
I also set my thinkpad in "monitor mode" and captured all the wifi 802.11 traffic. During the capture, I performed a lot of connections from both the phone and esp32-c6.
I do not know how to read it though.
Thank you providing the capture. KeyFalse AP is on channel 1 while sniffer capture is of channel 10. Can you please take sniffer capture of channel 1 or start the AP on channel 10 ?
Does this same configuration shows WPA WPA2 WPA3
security in the output of nmcli device wifi list
?
Can you please take sniffer capture of channel 1 or start the AP on channel 10 ?
Alright, sorry for the wait, I captured channel 1 this time. ch1.zip While the capture was running I connected to the network "KeyFalse" with an ESP32-C6 and the phone.
Does this same configuration shows WPA WPA2 WPA3 security in the output of nmcli device wifi list ?
Yes.
Here, AP does not advertise Management Frame Protection
RSN capabilities , so in my opinion station not connecting in WPA3 mode is right.
Yes, it should use WPA2. I don't think WPA3 would work for these networks.
We will consider security of such AP as WPA2 WPA3 (i.e. ignoring the weaker WPA version 1 security) and will provide an update for this soon.
Maybe it should be reported as WPA2
, not WPA2 WPA3
. I think it being detected as WPA3
is a mistake.
Maybe it should be reported as WPA2, not WPA2 WPA3
You are right. If AP does not follow WPA3, we will treat this AP as WPA_WPA2
. If it follows WPA3, this will be treated as WPA2_WPA3
Hi @bill88t , we have merged above discussed changes into master branch now. It will be available on next v5.1 tag (i.e. v5.1.3)
Thank you for your support
is it already in master? we are also affected by this bug and I would like to know which commit in master fixed the issue to start my rebases on
I don't think so. I did test master 2 weeks ago with the latest commit and didn't see any changes. I also can't find the related commit in the commit log.
It's possible the fix has been applied downstream and we will see it with the release. I don't know how espressif works. In either case, I don't know.
Hi @0xFEEDC0DE64 , @bill88t . Sorry for making you wait. Fix is merged in internal repository. Push to github It is stalled due to internal CI. It will soon be available on github.
No problem, thanks for letting us know!
It will soon be available on github.
It is available now. (615d928a)
Can confirm, this fixed the issue. Thanks!
Hi @bill88t , we have merged above discussed changes into master branch now. It will be available on next v5.1 tag (i.e. v5.1.3)
@sarveshb14 v5.1.3 does not include this fix.
Hi @AxelLin @bill88t , We will include this in next release of v5.1. Apologies for the inconvenience caused.
I can confirm an update to latest esp-idf has fixed all problems for us, thank you
Answers checklist.
IDF version.
v5.1.1
Espressif SoC revision.
ESP32-C6 ESP32 ESP32-S3 (and probably the rest)
Operating System used.
Linux
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
None
Development Kit.
WeAct ESP32-C6, M5Stack Timer Camera X, Adafruit Feather ESP32-S3 TFT
Power Supply used.
USB
What is the expected behavior?
A wifi scan from my trustworthy thinkpad returns:
What is the actual behavior?
Using wifi scan example (examples/wifi/scan) as is, with just flash parameters and speed changed, 10cm from the thinkpad's scan spot:
Steps to reproduce.
Unkown.
Debug Logs.
No response
More Information.
The network "KeyFalse" in question is a linux computer with NetworkManager doing the hotspot with it's motherboard's wifi. The full connection parameters are as follows:
Under random chance, during the day, other networks, frequently "Feline34" which is also mine appears also as OPEN. That network is a standard isp provided router and it's pretty old.
This issue is in fact not a dupe of https://github.com/espressif/esp-idf/issues/11202 as there are no Enterprise networks in the vicinity.