Slow to obtain IP/none at all esp32c6/ embassy_net- Reserving IP through router fixes the issue

[kyleSpaulus]

Not sure if this is esp related, embassy_net, router etc.., Ive done a lot to try and monitor and fix this issue, no matter what I do sometimes my esp32c6 will take a really long time to obtain an IP address or sometimes can wait indefinately.

Ive monitored traffic through Wireshark as well as the logs from the router itself, do not see any errors. Applying a static IP address configuration or reserving the IP will fix this issue. This work around is OK for dev but not for production. Ive checked some previous posts about a fix in 2024, this seems to be something similar to this case in the past. #2264

I am a bit of a loss how to move forward, any suggestions? Does the reservation of the IP on the router provide some hints what it could be? Any other tools i could use?

Would appreciate some support or a point in the right direction

//K

Minimum example

macro_rules! mk_static {
    ($t:ty,$val:expr) => {{
        static STATIC_CELL: static_cell::StaticCell<$t> = static_cell::StaticCell::new();
        #[deny(unused_attributes)]
        let x = STATIC_CELL.uninit().write(($val));
        x
    }};
}

// Wait to get connected
    println!("Wait to get connected");

    loop {
        let res = wifi_device.is_connected();
        match res {
            Ok(connected) => {
                if connected {
                    break;
                }
            }
            Err(err) => {
                println!("{:?}", err);
                loop {}
            }
        }
    }
    println!("{:?}", wifi_device.is_connected());

    // Initializ the network stack for dhcp
    let config = Config::dhcpv4(Default::default());


    let (stack, runner) = embassy_net::new(
        controller,
        config,
        mk_static!(StackResources<3>, StackResources::<3>::new()),
        rng.random().into(),
    );
    // Spawn network task
    spawner.spawn(net_task(runner)).unwrap();

    // Wait for the link to be up
    loop {
        if stack.is_link_up() {
            println!("Link is up");
            break;
        }
        Timer::after(Duration::from_millis(500)).await;
    }

    println!("Waiting to get IP address...");

    let mut counter = 0;

    loop {
        stack.is_config_up();
        if let Some(config) = stack.config_v4() {
            println!("Got IP: {}", config.address);
            break;
        }
        counter += 1;
        println!("Waiting for IP address... {}", counter);
        Timer::after(Duration::from_millis(1000)).await;
    }

Cargo:

[dependencies]
embassy-net = { version = "0.6.0", features = [
  "dhcpv4",
  "medium-ethernet",
  "tcp",
  "udp",
] }
embedded-io = "0.6.1"
embedded-io-async = "0.6.1"
esp-alloc = "0.7.0"
esp-backtrace = { version = "0.15.1", features = [
  "esp32c6",
  "exception-handler",
  "panic-handler",
  "println",
] }
esp-hal = { version = "1.0.0-beta.0", features = ["esp32c6", "unstable"] }
esp-println = { version = "0.13.0", features = ["esp32c6"] }
smoltcp = { version = "0.12.0", default-features = false, features = [
  "medium-ethernet",
  "multicast",
  "proto-dhcpv4",
  "proto-dns",
  "proto-ipv4",
  "socket-dns",
  "socket-icmp",
  "socket-raw",
  "socket-tcp",
  "socket-udp",
] }
# for more networking protocol support see https://crates.io/crates/edge-net
critical-section = "1.2.0"
embassy-executor = { version = "0.7.0", features = ["task-arena-size-20480"] }
embassy-time = { version = "0.4.0", features = ["generic-queue-8"] }
esp-hal-embassy = { version = "0.7.0", features = ["esp32c6"] }
esp-wifi = { version = "0.13.0", features = ["builtin-scheduler", "esp-alloc", "esp32c6", "log", "smoltcp", "wifi"] }
heapless = { version = "0.8.0", default-features = false }
static_cell = { version = "2.1.0", features = ["nightly"] }
rust-mqtt = { version = "0.3.0", default-features = false }

[yanshay]

I'm not sure if this is related, but read through #2264, I had similar issues.

What I ended up with is:

1. esp-wifi doesn't work well with my multi access points configuration. When I let only one access point serve the SSID it work, but when more than one then getting IP is a problem. This is super consistent.
2. It seems that this is probably caused by smoltcp . I filed an issue there but no one responded. (Problems acquiring DHCP IP in case of multiple access points serving same SSID smoltcp-rs/smoltcp#1017)
3. My application that face these issues in my network config is used by tens, maybe over hundred people in some open-source software, and no one face these issues (I would have known if it would). So it's probably not a common issue.

[kyleSpaulus]

Hi yanshay,

I have updated my message with your case number, I did find it useful in trying to fix this.

Regarding point 2, I must agree with you but do not know why: I have tested smoltcp dhcp_client.rs from the examples page https://github.com/smoltcp-rs/smoltcp/blob/main/examples/dhcp_client.rs with identical results to the embassy_net version. When this issue pops up both the embassy and smoltcp scripts appear to behave the same.

In the no_std training for example dhcp_client https://github.com/esp-rs/no_std-training/blob/main/intro/http-client/examples/http-client.rs uses a very specific crate for the stack blocking_network_stack::Stack;. I wonder if this could be helpful in identifying the root cause?

Could I help by posting this information in your smoltcp request?

Happy to do it if you think it will support, thank you for the quick response.

use blocking_network_stack::Stack;

 // wait for getting an ip address
    println!("Wait to get an ip address");
    loop {
        stack.work();

        if stack.is_iface_up() {
            println!("got ip {:?}", stack.get_ip_info());
            break;
        }
    }
    // ANCHOR_END: ip

P.S are you using esp32 for production? Anything you have public like a website you could share more details. Just curious.

//Kyle

[yanshay]

Could I help by posting this information in your smoltcp request?

Feel free, I gave up on this once I solved it for myself, and as said, it wasn't reproduced elsewhere. I'll be happy to monitor if there's any progress. I'm sure someone on the smoltcp team would be able to get it resolved if you can get their attention.
You could also turn smoltcp logs on and try to follow the dhcp messages together with the logs, maybe that would help.

P.S are you using esp32 for production? Anything you have public like a website you could share more details. Just curious.

I guess you could call it production by now, quite a few people are using it all the time with their 3D printers. Start at https://www.spoolease.io , maybe will be relevant to you in case you are into 3D printing 😄 . There's a link there to the main GitHub repo.
Sorry in advance regarding the code - I admit it's not good, I just focus on features at this time and sacrifice even on the most basic rust practices and idiomatic code (too much actually). But its working perfectly thanks to Rust - even not best code is super stable and reliable. I really like the ecosystem - esp-hal, embassy, slint, and lots more. Even though it's not mature. Highly recommended. You can Star the repo on the way 😄

[kyleSpaulus]

I had a breakthrough after reading through your threads @yanshay , and taking a few days to test. I have found a solution.

If anyone is using the sleep functionality - light sleep you may have problems obtaining an IP when waking:

let rtc = Rtc::new(peripherals.LPWR);
rtc.sleep_light(&[wake_source]);

When waking up the wifi will be in power savings mode, preventing and sometimes dropping the wifi connection. One can observe this by looking in your router for signal strength. Mine was around 6Mbps in power savings mode (Minimum by default) and 65 with None. The solution is to provide the wifi controller PowerSaveMode::None:

let (mut wifi_device, controller) = esp_wifi::wifi::new(init, wifi_peripherals).unwrap();

    // Set power savings mode to none
    wifi_device
        .set_power_saving(esp_wifi::config::PowerSaveMode::None)
        .unwrap();

Yanshay - very cool project :) thank you for sharing. The bamboo labs printers are really beautifully designed and sounds like a good addition.

[yanshay]

I do have the let rtc = Rtc::new ... code, but not the sleep after that.
Could this be relevant in my case as well then?

I don't even know why it's there, it is some historical line, that in the past when I removed or even moved to another position caused issues, so I left it there. Never had time to check what its about.

Worth keeping this issue open and asking the maintainers about this, if it is an expected behavior.