Setting timeout_ms to esp_wifi_wps_start() has no effect (IDFGH-8996)

[AxelLin]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.1-dev-2356-gedd815af2e

Operating System used.

Linux

How did you build your project?

Command line with idf.py

If you are using Windows, please specify command line type.

None

Development Kit.

ESP32C3DevKit-M1

Power Supply used.

USB

What is the expected behavior?

The comment says "timeout_ms : maximum blocking time before API return.":
https://github.com/espressif/esp-idf/blob/master/components/wpa_supplicant/esp_supplicant/include/esp_wps.h#L104-L106
So I would expect setting timeout_ms should work.

But the esp_wifi_wps_start() function does not use the timeout_ms at all.

What is the actual behavior?

Setting timeout_ms to esp_wifi_wps_start has no effect

Steps to reproduce.

You can set timeout_ms for esp_wifi_wps_start() in wps example code.

Debug Logs.

No response

More Information.

No response

[kriegste]

I'd rather have a parameter to specify how long WPS is attempted. It is now 120 seconds, but it would be helpful if we can set a shorter time.

[kapilkedawat]

This variable was deprecated long time back, we now use events to update WPS status to application. We will update the API doc to reflect the same.

@kriegste This is as per specification. Also 120 secs is the max time, if the AP is available, it will take very minimal time.

[kriegste]

The AP has to provide WPS for 120 seconds. Are you sure this specification is for the client, too? On the ESP8266 the WPS timeout is only 15 seconds!

[kapilkedawat]

Yes, walk time for an enrollee is defined as 120 sec by default, you can use a lower value but that messes up the registrar logic in some registrar where monitor time is 120 secs and any two probes from two enrollee will be considered as WPS overlap.

Also why do you want to decrease this value? Can you explain the usecase in detail?

[AxelLin]

#987 (comment)

[kriegste]

To setup WiFi we use WPS or the SoftAP (and an HTTP server on the ESP32, so the user can enter the password manually).
Not all users have WPS as an option!

In initial tests, we had problems with the stability of the SoftAP during WPS. On the ESP8266 the SoftAP was not available at all during WPS. But there it took only 15 seconds and then WPS ran into the timeout. So the user did not have to wait too long.
On the ESP32 this takes 120 seconds. Lowering it to 15 seconds (like on the ESP8266) by editing the IDF solved the issue for us.

The devices do not have buttons or displays. So upon first boot, WPS is tried automatically.

[kriegste]

Same problem (disconnect due to WPS) here:
#9825

[AxelLin]

@kapilkedawat

I don't understand the meaning of this issue status.
It's marked as Resolution: Done for several months, but the issue is still open. What is fixed?

[kapilkedawat]

This variable was deprecated long time back, we now use events to update WPS status to application. We will update the API doc to reflect the same.

As mentioned in comment API has been updated since the argument has no effect. 142f339

[kapilkedawat]

In initial tests, we had problems with the stability of the SoftAP during WPS. On the ESP8266 the SoftAP was not available at all during WPS. But there it took only 15 seconds and then WPS ran into the timeout. So the user did not have to wait too long.

@kriegste this will be taken care in next releases. During the scan, softAP will come back to home channel to do tx.