Handling AP disconnects about esp-wifi-sys HOT 6 CLOSED

So I could reproduce this esp-idf, it's most likely my crappy isp router not responding to subsequent scans, switching to a high-quality router and it works flawlessly. It's a shame retry count doesn't retry the scan if it's not found when connecting, but I think in any real application it's expected to have to handle AP disconnects/retries.

I consider this solved/non-issue.

from esp-wifi-sys.

I think there are some more details available: https://github.com/esp-rs/esp-wifi/blob/60e57efa839590b915dc0cabd9bdc28afa0a0b19/src/binary/include_esp32c3.rs#L3977-L3999

But only a fraction of that gets mapped here: https://github.com/esp-rs/esp-wifi/blob/60e57efa839590b915dc0cabd9bdc28afa0a0b19/src/wifi/os_adapter.rs#L43-L53

My gut feeling for now is to show how to implement a simple retry in the samples - in a real implementation we should have exponential backoff and probably also a way to configure that

from esp-wifi-sys.

With wifi logs turned on we can figure out a disconnect reason, in my case, I am seeing error 202 about 50% of the time, which equates to

WIFI_REASON_AUTH_FAIL                = 202,

I don't understand how auth can sometimes fail, even when the same credentials are supplied. Is this a known wifi/esp limitation that we have to work around by retrying? Or are we doing something wrong in esp-wifi?

Perhaps @igrr has seen something like this in esp-idf?

from esp-wifi-sys.

So I believe the issue above is a bit of a red-herring and can be resolved quite easily by increasing the failure_retry count in esp_wifi_connect.

The other issue happens when doing a scan, and then connecting after a scan. Here's a log: https://gist.github.com/MabezDev/d0307096ca088463e3705963acc29068.

The first scan is triggered manually here: https://github.com/esp-rs/esp-wifi/blob/d1bf3a37ecbc9ab40941bf3e4b5375770f417127/esp-wifi/examples/embassy_dhcp.rs#L99-L106 and correctly finds the access point on channel 6.

The next scan is the scan used when connecting, as you'll see from the log above it scans all channels and doesn't seem to find the AP which is just found in the previous scan! If I remove the manual scan, I can connect the AP every time without fail.

Not sure if this is a limitation of the blobs, or we're missing something in esp-wifi and don't really know how to proceed :/. Any ideas?

from esp-wifi-sys.

Maybe we could try to do the same steps (manually scan and then try to connect) in esp-idf (probably it doesn't matter if we use C or Rust) and see if there are similar issues. Looking at the headers there is nothing that looks too promising to try

from esp-wifi-sys.

Interesting... I ran into this too and removing the initial (explicit) scan indeed fixed my problem as well.

I am in fact also using my "crappy isp router", but I will test your theory as I do have a better one laying around.

Thanks for leading me to the solution @MabezDev!

UPDATE:

I tested a better router and it solved my problem as well, thanks again!

from esp-wifi-sys.