-
Notifications
You must be signed in to change notification settings - Fork 7.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIFI Access Point: Detect incorrect password entered by station (IDFGH-13377) #14289
Comments
You've registered the
I'd expected a |
I believe you need to be connected in the first place to get the |
@koneill-txwireless |
Thank you but have you actually confirmed this? Have you the log showing an incorrect password being entered? I have tested this yesterday and no event is generated when an incorrect password is entered. Espressif have also confirmed that |
Hi @KaeLL , For softAP, |
I stand corrected. |
Hi @sarveshb14, is this feature something you guys are considering? Our client is chasing us again for when we will have a solution for this. They have come from a Linux based platform to the ESP32 and it was a key feature on their legacy solution. |
Hi @koneill-txwireless , apologies for the delay. May I know which chips are you planning to use ? I will provide you with a patch. |
That's great news. The ESP32S3 is the only chip our client uses. |
Hi @koneill-txwireless , This is indeed an interesting case. Please try with following esp-idf patch and also replace wifi libraries for S3 in With the above change, we have added Do let me know if this handles your use case and any additional suggestions/requirements if any. |
I reckon this is a helpful addition to the regular IDF on all chips. |
Hi @sarveshb14, apologies for being slow to get back to you, I was off the last few days. Your patch is working and working well. The only thing I noticed was that it appears to be triggered four times per attempt. Is there a way that I can reduce this to one per event? Should I be clearing event bits? |
Hi @koneill-txwireless , for WPA2, we (softAP) know that station is trying to connect with wrong password if mic-verification (kind of signature verification) fails during the processing of M2 message (of 4-Way-Handshake). Its normal for stations to re-transmit frames in case of failed connection in the assumption that the frame was previously lost in the transmission. Hence you are seeing the event getting triggered for 4 times. It is actually the station which is re-transmitting the frame for 4 times (due to wrong password). This can also happen for WPA3. I do not think we can do much here. We have to report the event every time a wrong frame (due to wrong password) is received. |
That's fine, thank you for the background on it. We can manage the multiple triggers. |
@sarveshb14 What's the ETA for that on master? |
Hi @sarveshb14, is there a possibility that this will be merged into the next release of v5.1, e.g. v5.1.5? It is the release line that our client is on and they are sensitive to big jumps. |
Hey @sarveshb14, any update on this? Client is keen to get this integrated and tested. |
Since this was requested, v5.1.5 has been released. The libraries provided are targetted at v5.1.4 I think as you get linker errors on v5.1.5. Would it be possible to get new WIFI libs with incorrect password detection functionality for v5.1.5? |
Hi @koneill-txwireless , Sorry for the late response. The functionality to detect the station using wrong pasword/pin is implemented completely in We will get this feature merged in esp-idf soon. Till then please use this patch as it is on esp-idf (without the libraries). |
Is your feature request related to a problem?
Client has stringent cyber-security requirements and needs to be able to react, taking the matter into their own hands, to an incorrect password being entered more than once.
Describe the solution you'd like.
When a station attempts to connect to the ESP32 WIFI access point, with an incorrect password, a callback with a reason of "incorrect password" or something similiar.
Describe alternatives you've considered.
We looked at using WIFI_EVENT_AP_STADISCONNECTED but as was correctly pointed out, that is only applicable when a station was connected in the first place.
We tried to monitor the ESP32's reaction to an incorrect password being entered, it does log it (deauth/disassoc, reason: 3), but we can't find a way to react to it.
Additional context.
The client is on v5.1.4 of IDF.
The text was updated successfully, but these errors were encountered: