esp-wifi - inconsistent issues getting IP

[yanshay]

I'm writing an async app using embassy and asp-wifi, and keep having issues with getting IP.
Connecting to wifi is almost always working but getting an IP isn't consistent.
Sometimes I get it quickly, sometimes I just don't even if waiting for minutes and need to reset the device to try again.
Sometimes after a single reset I get the IP, sometimes it takes several resets to get it working.

I have all kinds of logs going on (e.g. I wait for the IP on two tasks like in the examples and issues log from the waiting loop with the timer) and I noticed that depending on order of logs (coming from the two different tasks) I can even predict when I'll have issues with getting the IP as if it depends on the tasks scheduling order or something like that.
Maybe checking on IP on one of the tasks, before wifi is even connected could cause such issues?

Once I get the IP all networking works flawlessly.

I placed the router about 1.5 meter from the device so it's not low reception, and I don't have such issues on any other device.

Also, several months ago I developed a with embassy and esp-hal on the same device, only much older versions of both. I didn't have such issues back then.

1. Any guidelines how to troubleshoot something like that?
2. Is there a way to force a device reset from code if I see that I don't get an IP for a while? It's not a good option, but maybe I'll have to.

[bugadani]

This is a known issue (see #2246) and we're actively working on resolving it.

[yanshay]

This case seem to be about long time to get IP, in my case I never get an IP (or at least not for several minutes).
Could it explain such behavior as well?

[bjoernQ]

I think it's related / same issue

[JurajSadel]

Hello @yanshay! Could you try with these changes: #2251 if it makes things better?

[yanshay]

I managed to get esp-mbedtls to compile with esp-wifi 0.9.1 (also submitted a PR).

Next I tried using the commit by adding the below cargo overrides and removing features that are no longer supported on esp-hal and esp-wifi.

[patch.crates-io]
esp-wifi = { git = "https://github.com/esp-rs/esp-hal", rev = "543de7189cf8d7f876a9c9a9c6c19d434db29fdf"}
esp-hal = { git = "https://github.com/esp-rs/esp-hal", rev = "543de7189cf8d7f876a9c9a9c6c19d434db29fdf"}
esp-hal-embassy = { git = "https://github.com/esp-rs/esp-hal", rev = "543de7189cf8d7f876a9c9a9c6c19d434db29fdf"}

cargo update passed.

When I build I get the following error:

   Compiling xtensa-lx-rt v0.17.1
error: failed to run custom build command for `xtensa-lx-rt v0.17.1`

Caused by:
  process didn't exit successfully: `/Users/user/ProgProj/ESP32/nfc-filament/target/release/build/xtensa-lx-rt-385542a3f2f3b6df/build-script-build` (exit status: 101)
  --- stdout
  cargo:rustc-link-search=/Users/user/ProgProj/ESP32/nfc-filament/target/xtensa-esp32s3-none-elf/release/build/xtensa-lx-rt-5e3e417d9565ca8b/out

  --- stderr
  thread 'main' panicked at /Users/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/xtensa-lx-rt-0.17.1/build.rs:108:14:
  Either the esp32, esp32s2, esp32s3 feature must be enabled
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Where do I need to enable the esp32s3? (it's a working project so all these settings are set up properly wherever normally needed)

[bugadani]

You'll have to add xtensa-lx-rt to your list of patched crates, too.

[yanshay]

It progressed.

But now I have tens of compilation issues in my app which I can't fix for a temporary test.

So at most I'll try to reproduce the issue on a simple app, and if it happens there as well I'll try the fix there.

When is an updated version with this fix planned to come out? (at that point it makes sense for me to try and fix all those tens of errors I have).

And hopefully when it's released esp-mbedtls is not forgotten if requires an update.

[bugadani]

You can find our current roadmap at https://github.com/esp-rs/esp-hal/milestones

[yanshay]

Since moving to esp-wifi 9.1, I no longer see the IP issue, surely not at the same rate. Was anything that could be related to this change there?

Also, when I tried the wifi-embassy-dhcp example from the main branch, the issues didn't occur and also on #2251 .

Maybe it's just a good day for connectivity here, I will continue monitoring.