120 second timeout in WPS

[cruvus]

The 120 seconds which WPS waits for an answer, is this a requirement for a standard of some kind? Or would it be possible to make it customizable in the future?

In IDF 4.4.1 there is this misleading definition:

/**
* @brief WPS starts to work.
*
* @attention WPS can only be used when ESP32 station is enabled.
*
* @param timeout_ms : maximum blocking time before API return.
* - 0 : non-blocking
* - 1~120000 : blocking time (not supported in IDF v1.0)
*
* @return
* - ESP_OK : succeed
* - ESP_ERR_WIFI_WPS_TYPE : wps type is invalid
* - ESP_ERR_WIFI_WPS_MODE : wifi is not in station mode or sniffer mode is on
* - ESP_ERR_WIFI_WPS_SM : wps state machine is not initialized
* - ESP_FAIL : wps initialization fails
*/
esp_err_t esp_wifi_wps_start(int timeout_ms);

But timeout_ms isn't actually used anywhere.


Of course, one could just modify components/wpa_supplicant/esp_supplicant/src/esp_wps.c (two occurrences):
> eloop_register_timeout(120, 0, wifi_station_wps_timeout, NULL, NULL);


I am asking for an official solution since ESP8266_NONOS had a much shorter timeout. In my app which I need to migrate, I first use WPS and then the SoftAP for initial WiFi configuration. Both cannot be used at the same time, so the users have to wait until WPS fails before they get their SoftAP. In ESP32, however, this takes endless 120 seconds.
Normally, a router has WPS active for 120 seconds. Calling esp_wifi_wps_start() during this time results in a prompt success. There is no need for ESP32 to wait this long.