Wrong disconnected reason when provisioning & connecting to WEP network (IDFGH-4086) #5957
Comments
github-actions
bot
changed the title
|
Thanks for reporting, we will look into. |
|
From the logs, it seems like WEP64 is not supported by AP therefore it is sending an auth reject from with reason code 13(auth algo not supported). For WEP128(incorrect password) -- can you please check the password which you are giving is in compliance with WEP128 format since the device is not able to parse it as WEP password(Invalid WEP key password). Also, auth error will only come if AP is using shared WEP(ie giving error code in auth2/auth4), for open WEP there is no such mechanism for detection since open WEP automatically authenticates any client regardless of whether it actually has the correct WEP keys. |
|
Fow the WEP64 I'll try to use another AP to check if the AP is the problem, thanks. For the WEP128, I provided a wrong password intentionally. The issue is here is: although the device is no able to parse the password, as you said it actually prints the message |
|
Hi @ChromaMaster , During the scan phase, device searches for configured SSID APs. If it finds one AP with WEP mode enabled, it will check whether the device password is in compliance for WEP password, if not it will not consider it a candidate and will search for next AP(WPA/WPA2 mode). So the reason code is correct since the device didn't find any AP with the configured SSID and password(WPA/WPA2 mode). It is as similar as providing an AP with open mode and the device is configured with password. Feel free to mark the issue as closed if that answers your queries. |
You explained why device shows reason WIFI_REASON_NO_AP_FOUND (201). When got WIFI_REASON_NO_AP_FOUND most people will check SSID rather than password. |
|
@ChromaMaster @AxelLin The reason code WIFI_REASON_NO_AP_FOUND should be interpreted as AP(SSID) with required configuration is not found. The password provided (length) is one of the factor determining the mode in which the device connects to the AP. The same is true if auth-threshold in scan is set to higher security level. WIFI_REASON_NO_AP_FOUND will not be seen if the password format is as per WEP specification but there is a mismatch. |
@sagb2015 |
|
Maybe we can add a new reason code, from the original WIFI_REASON_NO_AP_FOUND, there are more cases:
|
|
added three new reasons: in |
Adds 3 more ddisconnect reasons in case of No AP found.
1. REASON_NO_AP_FOUND_IN_RSSI_THRESHOLD : AP rejected because it did
not meet rssi threshold.
2. REASON_NO_AP_FOUND_IN_AUTHMODE THRESHOLD : AP rejected because it
did not meet security threshold.
3. REASON_NO_AP_FOUND_WITH_COMPATIBLE_ SECURITY : AP rejected because
of incompatible security configuration. These situations could include
-- bss offerring WEP, but our password is not WEP compliant,
-- Encrypted AP bss but we have no password config set.
-- AP is Enterprise but we have not setup enterprise config and vice versa
Closes #5957
Adds 3 more ddisconnect reasons in case of No AP found.
1. REASON_NO_AP_FOUND_IN_RSSI_THRESHOLD : AP rejected because it did
not meet rssi threshold.
2. REASON_NO_AP_FOUND_IN_AUTHMODE THRESHOLD : AP rejected because it
did not meet security threshold.
3. REASON_NO_AP_FOUND_WITH_COMPATIBLE_ SECURITY : AP rejected because
of incompatible security configuration. These situations could include
-- bss offerring WEP, but our password is not WEP compliant,
-- Encrypted AP bss but we have no password config set.
-- AP is Enterprise but we have not setup enterprise config and vice versa
Closes espressif#5957
Environment
Problem Description
Hi.
I'm trying to implement a ble provisioning mechanism for my esp32 using the example provided by espressif: here.
The thing is that I'm trying to get some feedback from the system when this fails to connect to the provisioned nerwork. Everything works fine when I'm using WPA-PSK and WPA2-PSK encryption. The problem comes when I'm trying to use a WEP network. I'm not able to connect to a WEP-64bits network although I've tried a couple of routers.... and I can connect to a WEP-128bits network if the password matches (obviously) but I can't get the auth error if the password is wrong...
Expected Behavior
The expected behaviour is to get the wifi connected to the WEP-64bits when the right password is provided and if not, at least get the correct error messages. For the WEP-128bits I expect to get the "Auth error" if the password is wrong.
Actual Behavior
When I'm using the WEP-64bits encryption I'm not able to connect no matter what I'm always getting "Auth error". I've noticed that the wifi debug sais
wifi:invaild status 13 in auth response, retry auth requestso I tried another router and it doesn't work either.When I'm using the WEP-128bits encryption I am able to connect to the network if the password is right, but if I provide a wrong password, I always get a "AP Not found" error although you can see that the wifi debug sais
wifi:sta status is wrong passwordjust before the other error is reported.Steps to reproduce
make menuconfig(Component config -> Wi-Fi -> Enable WiFi debug log)Debug Logs
For WEP-64
For WEP-128
The text was updated successfully, but these errors were encountered: