FG mode, password wrong reason unable to accurately identify

[lwj850533527]

Hi mantriyogesh,

Feedback on an issue with the FG mode. Connect to AP wiith wrong password, esp32 unable to return the correct reason for failure.

Question 1:there are different scenarios for reporting reasons, but the reasons are the same Scene 1: The connection in authentication phase, and the AP reply authentication response err. WIFI_EVENT_STA_DISCONNECTED event report with reason 2 Scene 2: The connection in the 4-way handshake phase, and the AP reply deauthentication with reason 2. WIFI_EVENT_STA_DISCONNECTED event report with reason 2

Question 2: Set WIFI_WRONG_PASSWORD_BIT, It depends on WIFI_REASON_CONNECTION_FAIL (205) and WIFI_REASON_NOT_AUTHED (6), It seems not enough

Question 3: When the connection in the 4-way handshake phase, no matter what packet receive, I want all reported reason codes to be changed to 15 (WIFI_REASON_4WAY_HANDSHAKE_TIMEOUT). Where can I modify this

[mantriyogesh]

Wrt (1) & (2), Actually, these issues are raised in other issues, already. We are fixing them, but might take two weeks time to get fixes on the master.

Regarding (3), https://github.com/espressif/esp-hosted/blob/6ddb670edcf15108be92d7e8e4fc6f32542ef5e4/esp_hosted_fg/host/control_lib/src/ctrl_core.c#L426

is the place where control lib parse the response from slave. If resp is non-zero, you can change it here to your exp choice, at host itself.

If you use disconnect event, you can also check
https://github.com/espressif/esp-hosted/blob/6ddb670edcf15108be92d7e8e4fc6f32542ef5e4/esp_hosted_fg/host/control_lib/src/ctrl_core.c#L247 additionally.

We are also making the change, which would return the exact reason code due to which the slave API was failed to make return code transparent to host, which would be correct fix. But anyway this I consider sub-part of (1) & (2) above.

Instead of manual interpretation at slave or host, then host on receiving the return value, higher level app can then choose what to do.

[lwj850533527]

Regarding (3), “If resp is non-zero, you can change it here to your exp choice, at host itself.” I want to change reason in slave before the WIFI_EVENT_STA_DISCONNECTED send, it should be set at bottom driver

[lwj850533527]

The host side cannot sense which stage the WiFi connection is in. When the same error code appears, the host cannot distinguish it

[mantriyogesh]

If you want workaround as if now, Can you please check: https://github.com/espressif/esp-hosted/issues/435

[mantriyogesh]

Anyway, for a proper fix, we are already incorporating the change, but it might take some time to appear on master.

[lwj850533527]

If you want workaround as if now, Can you please check: #435

Actually, I have already made this modification. But it still can't solve my problem

I want to change reason in slave before station_event_handler called. Because it occur Question 1 scene

[mantriyogesh]

That's right.

If you wish to override the reason from 2 to 15, this is the place.

However, as I see from the code this code should not be broken. basically, whatever the reason code for disconnection reported from Wi-Fi (sta mode), should be received at https://github.com/espressif/esp-hosted/blob/6ddb670edcf15108be92d7e8e4fc6f32542ef5e4/esp_hosted_fg/host/linux/host_control/c_support/test_utils.c#L119-L120

Not sure if you wish to selectively modify the reason code, For example,

Also, please keep in mind, this is a event loop(system) event handler (callback with small stack), so, any modifications should be as minimal as possible and non-blocking in nature.

[lwj850533527]

Thank you for your reply! I think I may not have expressed my thoughts clearly.

Question 1:there are different scenarios for reporting reasons, but the reasons are the same Scene 1: The connection in authentication phase, and the AP reply authentication response err. WIFI_EVENT_STA_DISCONNECTED event report with reason 2 Scene 2: The connection in the 4-way handshake phase, and the AP reply deauthentication with reason 2. WIFI_EVENT_STA_DISCONNECTED event report with reason 2

Question 3 is mainly for question 1 actually, in Scene 1, reason 2 does not require any changes, in Scene 2, reason 2 require changes to 15. That's why I emphasize that only during the connection in the 4-way handshake phase, I need to modify the reason code.

[mantriyogesh]

ESP-Hosted doesn't know the current state, as it is handled below in wpa supplicant in wifi driver.

ESP-Hosted scope wrt event handler

Your observations might hold true, but that is out of the scope for ESP-Hosted. What I mean, Underlying Wi-Fi driver already might have the understanding of current state. In ESP-Hosted-FG, we transparently pass the return code from underlying wifi driver from ESP-IDF. Sniffer capture if you capture, can clearly showcase, that disconnect received is not in 4-Way-Handshake and not in Auth mode.

Next steps

If you suspect that the return code in the current state of Wi-Fi is incorrect, Possibly can try running the same Hosted on ESP-IDF master commit, it in case this issue was actually there on WiFi driver.

If still face issues on latest hosted-latest idf, can you please provide wifi sniffer log, from starting (with M1-M4 EAPOL messages captured), along with slave and host logs. We will ask wifi driver team to look into it. Alternatively, raising issue in https://github.com/espressif/esp-idf/issues might help.

Some learning and verification of issue

For understanding wifi stages and associated disconnected events, please refer to:

• Disconnect while 4-Way-Handshake
• disconnect while authentication
• Overall wifi stages understanding