WIFI_REASON_NO_AP_FOUND_W_COMPATIBLE_SECURITY received (IDFGH-12537)

[0xFEEDC0DE64]

Hi,

we are used a bit outdated esp-idf version and it seems like a lot of customers of our products receive the event WIFI_REASON_NO_AP_FOUND_W_COMPATIBLE_SECURITY since our rebase of the used esp-idf submodule.

we are using esp-idf fork: https://github.com/0xFEEDC0DE64/esp-idf/commits/fixes/ which is based on the espressif commit https://github.com/espressif/esp-idf/commit/5454d37d496a8c58542eb450467471404c606501

My question is now: Is there a reason for this error to occur now? Customers can downgrade the firmware to an old esp-idf and then their home wifi works again.

Will another esp idf rebase help in this situation?

[0xFEEDC0DE64]

more customers contacted us, they also receive NO_AP_FOUND_IN_AUTHMODE_THRESHOLD

why are these new errors emitted?

[0xFEEDC0DE64]

by the way the threshold is set to open in all situations in our firmware:

wifi_config_t make_sta_config(std::string_view ssid, std::string_view password, int8_t min_rssi,
                              std::optional<mac_t> bssid, uint8_t channel)
{
    wifi_config_t wifi_config;

    wifi_config.sta.channel = channel;
    wifi_config.sta.listen_interval = 0;
    wifi_config.sta.scan_method = WIFI_FAST_SCAN; //WIFI_ALL_CHANNEL_SCAN or WIFI_FAST_SCAN
    wifi_config.sta.sort_method = WIFI_CONNECT_AP_BY_SIGNAL; //WIFI_CONNECT_AP_BY_SIGNAL or WIFI_CONNECT_AP_BY_SECURITY
    wifi_config.sta.threshold.rssi = min_rssi;
    wifi_config.sta.pmf_cfg.capable = true;
    wifi_config.sta.pmf_cfg.required = false;
    wifi_config.sta.bssid_set = 0;
    std::fill(std::begin(wifi_config.sta.bssid), std::end(wifi_config.sta.bssid), 0);
    wifi_config.sta.threshold.authmode = WIFI_AUTH_OPEN;
    wifi_config.sta.ssid[0] = 0;
    wifi_config.sta.password[0] = 0;

    if (!ssid.empty())
    {
        copyStrToBuf(wifi_config.sta.ssid, ssid);

        if (!password.empty())
        {
            wifi_config.sta.threshold.authmode = WIFI_AUTH_WEP;
            copyStrToBuf(wifi_config.sta.password, password);
        }

        if (bssid)
        {
            wifi_config.sta.bssid_set = 1;
            bssid->copyTo(wifi_config.sta.bssid);
        }
    }

    return wifi_config;
}

[mhdong]

Hi @0xFEEDC0DE64 If the scan fails to find the target AP, WIFI_EVENT_STA_DISCONNECTED_ will arise and the reason code could either be WIFI_REASON_NO_AP_FOUND or WIFI_REASON_NO_AP_FOUND_W_COMPATIBLE_SECURITY or WIFI_REASON_NO_AP_FOUND_IN_AUTHMODE_THRESHOLD or WIFI_REASON_NO_AP_FOUND_IN_RSSI_THRESHOLD depending of the Station's configuration.

1. NO_AP_FOUND_IN_AUTHMODE_THRESHOLD 1) Received WPA3-Enterprise disable transition bit, required authmode is greater than WPA2.(disable wpa2 transition) 2) Received WPA3-Personal disable transition bit, required authmode is greater than WPA2.(disable wpa2 transition) 3) OWE transition is disabled, reject legacy open bss profile.(disable owe transition) 3) authmode threshold failure.
2. WIFI_REASON_NO_AP_FOUND_W_COMPATIBLE_SECURITY 1) AP in IBSS mode 2) WPA AP beacon recieved but sta has set PMF required configuration 3) WEP key parsing failed 4) wpa_config_parse_string is null 5) Invalid WEP key 6) Station SAE H2E disabled, which is required by AP 7) RSNXE parsing failed 8) AP's AKM suite is 'SAE Extended Key' but AP does not have H2E enabled 9) Open AP, but we want an encrypted AP, ignore 10) SAE-PK is configured as mandatory but disabled for AP 11) SAE H2E is configured as mandatory but disabled for AP 12) Authmode is bad(authtype is OWE but sta disabled OWE) 13) Received encrypted AP, but password is empty 14) Enterprise mode enabled, but AP is open/PSK

The possible reasons are listed above, and you can further confirm the specific reasons by opening the debug level. menuconfig -> Component config -> Log output -> Default log verbosity -> Debug

[AxelLin]

The possible reasons are listed above, and you can further confirm the specific reasons by opening the debug level. menuconfig -> Component config -> Log output -> Default log verbosity -> Debug

@mhdong Is there any api to get the the specific reasons in standard build? Sometimes, it's not possible to install a debug build on a customer's device.

[0xFEEDC0DE64]

I did another esp-rebase (we have already been 1300 commits behind from master) and now it seems at least one customer had success connecting to his wifi again, seems like the issue was only in a certain range of commits.

Sometimes I really wish for an open source wifi driver to better understand what is going on inside.

[mhdong]

Hi @AxelLin NO_AP_FOUND_IN_AUTHMODE_THRESHOLD and WIFI_REASON_NO_AP_FOUND_W_COMPATIBLE_SECURITY is specific reasons for customer. Thank you very much for your suggestion. If all possible reasons are added as reason codes, it will result in too many reason codes. We will continue to add reasons that are meaningful to customers or can quickly identify issues in the future.

[mhdong]

Hi @0xFEEDC0DE64 Thank you very much for your suggestion. For ease of use, we will continuously optimize the reason codes for scan fails to find the target AP.

[AxelLin]

If all possible reasons are added as reason codes, it will result in too many reason codes. We will continue to add reasons that are meaningful to customers or can quickly identify issues in the future.

My point is: You cannot assume every device has a console to show the prints. If there is no api to get the real reason code, it's very difficult to understand what's wrong especially when it only happens on certain customer's environment.

[Sherry616]

Thanks for reporting, will close due to short of feedback from the reporter, feel free to reopen with more updates. Thanks for using our Espressif product!

[udoudou]

@0xFEEDC0DE64 There may be a problem with your code. wifi_config_t wifi_config is not initialized, which will cause the unset members to carry garbage values. Of course, this is not necessarily the cause of your problem.