Error running `mdns_responder` example on ESP32C3

ivmarkov / edge-net

async + no_std + no-alloc implementations of various network protocols

Apache License 2.0

110 stars 17 forks source link

Error running `mdns_responder` example on ESP32C3 #24

Closed Luni-4 closed 1 month ago

Luni-4 commented 2 months ago

My issue could be caused by my lack of experience and knowledge, so sorry in advance if that's the case.

I can build the mdns-responder example on esp32c3, but I cannot flash and run it because I'm getting the following error repeatedly:

ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0xc (RTC_SW_CPU_RST),boot:0xd (SPI_FAST_FLASH_BOOT)
Saved PC:0x4038152a
0x4038152a - esp_restart_noos
    at /.espressif/esp-idf/v5.2.1/components/esp_system/port/soc/esp32c3/system_internal.c:111
SPIWP:0xee
mode:DIO, clock div:2
load:0x3fcd5820,len:0x1714
load:0x403cc710,len:0x968
load:0x403ce710,len:0x2f9c
entry 0x403cc710
I (19) boot: ESP-IDF v5.1.2-342-gbcf1645e44 2nd stage bootloader
I (20) boot: compile time Dec 12 2023 10:50:58
I (20) boot: chip revision: v0.4
I (24) boot.esp32c3: SPI Speed      : 40MHz
I (29) boot.esp32c3: SPI Mode       : DIO
I (34) boot.esp32c3: SPI Flash Size : 4MB
I (38) boot: Enabling RNG early entropy source...
I (44) boot: Partition Table:
I (47) boot: ## Label            Usage          Type ST Offset   Length
I (55) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (62) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (69) boot:  2 factory          factory app      00 00 00010000 003f0000
I (77) boot: End of partition table
I (81) esp_image: segment 0: paddr=00010020 vaddr=3c050020 size=136e8h ( 79592) map
I (107) esp_image: segment 1: paddr=00023710 vaddr=3fc8ae00 size=012d0h (  4816) load
I (109) esp_image: segment 2: paddr=000249e8 vaddr=40380000 size=0acf0h ( 44272) load
I (124) esp_image: segment 3: paddr=0002f6e0 vaddr=00000000 size=00938h (  2360)
I (125) esp_image: segment 4: paddr=00030020 vaddr=42000020 size=4a8e4h (305380) map
I (201) boot: Loaded app from partition at offset 0x10000
I (201) boot: Disabling RNG early entropy source...
I (212) cpu_start: Unicore app
I (221) cpu_start: Pro cpu start user code
I (221) cpu_start: cpu freq: 160000000 Hz
I (221) cpu_start: Application information:
I (224) cpu_start: Project name:     libespidf
I (229) cpu_start: App version:      1
I (234) cpu_start: Compile time:     Sep 10 2024 15:56:34
I (240) cpu_start: ELF file SHA256:  000000000...
I (245) cpu_start: ESP-IDF:          v5.2.1
I (250) cpu_start: Min chip rev:     v0.3
I (255) cpu_start: Max chip rev:     v1.99
I (260) cpu_start: Chip rev:         v0.4
I (264) heap_init: Initializing. RAM available for dynamic allocation:
I (272) heap_init: At 3FC8DB50 len 000324B0 (201 KiB): RAM
I (278) heap_init: At 3FCC0000 len 0001C710 (113 KiB): Retention RAM
I (285) heap_init: At 3FCDC710 len 00002950 (10 KiB): Retention RAM
I (292) heap_init: At 50000010 len 00001FD8 (7 KiB): RTCRAM
I (299) spi_flash: detected chip: generic
I (303) spi_flash: flash io: dio
W (307) timer_group: legacy driver is deprecated, please migrate to `driver/gptimer.h`
I (315) sleep: Configure to isolate all GPIO pins in sleep state
I (322) sleep: Enable automatic switching of GPIO sleep configuration
I (329) main_task: Started on CPU0
I (329) main_task: Calling app_main()
Guru Meditation Error: Core  0 panic'ed (Stack protection fault).

Detected in task "main" at 0x4200127a
0x4200127a - foo_esp::main
    at /foo-esp/src/main.rs:25
Stack pointer: 0x3fc8f9d0
Stack bounds: 0x3fc8fb30 - 0x3fc90b20

Core  0 register dump:
MEPC    : 0x4200127e  RA      : 0x4200176a  SP      : 0x3fc8f9d0  GP      : 0x3fc8b600
0x4200127e - foo_esp::main
    at /foo-esp/src/main.rs:26
0x4200176a - std::rt::lang_start::{{closure}}
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:164
0x3fc8b600 - __func__.0
    at ??:??
TP      : 0x3fc7e0a4  T0      : 0x4005890e  T1      : 0x4201b608  T2      : 0xffffffff
0x4201b608 - <std::sys::sync::mutex::pthread::AllocatedMutex as std::sys_common::lazy_box::LazyInit>::init
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/sync/mutex/pthread.rs:51
S0/FP   : 0x3c0505c0  S1      : 0x3fc90ad8  A0      : 0x4200126e  A1      : 0x42001762
0x3c0505c0 - $d
    at ??:??
0x4200126e - foo_esp::main
    at /foo-esp/src/main.rs:25
0x42001762 - std::rt::lang_start::{{closure}}
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:164
A2      : 0x3fc9166c  A3      : 0x00000003  A4      : 0x3fc91628  A5      : 0x00000000
A6      : 0xa0000000  A7      : 0x0000000a  S2      : 0x00000000  S3      : 0x00000000
S4      : 0x00000000  S5      : 0x00000000  S6      : 0x00000000  S7      : 0x00000000
S8      : 0x00000000  S9      : 0x00000000  S10     : 0x00000000  S11     : 0x00000000
T3      : 0x00000000  T4      : 0x00000000  T5      : 0x00000000  T6      : 0x00000000
MSTATUS : 0x00001881  MTVEC   : 0x40380001  MCAUSE  : 0x0000001b  MTVAL   : 0x00012097
0x40380001 - _vector_table
    at ??:??
MHARTID : 0x00000000

Stack memory:
3fc8f9d0: 0x5f707365 0x656d6974 0x00000072 0x00000000 0x3fc8f990 0x00000016 0x00000000 0x00000000
3fc8f9f0: 0x00000000 0x00000000 0x3fc8e33c 0x3fc8e3a4 0x3fc8e40c 0x00000000 0x00000000 0x00000001
3fc8fa10: 0x00000000 0x00000000 0x00000000 0x420290c0 0x00000000 0x00000000 0x00000000 0x00000000
0x420290c0 - esp_cleanup_r
    at /.espressif/esp-idf/v5.2.1/components/newlib/newlib_init.c:60
3fc8fa30: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fc8fa50: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fc8fa70: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fc8fa90: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fc8fab0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fc8fad0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000001 0x0000000c
3fc8faf0: 0x3fc8fb00 0x00000000 0x3fc8fae8 0x0000000c 0x09c6000a 0x00000000 0x3fc8fb20 0x0000000c
3fc8fb10: 0x3fc914b4 0x00000000 0x3fc8fb08 0x0000000c 0x0c88000a 0x00000000 0x3fc913e0 0x00001000
3fc8fb30: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc8fb50: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc8fb70: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc8fb90: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc8fbb0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc8fbd0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc8fbf0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc8fc10: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc8fc30: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc8fc50: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc8fc70: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc8fc90: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc8fcb0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc8fcd0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc8fcf0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc8fd10: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc8fd30: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc8fd50: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc8fd70: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc8fd90: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc8fdb0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5

ELF file SHA256: 000000000

Rebooting...
ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0xc (RTC_SW_CPU_RST),boot:0xd (SPI_FAST_FLASH_BOOT)
Saved PC:0x4038152a
0x4038152a - esp_restart_noos
    at /.espressif/esp-idf/v5.2.1/components/esp_system/port/soc/esp32c3/system_internal.c:111
SPIWP:0xee
mode:DIO, clock div:2
load:0x3fcd5820,len:0x1714
load:0x403cc710,len:0x968
load:0x403ce710,len:0x2f9c
entry 0x403cc710
I (20) boot: ESP-IDF v5.1.2-342-gbcf1645e44 2nd stage bootloader
I (20) boot: compile time Dec 12 2023 10:50:58
I (20) boot: chip revision: v0.4
I (24) boot.esp32c3: SPI Speed      : 40MHz
I (29) boot.esp32c3: SPI Mode       : DIO
I (34) boot.esp32c3: SPI Flash Size : 4MB
I (38) boot: Enabling RNG early entropy source...
I (44) boot: Partition Table:
I (47) boot: ## Label            Usage          Type ST Offset   Length
I (55) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (62) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (69) boot:  2 factory          factory app      00 00 00010000 003f0000
I (77) boot: End of partition table
I (81) esp_image: segment 0: paddr=00010020 vaddr=3c050020 size=136e8h ( 79592) map
I (107) esp_image: segment 1: paddr=00023710 vaddr=3fc8ae00 size=012d0h (  4816) load
I (109) esp_image: segment 2: paddr=000249e8 vaddr=40380000 size=0acf0h ( 44272) load
I (124) esp_image: segment 3: paddr=0002f6e0 vaddr=00000000 size=00938h (  2360)
I (125) esp_image: segment 4: paddr=00030020 vaddr=42000020 size=4a8e4h (305380) map

This is my Cargo.toml:

[package]
name = "foo-esp"
version = "0.1.0"
edition = "2021"
license = "MIT OR Apache-2.0"

[dependencies]
# Esp
embedded-svc = "0.28"
esp-idf-svc = "0.49"

# Mdns-sd
edge-mdns = "0.3"
edge-nal = "0.3"
edge-nal-std = "0.3"
embassy-sync = "0.6"
embassy-time= {version = "0.3", features = ["std", "generic-queue-8"] }
futures-lite = "2.3.0"
rand = "0.8.5"

[build-dependencies]
embuild  = "0.32.0"

[profile.dev]
# Rust debug is too slow.
# For debug builds always builds with some optimization
opt-level = "s"

[profile.release]
codegen-units = 1 # LLVM can perform better optimizations using a single thread
debug = 2
debug-assertions = false
incremental = false
lto = 'fat'
opt-level = 's'
overflow-checks = false

This is my config.toml:

[build]
target = "riscv32imc-esp-espidf"

[target.riscv32imc-esp-espidf]
linker = "ldproxy"
runner = "espflash flash --monitor"
# Future - necessary for the experimental "native build" of esp-idf-sys with ESP32C3
# See also https://github.com/ivmarkov/embuild/issues/16
rustflags = ["--cfg", "espidf_time64", "-C", "default-linker-libraries"]

[unstable]
# Builds the `std` environment crate for the `esp` target.
# The `panic_abort` crate is built as default behavior for the binary.
build-std          = ["panic_abort", "std"]
# Enables only the following `std` features for the `esp` binary.
build-std-features = ["panic_immediate_abort"]

[env]
# Enables the esp-idf-sys "native" build feature (`cargo build --features native`) to build against ESP-IDF (v5.2.1)
ESP_IDF_VERSION = { value = "tag:v5.2.1" }

# These configurations will pick up your custom "sdkconfig.release", "sdkconfig.debug" or "sdkconfig.defaults[.*]" files
# that you might put in the root of the project
# The easiest way to generate a full "sdkconfig[.release|debug]" configuration (as opposed to manually enabling only the necessary flags via "sdkconfig.defaults[.*]"
# is by running "cargo pio espidf menuconfig" (that is, if using the pio builder)
#ESP_IDF_SDKCONFIG = { value = "./sdkconfig.release", relative = true }
#ESP_IDF_SDKCONFIG = { value = "./sdkconfig.debug", relative = true }
ESP_IDF_SDKCONFIG_DEFAULTS = { value = "./sdkconfig.defaults", relative = true }
# ESP-IDF will be installed in ~/.espressif so it can be reused across the different examples.
# See also https://github.com/esp-rs/esp-idf-sys#esp_idf_tools_install_dir-esp_idf_tools_install_dir
ESP_IDF_TOOLS_INSTALL_DIR = { value = "global" }

This is my code:

use core::net::{Ipv4Addr, Ipv6Addr};

use edge_mdns::buf::{BufferAccess, VecBufAccess};
use edge_mdns::domain::base::Ttl;
use edge_mdns::io::{self, MdnsIoError, DEFAULT_SOCKET};
use edge_mdns::{host::Host, HostAnswersMdnsHandler};
use edge_nal::{UdpBind, UdpSplit};

use embassy_sync::blocking_mutex::raw::NoopRawMutex;
use embassy_sync::signal::Signal;

use log::info;

use rand::{thread_rng, RngCore};

// Change this to the IP address of the machine where you'll run this example
const OUR_IP: Ipv4Addr = Ipv4Addr::new(127, 0, 0, 1);

const OUR_NAME: &str = "mypc";

fn main() {
    esp_idf_svc::sys::link_patches();
    esp_idf_svc::log::EspLogger::initialize_default();

    let stack = edge_nal_std::Stack::new();

    let (recv_buf, send_buf) = (
        VecBufAccess::<NoopRawMutex, 1500>::new(),
        VecBufAccess::<NoopRawMutex, 1500>::new(),
    );

    futures_lite::future::block_on(run::<edge_nal_std::Stack, _, _>(
        &stack, &recv_buf, &send_buf, OUR_NAME, OUR_IP,
    ))
    .unwrap();
}

async fn run<T, RB, SB>(
    stack: &T,
    recv_buf: RB,
    send_buf: SB,
    our_name: &str,
    our_ip: Ipv4Addr,
) -> Result<(), MdnsIoError<T::Error>>
where
    T: UdpBind,
    RB: BufferAccess<[u8]>,
    SB: BufferAccess<[u8]>,
{
    info!("About to run an mDNS responder for our PC. It will be addressable using {our_name}.local, so try to `ping {our_name}.local`.");

    let mut socket = io::bind(stack, DEFAULT_SOCKET, Some(Ipv4Addr::UNSPECIFIED), Some(0)).await?;

    let (recv, send) = socket.split();

    let host = Host {
        hostname: our_name,
        ipv4: our_ip,
        ipv6: Ipv6Addr::UNSPECIFIED,
        ttl: Ttl::from_secs(60),
    };

    // A way to notify the mDNS responder that the data in `Host` had changed
    // We don't use it in this example, because the data is hard-coded
    let signal = Signal::new();

    let mdns = io::Mdns::<NoopRawMutex, _, _, _, _>::new(
        Some(Ipv4Addr::UNSPECIFIED),
        Some(0),
        recv,
        send,
        recv_buf,
        send_buf,
        |buf| thread_rng().fill_bytes(buf),
        &signal,
    );

    mdns.run(HostAnswersMdnsHandler::new(&host)).await
}

Thanks in advance for your help!

MabezDev commented 2 months ago

Could you also post your sdkconfig.defaults?

Luni-4 commented 2 months ago

Sure, here the sdkconfig.defaults:

CONFIG_ESP_MAIN_TASK_STACK_SIZE=20000
CONFIG_ESP_SYSTEM_EVENT_TASK_STACK_SIZE=4096

MabezDev commented 2 months ago

If you're doing a lot in main, without spawning any other threads you're probably hitting a stack overflow. Does increasing CONFIG_ESP_MAIN_TASK_STACK_SIZE and rebuilding help?

Luni-4 commented 2 months ago

I've added to the first comment my code. I had also tried to increase CONFIG_ESP_MAIN_TASK_STACK_SIZE=40000 but nothing changed, same error

MabezDev commented 2 months ago

I would try even bigger stacks maybe CONFIG_ESP_MAIN_TASK_STACK_SIZE=80000? It's unlikely to be anything else when it explicitly detects and overflow, but maybe @ivmarkov knows more.

ivmarkov commented 2 months ago

I've added to the first comment my code. I had also tried to increase CONFIG_ESP_MAIN_TASK_STACK_SIZE=40000 but nothing changed, same error

Are you absolutely sure your sdkconfig.defaults is picked up? Is it in the root of the crate? Did you do - just in case - cargo clean? I am - as we speak - running a much more complex project that amongst other things uses the edge-mdns responder with only 45KB stack.

Luni-4 commented 2 months ago

This is the content of my foo-esp directory after running the ls -la command

drwxrwxr-x  6 ron ron  4096 set 12 08:32 .
drwxr-x--- 81 ron ron  4096 set 12 08:31 ..
-rw-r--r--  1 ron ron    53 set 10 16:02 build.rs
drwxrwxr-x  2 ron ron  4096 set 10 15:49 .cargo
-rw-rw-r--  1 ron ron 48427 set 11 16:32 Cargo.lock
-rw-r--r--  1 ron ron   748 set 11 16:32 Cargo.toml
drwxrwxr-x  6 ron ron  4096 set 11 17:18 .git
drwxrwxr-x  3 ron ron  4096 set 10 13:25 .github
-rw-r--r--  1 ron ron   225 set 10 13:25 .gitignore
-rw-r--r--  1 ron ron 10741 set 10 13:25 LICENSE-APACHE
-rw-r--r--  1 ron ron  1052 set 10 13:25 LICENSE-MIT
-rw-r--r--  1 ron ron    59 set 10 15:52 rust-toolchain.toml
-rw-rw-r--  1 ron ron    83 set 12 08:31 sdkconfig.defaults
drwxrwxr-x  2 ron ron  4096 set 11 16:51 src

I've also tried to run cargo clean and then cargo run, but nothing has changed. I'm using the last Rust nightly version.

This is the error I get with CONFIG_ESP_MAIN_TASK_STACK_SIZE=40000

Rebooting...
ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0xc (RTC_SW_CPU_RST),boot:0xd (SPI_FAST_FLASH_BOOT)
Saved PC:0x40380eb4
0x40380eb4 - esp_restart_noos
    at /.espressif/esp-idf/v5.2.1/components/esp_system/port/soc/esp32c3/system_internal.c:111
SPIWP:0xee
mode:DIO, clock div:2
load:0x3fcd5820,len:0x1714
load:0x403cc710,len:0x968
load:0x403ce710,len:0x2f9c
entry 0x403cc710
I (19) boot: ESP-IDF v5.1.2-342-gbcf1645e44 2nd stage bootloader
I (20) boot: compile time Dec 12 2023 10:50:58
I (20) boot: chip revision: v0.4
I (24) boot.esp32c3: SPI Speed      : 40MHz
I (29) boot.esp32c3: SPI Mode       : DIO
I (33) boot.esp32c3: SPI Flash Size : 4MB
I (38) boot: Enabling RNG early entropy source...
I (44) boot: Partition Table:
I (47) boot: ## Label            Usage          Type ST Offset   Length
I (54) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (62) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (69) boot:  2 factory          factory app      00 00 00010000 003f0000
I (77) boot: End of partition table
I (81) esp_image: segment 0: paddr=00010020 vaddr=3c050020 size=13200h ( 78336) map
I (107) esp_image: segment 1: paddr=00023228 vaddr=3fc8a800 size=01288h (  4744) load
I (108) esp_image: segment 2: paddr=000244b8 vaddr=40380000 size=0a66ch ( 42604) load
I (123) esp_image: segment 3: paddr=0002eb2c vaddr=00000000 size=014ech (  5356)
I (125) esp_image: segment 4: paddr=00030020 vaddr=42000020 size=47eb8h (294584) map
I (198) boot: Loaded app from partition at offset 0x10000
I (198) boot: Disabling RNG early entropy source...
I (209) cpu_start: Unicore app
I (218) cpu_start: Pro cpu start user code
I (218) cpu_start: cpu freq: 160000000 Hz
I (218) cpu_start: Application information:
I (221) cpu_start: Project name:     libespidf
I (226) cpu_start: App version:      1
I (231) cpu_start: Compile time:     Sep 12 2024 08:36:17
I (237) cpu_start: ELF file SHA256:  000000000...
I (242) cpu_start: ESP-IDF:          v5.2.1
I (247) cpu_start: Min chip rev:     v0.3
I (252) cpu_start: Max chip rev:     v1.99
I (257) cpu_start: Chip rev:         v0.4
I (261) heap_init: Initializing. RAM available for dynamic allocation:
I (269) heap_init: At 3FC8D4F0 len 00032B10 (202 KiB): RAM
I (275) heap_init: At 3FCC0000 len 0001C710 (113 KiB): Retention RAM
I (282) heap_init: At 3FCDC710 len 00002950 (10 KiB): Retention RAM
I (289) heap_init: At 50000010 len 00001FD8 (7 KiB): RTCRAM
I (296) spi_flash: detected chip: generic
I (300) spi_flash: flash io: dio
W (304) timer_group: legacy driver is deprecated, please migrate to `driver/gptimer.h`
I (312) sleep: Configure to isolate all GPIO pins in sleep state
I (319) sleep: Enable automatic switching of GPIO sleep configuration
I (326) main_task: Started on CPU0
I (326) main_task: Calling app_main()
I (326) foo_esp: About to run an mDNS responder for our PC. It will be addressable using mypc.local, so try to `ping mypc.local`.

assert failed: tcpip_send_msg_wait_sem /IDF/components/lwip/lwip/src/api/tcpip.c:449 (Invalid mbox)
Core  0 register dump:
MEPC    : 0x40380ef2  RA      : 0x403835a8  SP      : 0x3fc97930  GP      : 0x3fc8b000
0x40380ef2 - panic_abort
    at /.espressif/esp-idf/v5.2.1/components/esp_system/panic.c:472
0x403835a8 - __ubsan_include
    at /.espressif/esp-idf/v5.2.1/components/esp_system/ubsan.c:313
0x3fc8b000 - __global_pointer$
    at ??:??
TP      : 0x3fc86cbc  T0      : 0x37363534  T1      : 0x7271706f  T2      : 0x33323130
S0/FP   : 0x00000001  S1      : 0x3fc97ab3  A0      : 0x3fc97988  A1      : 0x3fc8b289
A2      : 0x00000001  A3      : 0x00000029  A4      : 0x00000001  A5      : 0x3fc8d000
0x3fc8d000 - s_intr_handlers
    at ??:??
A6      : 0x7a797877  A7      : 0x76757473  S2      : 0x00000064  S3      : 0x3fc97988
S4      : 0x3fc97988  S5      : 0x3fc99e7c  S6      : 0x3fc97d64  S7      : 0x00000000
S8      : 0x00000002  S9      : 0x3fc97da8  S10     : 0x00000004  S11     : 0x00000001
T3      : 0x6e6d6c6b  T4      : 0x6a696867  T5      : 0x66656463  T6      : 0x62613938
MSTATUS : 0x00001801  MTVEC   : 0x40380001  MCAUSE  : 0x00000007  MTVAL   : 0x00000000
0x40380001 - _vector_table
    at ??:??
MHARTID : 0x00000000

Stack memory:
3fc97930: 0x0000000a 0x3fc97a34 0x3c060874 0x403890a0 0x0000000d 0x3fc99314 0x3fc99c28 0x3fc8b288
0x3c060874 - __func__.6
    at ??:??
0x403890a0 - newlib_include_assert_impl
    at /.espressif/esp-idf/v5.2.1/components/newlib/assert.c:93
3fc97950: 0x00393434 0x3fc8ab90 0x00000000 0x00000000 0x3f000000 0x3fc8b598 0x3c060874 0x3fc8b5a8
0x3fc8ab90 - s_fd_table
    at ??:??
0x3c060874 - __func__.6
    at ??:??
3fc97970: 0x3c05b2e8 0x3fc8b5ac 0x3fc97950 0x3fc8b5b0 0x3c05b314 0x3fc8b288 0x65737361 0x66207472
3fc97990: 0x656c6961 0x74203a64 0x70697063 0x6e65735f 0x736d5f64 0x61775f67 0x735f7469 0x2f206d65
3fc979b0: 0x2f464449 0x706d6f63 0x6e656e6f 0x6c2f7374 0x2f706977 0x7069776c 0x6372732f 0x6970612f
3fc979d0: 0x7063742f 0x632e7069 0x3934343a 0x6e492820 0x696c6176 0x626d2064 0x0029786f 0x00000000
3fc979f0: 0x00000058 0x00000054 0x3fc8d4f0 0x40387928 0x00000000 0x00000000 0x3fc9a048 0x00000054
0x40387928 - multi_heap_malloc_impl
    at /.espressif/esp-idf/v5.2.1/components/heap/multi_heap.c:218
3fc97a10: 0x3fc97d64 0x00000054 0x00000804 0x4038118e 0x00000000 0x00000000 0x3fc9a048 0x00000001
0x4038118e - heap_caps_malloc_base
    at /.espressif/esp-idf/v5.2.1/components/heap/heap_caps.c:180
3fc97a30: 0x00000004 0x3fc97da8 0x00000002 0x00000000 0x3fc97d64 0x3fc99e7c 0x00000003 0x42023fc6
0x42023fc6 - find_key
    at /.espressif/esp-idf/v5.2.1/components/pthread/pthread_local_storage.c:79
3fc97a50: 0x00000804 0x4203a88c 0x00000003 0x3fc97cf8 0x3fc97b80 0x4203a88c 0x3fc97aa8 0x4202d5fc
0x4203a88c - lwip_netconn_do_newconn
    at /.espressif/esp-idf/v5.2.1/components/lwip/lwip/src/api/api_msg.c:703
0x4203a88c - lwip_netconn_do_newconn
    at /.espressif/esp-idf/v5.2.1/components/lwip/lwip/src/api/api_msg.c:703
0x4202d5fc - tcpip_send_msg_wait_sem
    at /.espressif/esp-idf/v5.2.1/components/lwip/lwip/src/api/tcpip.c:449
3fc97a70: 0x3fc97b80 0x4203a88c 0x3fc9a120 0x420396f8 0x4202cd80 0x00000020 0x3fc97aa8 0x42039736
0x4203a88c - lwip_netconn_do_newconn
    at /.espressif/esp-idf/v5.2.1/components/lwip/lwip/src/api/api_msg.c:703
0x420396f8 - sys_thread_sem_init
    at /.espressif/esp-idf/v5.2.1/components/lwip/port/freertos/sys_arch.c:535
0x4202cd80 - event_callback
    at /.espressif/esp-idf/v5.2.1/components/lwip/lwip/src/api/sockets.c:2499
0x42039736 - netconn_apimsg
    at /.espressif/esp-idf/v5.2.1/components/lwip/lwip/src/api/api_lib.c:132
3fc97a90: 0x3fc97b80 0x00000000 0x3fc9a010 0x42039798 0x3fc97b58 0x3fc99314 0x3fc9a010 0x40383c88
0x42039798 - netconn_new_with_proto_and_callback
    at /.espressif/esp-idf/v5.2.1/components/lwip/lwip/src/api/api_lib.c:162
0x40383c88 - xQueueGiveMutexRecursive
    at /.espressif/esp-idf/v5.2.1/components/freertos/FreeRTOS-Kernel/queue.c:789
3fc97ab0: 0x3fc97b00 0x3fc8dd44 0x00000020 0x42012654 0x3c052d9a 0x00000001 0x00000146 0x3fc9a120
0x42012654 - <esp_idf_svc::log::EspLogger as log::Log>::log
    at ??:??
0x3c052d9a - $d
    at ??:??
3fc97ad0: 0x3fc8dd44 0x00000004 0x3fc97b10 0x4202d3de 0x3fc97af0 0x00000004 0x3fc97b10 0x42019db6
0x4202d3de - lwip_socket
    at /.espressif/esp-idf/v5.2.1/components/lwip/lwip/src/api/sockets.c:1720
0x42019db6 - std::sys::pal::unix::net::Socket::new_raw
    at ??:??
3fc97af0: 0x3fc97ad7 0x420207ca 0x3fc97b60 0x4201ba62 0x3fc97ac8 0x4202080c 0x3fc97b18 0x4201f1e0
0x420207ca - <u8 as core::fmt::num::DisplayInt>::to_u32
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/num.rs:41
0x4201ba62 - <core::result::Result<T,E> as core::ops::try_trait::Try>::branch
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/result.rs:1986
0x4202080c - <u32 as core::fmt::num::DisplayInt>::to_u32
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/num.rs:41
0x4201f1e0 - <&T as core::fmt::Display>::fmt
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:2382
3fc97b10: 0x3fc97acc 0x42012884 0x3c05033c 0x00000007 0x0000000b 0x00000003 0x00000002 0x3c05033c
0x42012884 - <&T as core::fmt::Display>::fmt
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:2382
0x3c05033c - $d
    at ??:??
0x3c05033c - $d
    at ??:??
3fc97b30: 0x00000004 0x00000004 0x3fc97bc0 0x42000cf0 0x00000000 0x00000000 0x00000000 0x00000000
0x42000cf0 - std::net::each_addr
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/net/mod.rs:81
3fc97b50: 0x00000000 0x00000000 0x14e90000 0x00000000 0x00000001 0x00000000 0x00000000 0x00000000
3fc97b70: 0x00000000 0x00000000 0x00000000 0x000014e9 0x00000007 0x3c050308 0x00000004 0x3fc97b60
0x3c050308 - $d
    at ??:??
3fc97b90: 0x3fc97da4 0x00000001 0x3fc97c48 0x42000d4e 0x00000001 0x00000000 0x00000000 0x00000000
0x42000d4e - core::result::Result<T,E>::map
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/result.rs:770
3fc97bb0: 0x00000000 0x00000000 0x00000000 0x000014e9 0x3fc97da4 0x3fc98db0 0x3fc99277 0x420004ee
0x420004ee - <core::result::Result<T,E> as core::ops::try_trait::Try>::branch
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/result.rs:1986
3fc97bd0: 0xa5a5a5a5 0xa5a5a5a5 0x3fc9804c 0x3fc98030 0x3fc97fec 0x3fc97fe0 0x3fc98db0 0x00000000
3fc97bf0: 0x3fc99e78 0x3fc97fdc 0x3fc97dd0 0xfb0000e0 0x3fc97d54 0x3fc97d38 0x3fc97d20 0x3fc97d18
3fc97c10: 0x3fc97d90 0x3fc981a4 0x3fc97f88 0x3fc981a0 0x3fc97da0 0x3fc98190 0x3fc97d64 0xa5a5a5a5
3fc97c30: 0xa5a5a5a5 0xa5a5a5a5 0x3fc99e80 0x3fc99e80 0x00000000 0xa5a5a5a5 0x3c050308 0x00000003
0x3c050308 - $d
    at ??:??
3fc97c50: 0x3fc97c60 0x00000001 0x3fc97c68 0x00000002 0x3fc97d18 0x4201f1e0 0x00000001 0x00000000
0x4201f1e0 - <&T as core::fmt::Display>::fmt
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:2382
3fc97c70: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x000014e9 0x00000002 0xa5a5a5a5
3fc97c90: 0x00000002 0xa5a5a5a5 0x00000020 0x00000000 0x00000000 0xa5a5a503 0x3c05033c 0x00000007
0x3c05033c - $d
    at ??:??
3fc97cb0: 0x3c05033c 0x00000007 0x3c05032c 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x3c05033c - $d
    at ??:??
0x3c05032c - $d
    at ??:??
3fc97cd0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x3fc97cf8 0x3fc98db0 0x420029c4
0x420029c4 - core::ptr::drop_in_place<foo_esp::run<edge_nal_std::Stack,&edge_mdns::buf::VecBufAccess<embassy_sync::blocking_mutex::raw::NoopRawMutex,1500_usize>,&edge_mdns::buf::VecBufAccess<embassy_sync::blocking_mutex::raw::NoopRawMutex,1500_usize>>::{{closure}}>
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:49
3fc97cf0: 0xa5a5a5a5 0xa5a5a5a5 0x00000031 0x4202aa84 0x00000031 0x00000000 0x3fc8dd44 0x40381cee
0x4202aa84 - console_write
    at /.espressif/esp-idf/v5.2.1/components/vfs/vfs_console.c:78
0x40381cee - __retarget_lock_release_recursive
    at /.espressif/esp-idf/v5.2.1/components/newlib/locks.c:341
3fc97d10: 0x00000004 0x00000000 0x3c050544 0x00000004 0x00000000 0x00000000 0x3c050544 0x00000004
0x3c050544 - $d
    at ??:??
0x3c050544 - $d
    at ??:??

ELF file SHA256: 000000000

ivmarkov commented 2 months ago

This is the content of my foo-esp directory after running the ls -la command

OK. So sdkconfig.defaults is in the correct location. Read on.

I've also tried to run cargo clean and then cargo run, but nothing has changed. I'm using the last Rust nightly version.

Everything had changed. Before, you were claiming this error (with stack size of 40KB):

I (329) main_task: Calling app_main() Guru Meditation Error: Core 0 panic'ed (Stack protection fault).

Now, you are reporting this error (again, with stack size of 40KB):

assert failed: tcpip_send_msg_wait_sem /IDF/components/lwip/lwip/src/api/tcpip.c:449 (Invalid mbox)

These are two completely different errors. The fact, that you get the "Invalid mbox" error in the lwIp stack does mean, that the stack size issue is no longer an issue. So something had changed - for the better.

Now, for the second error:

You get it, because the networking layer of ESP IDF is not initialized yet. In other words, even if you didn't get the second error, the code you have just wouldn't do anything, simply because the mDNS responder does not have an ethernet device (and IP stack on top) via which it could send/receive UDP packets in the first place.

The example you have copied can only run verbatim on regular PCs only, where the ethernet connection and the network interfaces are up and running before the start of your app, because you have an OS underneath your app, and when booting it, the OS took care of bringing up either ethernet, or Wifi for you - automatically.

In the embedded MCU world (ESP IDF included), you need extra steps to bring up either an Ethernet interface or a Wifi interface or both.

Assuming you want a Wifi interface, you need some code similar to this example. This code needs to run before the code you have so far which is trying to bring up the mDNS responder.

(BTW, while running the mDNS responder, please keep the wifi variable around and don't drop it, as that would drop the wifi interface and you'll get to square 0 again.)

Please let me know if it works for you once you incorporate the changes I suggest. There might be a need to do one more thing, but let's go step by step. And if you hit a stack size issue again, increase the stack size with the conf setting. There are ways to reduce the stack size usage, but then again - step by step.

Luni-4 commented 2 months ago

Thanks a lot @ivmarkov for your explanation, very appreciated, clear and concise! :)

Ok, I've tried to replicate the Wiifi interface code you linked to me. This is the result. First, I run cargo clean and then cargo run.

use core::net::{Ipv4Addr, Ipv6Addr};

use edge_mdns::buf::{BufferAccess, VecBufAccess};
use edge_mdns::domain::base::Ttl;
use edge_mdns::io::{self, MdnsIoError, DEFAULT_SOCKET};
use edge_mdns::{host::Host, HostAnswersMdnsHandler};
use edge_nal::{UdpBind, UdpSplit};

use embassy_sync::blocking_mutex::raw::NoopRawMutex;
use embassy_sync::signal::Signal;

use log::info;

use rand::{thread_rng, RngCore};

use anyhow::bail;

use embedded_svc::wifi::{AuthMethod, ClientConfiguration, Configuration};

use esp_idf_svc::hal::prelude::Peripherals;
use esp_idf_svc::hal::task::block_on;
use esp_idf_svc::log::EspLogger;
use esp_idf_svc::timer::EspTaskTimerService;
use esp_idf_svc::wifi::{AsyncWifi, EspWifi};
use esp_idf_svc::{eventloop::EspSystemEventLoop, nvs::EspDefaultNvsPartition};

const OUR_NAME: &str = "mypc";

#[toml_cfg::toml_config]
pub struct WifiConfig {
    #[default("")]
    ssid: &'static str,
    #[default("")]
    password: &'static str,
}

fn main() -> anyhow::Result<()> {
    esp_idf_svc::sys::link_patches();
    EspLogger::initialize_default();

    // `async-io` uses the ESP IDF `eventfd` syscall to implement async IO.
    // If you use `tokio`, you still have to do the same as it also uses the `eventfd` syscall
    esp_idf_svc::io::vfs::initialize_eventfd(5).unwrap();

    let peripherals = Peripherals::take()?;
    let sys_loop = EspSystemEventLoop::take()?;
    let timer_service = EspTaskTimerService::new()?;
    let nvs = EspDefaultNvsPartition::take()?;

    let mut wifi = AsyncWifi::wrap(
        EspWifi::new(peripherals.modem, sys_loop.clone(), Some(nvs))?,
        sys_loop,
        timer_service,
    )?;

    block_on(connect_wifi(&mut wifi))?;

    let ip_info = wifi.wifi().sta_netif().get_ip_info()?;

    info!("Wifi DHCP info: {:?}", ip_info);

    let stack = edge_nal_std::Stack::new();

    let (recv_buf, send_buf) = (
        VecBufAccess::<NoopRawMutex, 1500>::new(),
        VecBufAccess::<NoopRawMutex, 1500>::new(),
    );

    block_on(run::<edge_nal_std::Stack, _, _>(
        &stack, &recv_buf, &send_buf, OUR_NAME, ip_info.ip,
    ))
    .unwrap();

    loop {
        // Sleep for one second and then continue the execution.
        std::thread::sleep(std::time::Duration::from_millis(1000));
    }
}

async fn run<T, RB, SB>(
    stack: &T,
    recv_buf: RB,
    send_buf: SB,
    our_name: &str,
    our_ip: Ipv4Addr,
) -> Result<(), MdnsIoError<T::Error>>
where
    T: UdpBind,
    RB: BufferAccess<[u8]>,
    SB: BufferAccess<[u8]>,
{
    info!("About to run an mDNS responder for our PC. It will be addressable using {our_name}.local, so try to `ping {our_name}.local`.");

    let mut socket = io::bind(stack, DEFAULT_SOCKET, Some(Ipv4Addr::UNSPECIFIED), Some(0)).await?;

    let (recv, send) = socket.split();

    let host = Host {
        hostname: our_name,
        ipv4: our_ip,
        ipv6: Ipv6Addr::UNSPECIFIED,
        ttl: Ttl::from_secs(60),
    };

    // A way to notify the mDNS responder that the data in `Host` had changed
    // We don't use it in this example, because the data is hard-coded
    let signal = Signal::new();

    let mdns = io::Mdns::<NoopRawMutex, _, _, _, _>::new(
        Some(Ipv4Addr::UNSPECIFIED),
        Some(0),
        recv,
        send,
        recv_buf,
        send_buf,
        |buf| thread_rng().fill_bytes(buf),
        &signal,
    );

    mdns.run(HostAnswersMdnsHandler::new(&host)).await
}

async fn connect_wifi(wifi: &mut AsyncWifi<EspWifi<'static>>) -> anyhow::Result<()> {
    let wifi_config = WIFI_CONFIG;

    let ssid = wifi_config.ssid;
    let password = wifi_config.password;

    if ssid.is_empty() {
        bail!("Missing Wi-Fi SSID")
    }

    if password.is_empty() {
        bail!("Wifi password is empty");
    }

    let wifi_configuration: Configuration = Configuration::Client(ClientConfiguration {
        ssid: ssid.try_into().unwrap(),
        bssid: None,
        auth_method: AuthMethod::WPA2Personal,
        password: password.try_into().unwrap(),
        channel: None,
        ..Default::default()
    });

    wifi.set_configuration(&wifi_configuration)?;

    wifi.start().await?;
    info!("Wifi started");

    wifi.connect().await?;
    info!("Wifi connected");

    wifi.wait_netif_up().await?;
    info!("Wifi netif up");

    Ok(())
}

And now I get the following error:

[2024-09-12T15:00:39Z INFO ] Serial port: '/dev/ttyACM0'
[2024-09-12T15:00:39Z INFO ] Connecting...
[2024-09-12T15:00:39Z INFO ] Using flash stub
Chip type:         esp32c3 (revision v0.4)
Crystal frequency: 40 MHz
Flash size:        4MB
Features:          WiFi, BLE
MAC address:       48:31:b7:3d:b6:84
App/part. size:    1,317,456/4,128,768 bytes, 31.91%
[2024-09-12T15:00:39Z INFO ] Segment at address '0x0' has not changed, skipping write
[2024-09-12T15:00:39Z INFO ] Segment at address '0x8000' has not changed, skipping write
[2024-09-12T15:00:40Z INFO ] Segment at address '0x10000' has not changed, skipping write
[2024-09-12T15:00:40Z INFO ] Flashing has completed!
Commands:
    CTRL+R    Reset chip
    CTRL+C    Exit

ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x15 (USB_UART_CHIP_RESET),boot:0xd (SPI_FAST_FLASH_BOOT)
Saved PC:0x40380576
0x40380576 - esp_mspi_pin_init
    at /.espressif/esp-idf/v5.2.2/components/spi_flash/flash_ops.c:154
SPIWP:0xee
mode:DIO, clock div:2
load:0x3fcd5820,len:0x1714
load:0x403cc710,len:0x968
load:0x403ce710,len:0x2f9c
entry 0x403cc710
I (19) boot: ESP-IDF v5.1.2-342-gbcf1645e44 2nd stage bootloader
I (20) boot: compile time Dec 12 2023 10:50:58
I (20) boot: chip revision: v0.4
I (24) boot.esp32c3: SPI Speed      : 40MHz
I (29) boot.esp32c3: SPI Mode       : DIO
I (33) boot.esp32c3: SPI Flash Size : 4MB
I (38) boot: Enabling RNG early entropy source...
I (44) boot: Partition Table:
I (47) boot: ## Label            Usage          Type ST Offset   Length
I (54) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (62) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (69) boot:  2 factory          factory app      00 00 00010000 003f0000
I (77) boot: End of partition table
I (81) esp_image: segment 0: paddr=00010020 vaddr=3c0f0020 size=46cc0h (289984) map
I (154) esp_image: segment 1: paddr=00056ce8 vaddr=3fc90c00 size=02b00h ( 11008) load
I (157) esp_image: segment 2: paddr=000597f0 vaddr=40380000 size=06828h ( 26664) load
I (166) esp_image: segment 3: paddr=00060020 vaddr=42000020 size=e7748h (948040) map
I (378) esp_image: segment 4: paddr=00147770 vaddr=40386828 size=0a2bch ( 41660) load
I (394) boot: Loaded app from partition at offset 0x10000
I (394) boot: Disabling RNG early entropy source...
I (406) cpu_start: Unicore app
I (415) cpu_start: Pro cpu start user code
I (415) cpu_start: cpu freq: 160000000 Hz
I (415) cpu_start: Application information:
I (418) cpu_start: Project name:     libespidf
I (423) cpu_start: App version:      1
I (427) cpu_start: Compile time:     Sep 12 2024 16:29:49
I (433) cpu_start: ELF file SHA256:  000000000...
I (439) cpu_start: ESP-IDF:          v5.2.2
I (444) cpu_start: Min chip rev:     v0.3
I (448) cpu_start: Max chip rev:     v1.99
I (453) cpu_start: Chip rev:         v0.4
I (458) heap_init: Initializing. RAM available for dynamic allocation:
I (465) heap_init: At 3FC97BD0 len 00028430 (161 KiB): RAM
I (471) heap_init: At 3FCC0000 len 0001C710 (113 KiB): Retention RAM
I (478) heap_init: At 3FCDC710 len 00002950 (10 KiB): Retention RAM
I (485) heap_init: At 50000010 len 00001FD8 (7 KiB): RTCRAM
I (493) spi_flash: detected chip: generic
I (496) spi_flash: flash io: dio
W (501) timer_group: legacy driver is deprecated, please migrate to `driver/gptimer.h`
I (509) sleep: Configure to isolate all GPIO pins in sleep state
I (516) sleep: Enable automatic switching of GPIO sleep configuration
I (523) main_task: Started on CPU0
I (523) main_task: Calling app_main()
I (533) pp: pp rom version: 9387209
I (543) net80211: net80211 rom version: 9387209
I (553) wifi:wifi driver task: 3fcb2654, prio:23, stack:6656, core=0
I (553) wifi:wifi firmware version: 3e0076f
I (553) wifi:wifi certification version: v7.0
I (553) wifi:config NVS flash: enabled
I (553) wifi:config nano formating: disabled
I (563) wifi:Init data frame dynamic rx buffer num: 32
I (563) wifi:Init static rx mgmt buffer num: 10
I (573) wifi:Init management short buffer num: 32
I (573) wifi:Init dynamic tx buffer num: 32
I (583) wifi:Init static tx FG buffer num: 2
I (583) wifi:Init static rx buffer size: 1600
I (583) wifi:Init static rx buffer num: 10
I (593) wifi:Init dynamic rx buffer num: 32
I (593) wifi_init: rx ba win: 6
I (603) wifi_init: tcpip mbox: 32
I (603) wifi_init: udp mbox: 6
I (603) wifi_init: tcp mbox: 6
I (613) wifi_init: tcp tx win: 5760
I (613) wifi_init: tcp rx win: 5760
I (613) wifi_init: tcp mss: 1440
I (623) wifi_init: WiFi IRAM OP enabled
I (623) wifi_init: WiFi RX IRAM OP enabled
I (633) phy_init: phy_version 1170,f4aea9b,Apr 30 2024,10:49:24
I (683) wifi:mode : sta (48:31:b7:3d:b6:84)
I (683) wifi:enable tsf
I (683) foo_esp: Wifi started
I (3103) wifi:new:<6,0>, old:<1,0>, ap:<255,255>, sta:<6,0>, prof:11
I (3103) wifi:state: init -> auth (b0)
I (3103) wifi:state: auth -> assoc (0)
I (3113) wifi:state: assoc -> run (10)
I (3153) wifi:connected with LongoLongo, aid = 6, channel 6, BW20, bssid = 2c:3a:fd:cd:5b:54
I (3153) wifi:security: WPA2-PSK, phy: bgn, rssi: -89
I (3153) wifi:pm start, type: 1

I (3163) wifi:dp: 1, bi: 102400, li: 3, scale listen interval from 307200 us to 307200 us
I (3163) wifi:set rx beacon pti, rx_bcn_pti: 0, bcn_timeout: 25000, mt_pti: 0, mt_time: 10000
I (3173) wifi:AP's beacon interval = 102400 us, DTIM period = 1
I (3183) foo_esp: Wifi connected
I (3193) wifi:<ba-add>idx:0 (ifx:0, 2c:3a:fd:cd:5b:54), tid:6, ssn:2, winSize:64
I (6183) esp_netif_handlers: sta ip: 192.168.178.126, mask: 255.255.255.0, gw: 192.168.178.1
I (6183) foo_esp: Wifi netif up
I (6183) foo_esp: Wifi DHCP info: IpInfo { ip: 192.168.178.126, subnet: Subnet { gateway: 192.168.178.1, mask: Mask(24) }, dns: Some(192.168.178.1), secondary_dns: Some(0.0.0.0) }
I (6203) foo_esp: About to run an mDNS responder for our PC. It will be addressable using mypc.local, so try to `ping mypc.local`.

***ERROR*** A stack overflow in task pthread has been detected.
Core  0 register dump:
MEPC    : 0x403815ea  RA      : 0x403854bc  SP      : 0x3fc943f0  GP      : 0x3fc91400
0x403815ea - panic_abort
    at /.espressif/esp-idf/v5.2.2/components/esp_system/panic.c:466
0x403854bc - __ubsan_include
    at /.espressif/esp-idf/v5.2.2/components/esp_system/ubsan.c:313
0x3fc943f0 - xIsrStack
    at ??:??
0x3fc91400 - __global_pointer$
    at ??:??
TP      : 0x3fc76220  T0      : 0x4005890e  T1      : 0x0000000f  T2      : 0x00000002
S0/FP   : 0x3fc94414  S1      : 0x3fc94414  A0      : 0x3fc94414  A1      : 0x3c11bd28
0x3fc94414 - xIsrStack
    at ??:??
0x3fc94414 - xIsrStack
    at ??:??
0x3fc94414 - xIsrStack
    at ??:??
A2      : 0x0000000f  A3      : 0x3fc94441  A4      : 0x00000001  A5      : 0x3fc98000
0x3fc94441 - xIsrStack
    at ??:??
A6      : 0x3fcbbfd4  A7      : 0x00000014  S2      : 0x00001881  S3      : 0x00000001
S4      : 0x3fcbc2fc  S5      : 0x3fcbbfc0  S6      : 0x3fcbbee4  S7      : 0x00000001
S8      : 0x00000001  S9      : 0x3b9aca00  S10     : 0x40380206  S11     : 0x00001881
0x40380206 - _interrupt_handler
    at ??:??
T3      : 0x3fc98000  T4      : 0x00000001  T5      : 0x3fc98000  T6      : 0x00000001
MSTATUS : 0x00001801  MTVEC   : 0x40380001  MCAUSE  : 0x00000007  MTVAL   : 0x00000000
0x40380001 - _vector_table
    at ??:??
MHARTID : 0x00000000

Stack memory:
3fc943f0: 0x00000000 0x00000000 0x00000000 0x403864a0 0x00000000 0xff000000 0x3c11bcec 0x3fcbbd68
0x403864a0 - vPortTLSPointersDelCb
    at /.espressif/esp-idf/v5.2.2/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:720
3fc94410: 0x3c11bd14 0x452a2a2a 0x524f5252 0x202a2a2a 0x74732041 0x206b6361 0x7265766f 0x776f6c66
3fc94430: 0x206e6920 0x6b736174 0x68747020 0x64616572 0x73616820 0x65656220 0x6564206e 0x74636574
3fc94450: 0x002e6465 0x00000000 0x00000000 0x40000000 0x01004000 0x80000004 0x3fc98000 0x40387504
0x40387504 - vTaskSwitchContext
    at /.espressif/esp-idf/v5.2.2/components/freertos/FreeRTOS-Kernel/tasks.c:3675
3fc94470: 0x00001881 0x80000004 0x3fcbc2d8 0x40386bb6 0x60023000 0x40384fec 0x40384ff8 0x00000000
0x40384fec - systimer_ticks_to_us
    at /.espressif/esp-idf/v5.2.2/components/esp_hw_support/port/esp32c3/systimer.c:16
0x40384ff8 - systimer_us_to_ticks
    at /.espressif/esp-idf/v5.2.2/components/esp_hw_support/port/esp32c3/systimer.c:21
3fc94490: 0x3fc9448c 0x00000000 0x00000000 0x00000000 0x3fc944a4 0xffffffff 0x3fc944a4 0x3fc944a4
0x3fc9448c - s_common_recursive_mutex
    at ??:??
0x3fc944a4 - s_common_recursive_mutex
    at ??:??
0x3fc944a4 - s_common_recursive_mutex
    at ??:??
0x3fc944a4 - s_common_recursive_mutex
    at ??:??
3fc944b0: 0x00000000 0x3fc944b8 0xffffffff 0x3fc944b8 0x3fc944b8 0x00000001 0x00000001 0x00000000
0x3fc944b8 - s_common_recursive_mutex
    at ??:??
0x3fc944b8 - s_common_recursive_mutex
    at ??:??
0x3fc944b8 - s_common_recursive_mutex
    at ??:??
3fc944d0: 0x0001ffff 0x00000000 0x00000000 0x00000000 0x00000000 0x3fc944e0 0x00000000 0x00000000
0x3fc944e0 - s_common_mutex
    at ??:??
3fc944f0: 0x00000000 0x3fc944f8 0xffffffff 0x3fc944f8 0x3fc944f8 0x00000000 0x3fc9450c 0xffffffff
0x3fc944f8 - s_common_mutex
    at ??:??
0x3fc944f8 - s_common_mutex
    at ??:??
0x3fc944f8 - s_common_mutex
    at ??:??
0x3fc9450c - s_common_mutex
    at ??:??
3fc94510: 0x3fc9450c 0x3fc9450c 0x00000001 0x00000001 0x00000000 0x0001ffff 0x00000000 0x00000000
0x3fc9450c - s_common_mutex
    at ??:??
0x3fc9450c - s_common_mutex
    at ??:??
3fc94530: 0x00000000 0x60023000 0x40384fec 0x40384ff8 0x3fcb0538 0x3fcb3400 0x00000002 0x3fc9805c
0x40384fec - systimer_ticks_to_us
    at /.espressif/esp-idf/v5.2.2/components/esp_hw_support/port/esp32c3/systimer.c:16
0x40384ff8 - systimer_us_to_ticks
    at /.espressif/esp-idf/v5.2.2/components/esp_hw_support/port/esp32c3/systimer.c:21
3fc94550: 0x3fc98120 0x3fc981e4 0x3fcb9678 0x00000000 0x00000000 0x00000000 0x00000000 0x3fcbb7a4
3fc94570: 0x00000000 0x00010000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fc94590: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fc945b0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fc945d0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fc945f0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fc94610: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fc94630: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fc94650: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fc94670: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fc94690: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fc946b0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fc946d0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fc946f0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fc94710: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fc94730: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fc94750: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fc94770: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fc94790: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fc947b0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x01b2a8c0 0x00000000 0x00000000
3fc947d0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000

ELF file SHA256: 000000000

Rebooting...

Luni-4 commented 2 months ago

Ok, I was able to avoid the stack issue, setting CONFIG_ESP_MAIN_TASK_STACK_SIZE=120000.

Now I get a weird error, though:

I (19253) esp_idf_svc::wifi: EspWifi dropped
I (19253) esp_idf_svc::netif: Dropped
I (19253) esp_idf_svc::netif: Dropped
I (19263) wifi:Deinit lldesc rx mblock:10
I (19273) esp_idf_svc::nvs: NvsDefault dropped
I (19273) esp_idf_svc::eventloop: System event loop dropped
Error: ESP_ERR_TIMEOUT
I (19273) main_task: Returned from app_main()

I've tried to add a infinite loop to avoid the timeout, but same error

loop {
        // Sleep for one second and then continue the execution.
        std::thread::sleep(std::time::Duration::from_millis(1000));
}

ivmarkov commented 2 months ago

Put this in sdkconfig.defaults:

CONFIG_PTHREAD_TASK_STACK_SIZE_DEFAULT=8192

ivmarkov commented 2 months ago

This error

***ERROR*** A stack overflow in task pthread has been detected.

Is not in your main() thread but in the hidden async-io thread so you need to increase the stack of that thread, hence the above parameter.

As for the timeout - I'll follow up shortly.

Luni-4 commented 2 months ago

Thank you!

I tried with your change, so I had reverted the MAIN_TASK value to 40000, and now sdkconfig.defaults is:

CONFIG_ESP_MAIN_TASK_STACK_SIZE=40000
CONFIG_ESP_SYSTEM_EVENT_TASK_STACK_SIZE=4096
CONFIG_PTHREAD_TASK_STACK_SIZE_DEFAULT=8192

And now I get this error:

thread 'main' panicked at /.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-io-2.3.4/src/reactor.rs:104:39:
cannot initialize I/O event notification: Custom { kind: PermissionDenied, error: "failed to initialize eventfd for polling, try calling `esp_vfs_eventfd_register`" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

abort() was called at PC 0x42051e45 on core 0
0x42051e45 - panic_abort::__rust_start_panic::abort
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/panic_abort/src/lib.rs:48
Core  0 register dump:
MEPC    : 0x403815ea  RA      : 0x403854bc  SP      : 0x3fca17b0  GP      : 0x3fc91400
0x403815ea - panic_abort
    at /.espressif/esp-idf/v5.2.2/components/esp_system/panic.c:466
0x403854bc - __ubsan_include
    at /.espressif/esp-idf/v5.2.2/components/esp_system/ubsan.c:313
0x3fc91400 - __global_pointer$
    at ??:??
TP      : 0x3fc5cdc0  T0      : 0x37363534  T1      : 0x7271706f  T2      : 0x33323130
S0/FP   : 0x3fca17ec  S1      : 0x3fca17ec  A0      : 0x3fca17ec  A1      : 0x3fca17ce
A2      : 0x00000000  A3      : 0x3fca1819  A4      : 0x00000001  A5      : 0x3fc98000
A6      : 0x7a797877  A7      : 0x76757473  S2      : 0x3fca17d0  S3      : 0x00000001
S4      : 0x3c10e49c  S5      : 0x00000004  S6      : 0x3fca22d4  S7      : 0x3fca2314
0x3c10e49c - $d
    at ??:??
S8      : 0x00000002  S9      : 0x3fca230e  S10     : 0x00000001  S11     : 0x3fca2318
T3      : 0x6e6d6c6b  T4      : 0x6a696867  T5      : 0x66656463  T6      : 0x62613938
MSTATUS : 0x00001801  MTVEC   : 0x40380001  MCAUSE  : 0x00000007  MTVAL   : 0x00000000
0x40380001 - _vector_table
    at ??:??
MHARTID : 0x00000000

Stack memory:
3fca17b0: 0x3fc97870 0x3fca1904 0x3fca17ec 0x4038c7b8 0x00000000 0x00000001 0x3fca181c 0x42040030
0x3fc97870 - std::sys::backtrace::lock::LOCK
    at ??:??
0x4038c7b8 - __assert_func
    at /.espressif/esp-idf/v5.2.2/components/newlib/assert.c:34
0x42040030 - <&mut W as core::fmt::Write::write_fmt::SpecWriteFmt>::spec_write_fmt
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:226
3fca17d0: 0x35303234 0x35346531 0x00000000 0x3fc92f34 0x3fca17d0 0x3fc92f50 0x3fca17cc 0x726f6261
3fca17f0: 0x20292874 0x20736177 0x6c6c6163 0x61206465 0x43502074 0x34783020 0x31353032 0x20353465
3fca1810: 0x63206e6f 0x2065726f 0x00000030 0x3fca0000 0x00000000 0x3fc93a88 0x3fca18d0 0x42051e48
0x3fc93a88 - std::thread::ThreadId::new::COUNTER
    at ??:??
0x42051e48 - object::endian::U16Bytes<E>::get
    at /.cargo/registry/src/index.crates.io-6f17d22bba15001f/object-0.36.2/src/endian.rs:636
3fca1830: 0x3fca1814 0x3fca180f 0x00000000 0x00000000 0x00000020 0x3fca1824 0x3fc90c44 0x42035ef0
0x3fc90c44 - std::panicking::panic_count::LOCAL_PANIC_COUNT::{{closure}}::VAL
    at ??:??
0x42035ef0 - std::sys::thread_local::key::unix::get
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/thread_local/key/unix.rs:21
3fca1850: 0x00000000 0x3fc93a88 0x3fca18d0 0x4204048e 0x00000009 0x3fc93a88 0x3fca18d0 0x4204f2aa
0x3fc93a88 - std::thread::ThreadId::new::COUNTER
    at ??:??
0x4204048e - std::thread::local::LocalKey<T>::try_with
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:282
0x3fc93a88 - std::thread::ThreadId::new::COUNTER
    at ??:??
0x4204f2aa - core::fmt::Arguments::new_const
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:339
3fca1870: 0x3fca18d0 0x3c10e49c 0x3c0f608c 0x00000002 0x00000001 0x3fcb46a8 0x3fcb46d8 0x3fc93a8c
0x3c10e49c - $d
    at ??:??
0x3c0f608c - $d
    at ??:??
0x3fc93a8c - std::panicking::HOOK
    at ??:??
3fca1890: 0x3fc93a88 0x3fcb46a8 0x00000000 0x3fca18d0 0x3c10e460 0x3c0f608c 0x00000001 0x420174ca
0x3fc93a88 - std::thread::ThreadId::new::COUNTER
    at ??:??
0x3c10e460 - $d
    at ??:??
0x3c0f608c - $d
    at ??:??
0x420174ca - event_listener::Event<T>::inner
    at /.cargo/registry/src/index.crates.io-6f17d22bba15001f/event-listener-5.3.1/src/lib.rs:476
3fca18b0: 0x00000000 0x00000004 0x00000003 0x00000002 0x3fc938c8 0x3c0f608c 0x3fca1918 0x4204efb2
0x3fc938c8 - async_io::reactor::Reactor::get::REACTOR
    at ??:??
0x3c0f608c - $d
    at ??:??
0x4204efb2 - std::panicking::payload_as_str
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:747
3fca18d0: 0x00000140 0x3fcb47e4 0x000000a6 0x3fca18e4 0x00000000 0x3c116d20 0x00000002 0x3fca1970
0x3c116d20 - $d
    at ??:??
3fca18f0: 0x00000002 0x00000000 0x00000002 0x3c0f608c 0x3fca1918 0x3fc93700 0x3c0f608c 0x420625d4
0x3c0f608c - $d
    at ??:??
0x3c0f608c - $d
    at ??:??
0x420625d4 - core::panicking::panic_nounwind_fmt
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/panicking.rs:122
3fca1910: 0x3fcb1b18 0x00000008 0x3c116d20 0x00000002 0x3fca1970 0x00000002 0x00000000 0x00000002
0x3c116d20 - $d
    at ??:??
3fca1930: 0x3c0f608c 0x3fc90001 0x3fca1f80 0x42062880 0xa5a5a5a5 0xa5a5a5a5 0x3c0f6008 0x00000028
0x3c0f608c - $d
    at ??:??
0x42062880 - <*mut T as core::fmt::Pointer>::fmt
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:2549
0x3c0f6008 - $d
    at ??:??
3fca1950: 0x3fca1bc0 0x3c0f5dc0 0x3c116d20 0x00000002 0x3fca1970 0x00000002 0x00000000 0x00000002
0x3c0f5dc0 - $d
    at ??:??
0x3c116d20 - $d
    at ??:??
3fca1970: 0x3fca1948 0x4205f072 0x3fca1950 0x4205efb8 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
0x4205f072 - <&T as core::fmt::Display>::fmt
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:2382
0x4205efb8 - <&T as core::fmt::Debug>::fmt
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:2382
3fca1990: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca19b0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0x3fc93700 0x3fca21ab 0x00000000 0x3fc93700
3fca19d0: 0x3fca21ab 0xff000000 0x3fc93700 0x00000000 0x3c0f1461 0x3fca2064 0x3fca2064 0x3fc98668
3fca19f0: 0x0000000a 0x3fca20b4 0x60043000 0x00000000 0x0000000e 0x3fca398c 0x3fca42a0 0x40385bc6
0x40385bc6 - xQueueGiveMutexRecursive
    at /.espressif/esp-idf/v5.2.2/components/freertos/FreeRTOS-Kernel/queue.c:789
3fca1a10: 0x0000000e 0x3fc91038 0x3fc98676 0x42070d36 0x3fca2758 0x00000001 0x00000005 0x00000000
0x3fc91038 - s_fd_table
    at ??:??
0x42070d36 - usb_serial_jtag_write
    at /.espressif/esp-idf/v5.2.2/components/vfs/vfs_usb_serial_jtag.c:164
3fca1a30: 0x3c0fef76 0x3fca20b4 0x3fca20b4 0x3fc98668 0x40386354 0x40385a92 0x3fca2080 0x3fc91400
0x3c0fef76 - $d
    at ??:??
0x40386354 - vPortClearInterruptMaskFromISR
    at /.espressif/esp-idf/v5.2.2/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:520
0x40385a92 - xQueueGenericSend
    at /.espressif/esp-idf/v5.2.2/components/freertos/FreeRTOS-Kernel/queue.c:1057
0x3fc91400 - __global_pointer$
    at ??:??
3fca1a50: 0x3fc5cdc0 0x00000000 0x00000000 0x00000000 0x3fcafba0 0x00000000 0x00000001 0x00000001
3fca1a70: 0x3fc98000 0x3fc98000 0x00000000 0x600c2194 0x00000006 0x00000006 0x00000000 0x3fca20cc
3fca1a90: 0xffffffff 0x00000002 0x3fcafbb0 0x3fca2314 0x00000002 0x3fca230e 0x00000001 0x3fca2318
3fca1ab0: 0x00000000 0x00000010 0x00000000 0x00000000 0x00000000 0x00000010 0x00000000 0x40385fc4
0x40385fc4 - xQueueSemaphoreTake
    at /.espressif/esp-idf/v5.2.2/components/freertos/FreeRTOS-Kernel/queue.c:1731
3fca1ad0: 0x00000005 0x00000054 0x00000804 0xffffffff 0x3fca22d4 0x00000004 0x00000003 0x3fca2308
3fca1af0: 0x0000001c 0x42085622 0x00000003 0x3fca2308 0x0000001c 0x00000000 0x3fcaf9d0 0x40385524
0x42085622 - lwip_netconn_do_bind
    at /.espressif/esp-idf/v5.2.2/components/lwip/lwip/src/api/api_msg.c:1281
0x40385524 - prvCopyDataToQueue
    at /.espressif/esp-idf/v5.2.2/components/freertos/FreeRTOS-Kernel/queue.c:2470
3fca1b10: 0x00000000 0x00000000 0x3fcaf9d0 0x40385a3c 0x00000000 0x42085622 0x3fca2118 0x00000000
0x40385a3c - xQueueGenericSend
    at /.espressif/esp-idf/v5.2.2/components/freertos/FreeRTOS-Kernel/queue.c:966
0x42085622 - lwip_netconn_do_bind
    at /.espressif/esp-idf/v5.2.2/components/lwip/lwip/src/api/api_msg.c:1281
3fca1b30: 0x3fca22d4 0x00000004 0x00000003 0x3fca2308 0x3fca22d4 0x00000004 0x00000003 0x3fca2308
3fca1b50: 0x0000001c 0x00000000 0x3fcaf9d0 0x40385524 0x00000000 0x00000000 0x3fcaf9d0 0x40385524
0x40385524 - prvCopyDataToQueue
    at /.espressif/esp-idf/v5.2.2/components/freertos/FreeRTOS-Kernel/queue.c:2470
0x40385524 - prvCopyDataToQueue
    at /.espressif/esp-idf/v5.2.2/components/freertos/FreeRTOS-Kernel/queue.c:2470
3fca1b70: 0x00000000 0x00000000 0x3fcaf9d0 0x40385a3c 0x0000001c 0x3fca2190 0x00000003 0x00000000
0x40385a3c - xQueueGenericSend
    at /.espressif/esp-idf/v5.2.2/components/freertos/FreeRTOS-Kernel/queue.c:966
3fca1b90: 0x3fca22d4 0x00000004 0x00000003 0x3fca2308 0x3fca22d4 0x00000004 0x00000003 0x3fca2308

ELF file SHA256: 000000000

Luni-4 commented 2 months ago

Running more times seems to have fixed the Permission denied issue, so it was a spurious error. But the timeout one remains.

ivmarkov commented 2 months ago

Add this line early on during startup.

Luni-4 commented 2 months ago

Add this line early on during startup.

Ok, added, thank you! I also updated the code above accordingly

Luni-4 commented 2 months ago

I've tried to run the code many times, and sometimes I get this error:

thread 'main' panicked at src/main.rs:72:6:
called `Result::unwrap()` on an `Err` value: IoError(Os { code: 125, kind: AddrNotAvailable, message: "Address not available" })
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

abort() was called at PC 0x42051e9d on core 0
0x42051e9d - panic_abort::__rust_start_panic::abort
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/panic_abort/src/lib.rs:48
Core  0 register dump:
MEPC    : 0x403815ea  RA      : 0x403854bc  SP      : 0x3fca2610  GP      : 0x3fc91400
0x403815ea - panic_abort
    at /.espressif/esp-idf/v5.2.2/components/esp_system/panic.c:466
0x403854bc - __ubsan_include
    at /.espressif/esp-idf/v5.2.2/components/esp_system/ubsan.c:313
0x3fc91400 - __global_pointer$
    at ??:??
TP      : 0x3fc5cda0  T0      : 0x37363534  T1      : 0x7271706f  T2      : 0x33323130
S0/FP   : 0x3fca264c  S1      : 0x3fca264c  A0      : 0x3fca264c  A1      : 0x3fca262e
A2      : 0x00000000  A3      : 0x3fca2679  A4      : 0x00000001  A5      : 0x3fc98000
A6      : 0x7a797877  A7      : 0x76757473  S2      : 0x3fca2630  S3      : 0x00000001
S4      : 0x3c10e4bc  S5      : 0x00000000  S6      : 0x00000000  S7      : 0x00000000
0x3c10e4bc - $d
    at ??:??
S8      : 0x00000000  S9      : 0x00000000  S10     : 0x00000000  S11     : 0x00000000
T3      : 0x6e6d6c6b  T4      : 0x6a696867  T5      : 0x66656463  T6      : 0x62613938
MSTATUS : 0x00001801  MTVEC   : 0x40380001  MCAUSE  : 0x00000007  MTVAL   : 0x00000000
0x40380001 - _vector_table
    at ??:??
MHARTID : 0x00000000

Stack memory:
3fca2610: 0x3fc97870 0x3fca2704 0x3fca264c 0x4038c7b8 0x00000000 0x00000001 0x3fca267c 0x42040030
0x3fc97870 - std::sys::backtrace::lock::LOCK
    at ??:??
0x4038c7b8 - __assert_func
    at /.espressif/esp-idf/v5.2.2/components/newlib/assert.c:34
0x42040030 - core::char::methods::encode_utf8_raw
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/char/methods.rs:1782
3fca2630: 0x35303234 0x64396531 0x00000000 0x3fc92f34 0x3fca2630 0x3fc92f50 0x3fca262c 0x726f6261
3fca2650: 0x20292874 0x20736177 0x6c6c6163 0x61206465 0x43502074 0x34783020 0x31353032 0x20643965
3fca2670: 0x63206e6f 0x2065726f 0x00000030 0x3fca0000 0x00000000 0x3fc93a88 0x3fca2730 0x42051ea0
0x3fc93a88 - std::thread::ThreadId::new::COUNTER
    at ??:??
0x42051ea0 - object::endian::U16Bytes<E>::get
    at /.cargo/registry/src/index.crates.io-6f17d22bba15001f/object-0.36.2/src/endian.rs:636
3fca2690: 0x3fca2674 0x3fca266f 0x00000000 0x00000000 0x00000020 0x3fca2684 0x3fc90c44 0x42035f48
0x3fc90c44 - std::panicking::panic_count::LOCAL_PANIC_COUNT::{{closure}}::VAL
    at ??:??
0x42035f48 - std::sys::thread_local::key::unix::get
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/thread_local/key/unix.rs:21
3fca26b0: 0x00000000 0x3fc93a88 0x3fca2730 0x420404e6 0x00000009 0x3fc93a88 0x3fca2730 0x4204f302
0x3fc93a88 - std::thread::ThreadId::new::COUNTER
    at ??:??
0x420404e6 - std::thread::local::LocalKey<T>::try_with
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:282
0x3fc93a88 - std::thread::ThreadId::new::COUNTER
    at ??:??
0x4204f302 - core::fmt::Arguments::new_const
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:339
3fca26d0: 0x3fca2730 0x3c10e4bc 0x3c0f1afc 0x403818a8 0x3fca44a0 0x3fca4470 0x00000000 0x3fc93a8c
0x3c10e4bc - $d
    at ??:??
0x3c0f1afc - $d
    at ??:??
0x403818a8 - heap_caps_malloc
    at /.espressif/esp-idf/v5.2.2/components/heap/heap_caps.c:202
0x3fc93a8c - std::panicking::HOOK
    at ??:??
3fca26f0: 0x3fc93a88 0x00000000 0x00000010 0x3fca2730 0x3c10e480 0x3c0f1afc 0x00000001 0x420364d6
0x3fc93a88 - std::thread::ThreadId::new::COUNTER
    at ??:??
0x3c10e480 - $d
    at ??:??
0x3c0f1afc - $d
    at ??:??
0x420364d6 - std::sys::thread_local::key::unix::set
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/thread_local/key/unix.rs:14
3fca2710: 0x00000000 0x3fca3918 0x0000a8c0 0x3fca3410 0x7eb2a8c0 0x3c0f1afc 0x3fca2778 0x4204f00a
0x3c0f1afc - $d
    at ??:??
0x4204f00a - std::panicking::payload_as_str
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:747
3fca2730: 0x000000ac 0x3fcb6120 0x00000080 0x3fca2744 0x00000036 0x3c116d40 0x00000002 0x3fca27d0
0x3c116d40 - $d
    at ??:??
3fca2750: 0x00000002 0x00000000 0x3fca3410 0x3c0f1afc 0x3fca2778 0x000101b2 0x3c0f1afc 0x4206262c
0x3c0f1afc - $d
    at ??:??
0x3c0f1afc - $d
    at ??:??
0x4206262c - core::panicking::panic_nounwind_fmt
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/panicking.rs:122
3fca2770: 0x00000000 0x000014e9 0x3c116d40 0x00000002 0x3fca27d0 0x00000002 0x00000000 0x3fca3410
0x3c116d40 - $d
    at ??:??
3fca2790: 0x3c0f1afc 0x3c0f0001 0x00007eb2 0x420628d8 0x3c0f4120 0x00000007 0x3c0f19a4 0x0000002b
0x3c0f1afc - $d
    at ??:??
0x420628d8 - <*mut T as core::fmt::Pointer>::fmt
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:2549
0x3c0f4120 - $d
    at ??:??
0x3c0f19a4 - $d
    at ??:??
3fca27b0: 0x3fca3418 0x3c0f1994 0x3c116d40 0x00000002 0x3fca27d0 0x00000002 0x00000000 0x3fca3410
0x3c0f1994 - $d
    at ??:??
0x3c116d40 - $d
    at ??:??
3fca27d0: 0x3fca27a8 0x4205f0ca 0x3fca27b0 0x4205f010 0xa5a5a5a5 0x3fca5ec8 0x00000000 0x3fca5ec8
0x4205f0ca - <&T as core::fmt::Display>::fmt
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:2382
0x4205f010 - <&T as core::fmt::Debug>::fmt
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:2382
3fca27f0: 0x3fcafbdc 0x3fcafc20 0x3c12164c 0x0000000b 0xffffffff 0x3fcafbbc 0x3fca60bc 0x3fcb1124
3fca2810: 0x3fcb0f6c 0x3fca5ec8 0xb2a8c001 0x00000101 0xa8c00000 0xa8c07eb2 0xa51801b2 0xa5000000
3fca2830: 0x00000000 0x00000000 0x3c0f1af4 0x00000000 0x00000000 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
0x3c0f1af4 - $d
    at ??:??
3fca2850: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca2870: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca2890: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca28b0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca28d0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca28f0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca2910: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca2930: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca2950: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca2970: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca2990: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca29b0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca29d0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca29f0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5

ELF file SHA256: 000000000

other than the timeout error from before

ivmarkov commented 2 months ago

Paste your code somewhere. I'll try it out at my end.

Luni-4 commented 2 months ago

Thanks a lot! I've pushed the entire repository here

ivmarkov commented 2 months ago

See https://github.com/Luni-4/foo-esp/pull/1

Luni-4 commented 2 months ago

Thanks a lot! Now it works perfectly! :)

Sometimes, when I launch cargo run, the ESP_ERR_TIMEOUT appears, but I do not think it is related to this issue. You can fix that, launching cargo run again.

I (694) foo_esp: Wifi started
I (3384) wifi:new:<6,0>, old:<1,0>, ap:<255,255>, sta:<6,0>, prof:11
I (3384) wifi:state: init -> auth (b0)
I (3384) wifi:state: auth -> init (8a0)
I (3394) wifi:new:<6,0>, old:<6,0>, ap:<255,255>, sta:<6,0>, prof:11
I (15704) wifi:flush txq
I (15704) wifi:stop sw txq
I (15704) wifi:lmac stop hw txq
I (15704) esp_idf_svc::wifi: EspWifi dropped
I (15704) esp_idf_svc::netif: Dropped
I (15714) esp_idf_svc::netif: Dropped
I (15714) wifi:Deinit lldesc rx mblock:10
I (15734) esp_idf_svc::nvs: NvsDefault dropped
I (15734) esp_idf_svc::eventloop: System event loop dropped
Error: ESP_ERR_TIMEOUT
I (15734) main_task: Returned from app_main()

Luni-4 commented 2 months ago

A small update.

I was able to work around the ESP_ERROR_TIMEOUT issue with the unwrap() function instead of stack unwinding the various errors. When a timeout occurs, ESP32-C3 panics, reboots, and it can now connect to Wi-Fi.

I have also reduced the stack usage to CONFIG_ESP_MAIN_TASK_STACK_SIZE=70000 building with the following release profile and using the unwrap() function everywhere in the main code.

[profile.release]
codegen-units = 1 # LLVM can perform better optimizations using a single thread
debug = 2
debug-assertions = false
incremental = false
lto = 'fat'
# Optimize for binary size, but with loop vectorization.
opt-level = 's'
overflow-checks = false

I do not know if it's the correct way, but it seems to work for me now. Thanks again @ivmarkov and @MabezDev for your help! :)

ivmarkov commented 2 months ago

A small update.

I was able to work around the ESP_ERROR_TIMEOUT issue using unwrap instead of stack unwinding the errors. When a timeout occurs, ESP32-C3 reboots, and it can connect to Wi-Fi.

I have also reduced the stack usage to CONFIG_ESP_MAIN_TASK_STACK_SIZE=70000 building with the following release profile and using the unwrap() function everywhere in the main code.
[profile.release]
codegen-units = 1 # LLVM can perform better optimizations using a single thread
debug = 2
debug-assertions = false
incremental = false
lto = 'fat'
# Optimize for binary size, but with loop vectorization.
opt-level = 's'
overflow-checks = false
I do not know if it's the correct way, but it seems to work for me now. Thanks again @ivmarkov and @MabezDev for your help! :)

The ESP_ERR_TIMEOUT is in the meantime fixed in esp-idf-svc itself, so if you [patch.crates-io] all esp-idf-* versions to their git master, it should disappear.

As for (ab) using unwrap specifically to reduce stack size - this is likely having zero influence on your stack usage.

Luni-4 commented 2 months ago

The ESP_ERR_TIMEOUT is in the meantime fixed in esp-idf-svc itself, so if you [patch.crates-io] all esp-idf-* versions to their git master, it should disappear.

Oh, thanks! I'm going to update my dependency soon then.

As for (ab) using unwrap specifically to reduce stack size - this is likely having zero influence on your stack usage.

Hmm, this is weird then. I have tried to use that release profile without using unwrap, but no stack changes at all. I have always run cargo clean before any cargo run --release command. Perhaps I screwed up somewhere else, I need to verify.

Luni-4 commented 2 months ago

The ESP_ERR_TIMEOUT is in the meantime fixed in esp-idf-svc itself, so if you [patch.crates-io] all esp-idf-* versions to their git master, it should disappear.

I have tried to update the Cargo.toml adding these patches:

[patch.crates-io]
esp-idf-hal = { git = "https://github.com/esp-rs/esp-idf-hal" }
esp-idf-sys = { git = "https://github.com/esp-rs/esp-idf-sys" }
esp-idf-svc = { git = "https://github.com/esp-rs/esp-idf-svc" }

and increasing the version in .cargo/config.toml to:

[env]
# Enables the esp-idf-sys "native" build feature (`cargo build --features native`) to build against ESP-IDF (v5.2.1)
ESP_IDF_VERSION = { value = "tag:v5.3.1" }

but I get this error

thread 'main' panicked at src/main.rs:118:44:
called `Result::unwrap()` on an `Err` value: "Esp32-C3 input/output: ESP_ERR_HTTPD_TASK"
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

abort() was called at PC 0x4201fdfb on core 0
0x4201fdfb - panic_abort::__rust_start_panic::abort
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/panic_abort/src/lib.rs:48
Core  0 register dump:
MEPC    : 0x403807d4  RA      : 0x403858e0  SP      : 0x3fca1530  GP      : 0x3fc92000
0x403807d4 - panic_abort
    at /.espressif/esp-idf/v5.3.1/components/esp_system/panic.c:463
0x403858e0 - __ubsan_include
    at /.espressif/esp-idf/v5.3.1/components/esp_system/ubsan.c:311
0x3fc92000 - g_timer_info
    at ??:??
TP      : 0x3fcabea0  T0      : 0x37363534  T1      : 0x7271706f  T2      : 0x33323130
S0/FP   : 0x3fca156c  S1      : 0x3fca156c  A0      : 0x3fca156c  A1      : 0x3fca154e
A2      : 0x00000000  A3      : 0x3fca1599  A4      : 0x00000001  A5      : 0x3fc99000
A6      : 0x7a797877  A7      : 0x76757473  S2      : 0x3fca1550  S3      : 0x00000000
S4      : 0x00000001  S5      : 0x00000000  S6      : 0x00000000  S7      : 0x3fca1f88
S8      : 0x3fca6f10  S9      : 0x3fcbb37c  S10     : 0x00000004  S11     : 0x3fca1fc0
T3      : 0x6e6d6c6b  T4      : 0x6a696867  T5      : 0x66656463  T6      : 0x62613938
MSTATUS : 0x00001801  MTVEC   : 0x40380001  MCAUSE  : 0x00000007  MTVAL   : 0x00000000
0x40380001 - _vector_table
    at /.espressif/esp-idf/v5.3.1/components/riscv/vectors_intc.S:54
MHARTID : 0x00000000

Stack memory:
3fca1530: 0x00000000 0x00000000 0x3fca156c 0x4038cf00 0x00000001 0x3fca15d8 0x3fcbb438 0x42040030
0x4038cf00 - __assert_func
    at /.espressif/esp-idf/v5.3.1/components/newlib/assert.c:33
0x42040030 - core::ops::function::impls::<impl core::ops::function::FnMut<A> for &mut F>::call_mut
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:294
3fca1550: 0x31303234 0x62666466 0x4202ad00 0x3fc93684 0x3fca1550 0x3fc936a0 0x3fca154c 0x726f6261
0x4202ad00 - std::sys::thread_local::key::racy::LazyKey::lazy_init
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/thread_local/key/racy.rs:46
3fca1570: 0x20292874 0x20736177 0x6c6c6163 0x61206465 0x43502074 0x34783020 0x66313032 0x20626664
3fca1590: 0x63206e6f 0x2065726f 0x00000030 0x00000000 0x3fcac858 0x00000000 0x3fc94988 0x4201fdfe
0x3fc94988 - std::io::stdio::STDOUT
    at ??:??
0x4201fdfe - std::sys::backtrace::__rust_end_short_backtrace
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/backtrace.rs:170
3fca15b0: 0xffffbfff 0x3fca1620 0x3c0eac9c 0x3c0e1ba0 0x3c0e1ba0 0x3fc949c8 0x3c0ea028 0x00000004
0x3c0eac9c - $d
    at ??:??
0x3c0e1ba0 - $d
    at ??:??
0x3c0e1ba0 - $d
    at ??:??
0x3fc949c8 - s_log_cache
    at ??:??
0x3c0ea028 - $d
    at ??:??
3fca15d0: 0x00000003 0xffff8fff 0x00000009 0x3fca15c0 0x3fca15f4 0x3fca15f3 0x00000000 0x00000000
3fca15f0: 0x02ffbfff 0x3fcbbe78 0x00000058 0x00000100 0x3fca6f10 0x3fca24f8 0x3fcab928 0x3c0e34e4
0x3c0e34e4 - $d
    at ??:??
3fca1610: 0x3fcbaa1c 0x3c0e1ba0 0x3fca1668 0x42043568 0x000000ac 0x3fcbbe78 0x00000058 0x3fca1634
0x3c0e1ba0 - $d
    at ??:??
0x42043568 - std::panicking::rust_panic_with_hook
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:763
3fca1630: 0x0000000b 0x3c0eae28 0x00000002 0x3fca16c0 0x00000002 0x00000000 0x3c0e34e4 0x3c0e1ba0
0x3c0eae28 - $d
    at ??:??
0x3c0e34e4 - $d
    at ??:??
0x3c0e1ba0 - $d
    at ??:??
3fca1650: 0x3fca1668 0x00000006 0x3c0e1ba0 0x42012c48 0x00000000 0x3fcab918 0x3c0eae28 0x00000002
0x3c0e1ba0 - $d
    at ??:??
0x42012c48 - core::fmt::num::imp::fmt_u32
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/num.rs:213
0x3c0eae28 - $d
    at ??:??
3fca1670: 0x3fca16c0 0x00000002 0x00000000 0x3c0e34e4 0x3c0e1ba0 0x00000001 0x00005000 0x42014a48
0x3c0e34e4 - $d
    at ??:??
0x3c0e1ba0 - $d
    at ??:??
0x42014a48 - <&T as core::fmt::LowerHex>::fmt
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:2382
3fca1690: 0x3fca6f10 0x3fcaf3f0 0x3c0e959c 0x0000002b 0x3fca6f10 0x3c0e192c 0x3c0eae28 0x00000002
0x3c0e959c - $d
    at ??:??
0x3c0e192c - $d
    at ??:??
0x3c0eae28 - $d
    at ??:??
3fca16b0: 0x3fca16c0 0x00000002 0x00000000 0x3c0e34e4 0x3fca1698 0x420134aa 0x3fca16a0 0x420134ba
0x3c0e34e4 - $d
    at ??:??
0x420134aa - <&T as core::fmt::Display>::fmt
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:2382
0x420134ba - <&T as core::fmt::Debug>::fmt
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:2382
3fca16d0: 0xa5a5a5a5 0x00000000 0x3fcaf3f0 0x3fcb9168 0x3fcb91ac 0x3c0f4c30 0x0000000b 0xffffffff
3fca16f0: 0x3fcb9148 0x3fcaf5e4 0x3fcba6b4 0x3fcba4f8 0x3fcaf3f0 0x7eb2a8c0 0x00000000 0xa5a5a5a5
3fca1710: 0x00000001 0x3c0e18e8 0x3c0e1b22 0x0000000a 0x3c0e1b18 0x0000000a 0x00000000 0x00000000
0x3c0e18e8 - $d
    at ??:??
0x3c0e1b22 - $d
    at ??:??
0x3c0e1b18 - $d
    at ??:??
3fca1730: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fca1750: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0xa5a5a5a5 0xa5a5a5a5
3fca1770: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca1790: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca17b0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca17d0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca17f0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca1810: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca1830: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca1850: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca1870: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca1890: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca18b0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca18d0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca18f0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fca1910: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5

ELF file SHA256: 000000000

Luni-4 commented 2 months ago

If I switch back to ESP_IDF_VERSION = { value = "tag:v5.2.2" } with the patches, the example compiles, but the timeout problem remains

ivmarkov commented 2 months ago

By upgrading both to master versions of the esp-idf-* crates, as well as upgrading to ESP IDF V5.3.1, where support for ESP IDF 5.3 is not even released yet, you take two risks simultaneously.

Stay with ESP IDF 5.2.2 max, while still using the master versions of the esp-idf-* crates.

Even though the error you are reporting should've been fixed by this: https://github.com/esp-rs/esp-idf-svc/commit/fb03bd77785a48672a7184c1393959e9e62da75e

Perhaps you should issue a cargo update?

ivmarkov commented 2 months ago

If I switch back to ESP_IDF_VERSION = { value = "tag:v5.2.2" } with the patches, the example compiles, but the timeout problem remains

Hmmm, I don't have a good explanation for that. :(

For me - at least on the c6 - the TIMEOUT issue is fixed with latest master.

Luni-4 commented 2 months ago

I've tried to update esp-idf-svc through git and branch master, but now I cannot build the project anymore. I get this error because it seems that this API has been removed:

error[E0425]: cannot find function `initialize_eventfd` in module `esp_idf_svc::io::vfs`
  --> src/main.rs:44:27
   |
44 |     esp_idf_svc::io::vfs::initialize_eventfd(5).unwrap();
   |                           ^^^^^^^^^^^^^^^^^^ not found in `esp_idf_svc::io::vfs`

ivmarkov commented 2 months ago

I've tried to update esp-idf-svc through git and branch master, but now I cannot build the project anymore. I get this error because it seems that this API has been removed:
error[E0425]: cannot find function `initialize_eventfd` in module `esp_idf_svc::io::vfs`
  --> src/main.rs:44:27
   |
44 |     esp_idf_svc::io::vfs::initialize_eventfd(5).unwrap();
   |                           ^^^^^^^^^^^^^^^^^^ not found in `esp_idf_svc::io::vfs`

There is an alternative API in this file. Just look inside this module.

Luni-4 commented 2 months ago

@ivmarkov

I have replaced that API with

 esp_idf_svc::io::vfs::MountedEventfs::mount(5).unwrap();

but I get the same error obtained here

thread 'main' panicked at /.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-io-2.3.4/src/reactor.rs:104:39:
cannot initialize I/O event notification: Custom { kind: PermissionDenied, error: "failed to initialize eventfd for polling, try calling `esp_vfs_eventfd_register`" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

abort() was called at PC 0x420206f7 on core 0
0x420206f7 - panic_abort::__rust_start_panic::abort
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/panic_abort/src/lib.rs:48
Core  0 register dump:
MEPC    : 0x40380698  RA      : 0x4038546a  SP      : 0x3fc9ae80  GP      : 0x3fc91400
0x40380698 - panic_abort
    at /.espressif/esp-idf/v5.2.2/components/esp_system/panic.c:466
0x4038546a - __ubsan_include
    at /.espressif/esp-idf/v5.2.2/components/esp_system/ubsan.c:313
0x3fc91400 - __global_pointer$
    at ??:??
TP      : 0x3fc7d6c0  T0      : 0x37363534  T1      : 0x7271706f  T2      : 0x33323130
S0/FP   : 0x3fc9aebc  S1      : 0x3fc9aebc  A0      : 0x3fc9aebc  A1      : 0x3fc9ae9e
A2      : 0x00000000  A3      : 0x3fc9aee9  A4      : 0x00000001  A5      : 0x3fc97000
0x3fc97000 - g_cnxMgr
    at ??:??
A6      : 0x7a797877  A7      : 0x76757473  S2      : 0x3fc9aea0  S3      : 0x00000000
S4      : 0x00000001  S5      : 0x00000000  S6      : 0x00000000  S7      : 0x3fcbd43c
S8      : 0x00000000  S9      : 0x3fcbfa14  S10     : 0x00000000  S11     : 0x00000003
T3      : 0x6e6d6c6b  T4      : 0x6a696867  T5      : 0x66656463  T6      : 0x62613938
MSTATUS : 0x00001801  MTVEC   : 0x40380001  MCAUSE  : 0x00000007  MTVAL   : 0x00000000
0x40380001 - _vector_table
    at ??:??
MHARTID : 0x00000000

Stack memory:
3fc9ae80: 0x00000000 0x00000000 0x3fc9aebc 0x4038c766 0x00000001 0x3fc9af28 0x3fcbfba8 0x42040030
0x4038c766 - __assert_func
    at /.espressif/esp-idf/v5.2.2/components/newlib/assert.c:34
0x42040030 - <core::result::Result<T,E> as core::ops::try_trait::Try>::branch
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/result.rs:1987
3fc9aea0: 0x32303234 0x37663630 0x4202b700 0x3fc9281c 0x3fc9aea0 0x3fc92838 0x3fc9ae9c 0x726f6261
0x4202b700 - std::sys::thread_local::key::racy::LazyKey::lazy_init
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:44
3fc9aec0: 0x20292874 0x20736177 0x6c6c6163 0x61206465 0x43502074 0x34783020 0x30323032 0x20376636
3fc9aee0: 0x63206e6f 0x2065726f 0x00000030 0x00000000 0x3fcab768 0x00000000 0x3fc93a08 0x420206fa
0x3fc93a08 - std::io::stdio::STDOUT
    at ??:??
0x420206fa - std::sys::backtrace::__rust_end_short_backtrace
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/backtrace.rs:170
3fc9af00: 0x00000000 0x3fc9af70 0x3c0daebc 0x3c0d3a28 0x3c0d3a28 0x00000054 0x3c0da248 0x00000004
0x3c0daebc - $d
    at ??:??
0x3c0d3a28 - $d
    at ??:??
0x3c0d3a28 - $d
    at ??:??
0x3c0da248 - $d
    at ??:??
3fc9af20: 0x00000000 0x3fc98000 0x00000009 0x3fc9af10 0x3fc9af44 0x3fc9af43 0x00000804 0x4038098a
0x4038098a - heap_caps_malloc_base
    at /.espressif/esp-idf/v5.2.2/components/heap/heap_caps.c:180
3fc9af40: 0x02c98000 0x3fcbfa54 0x000000a6 0xc0380000 0x3fcbd49c 0x3fcbd398 0x3fcbd36c 0x00000000
3fc9af60: 0x3fc93680 0x3c0d3a28 0x3fc9afb8 0x42043e52 0x00000140 0x3fcbfa54 0x000000a6 0x3fc9af84
0x3c0d3a28 - $d
    at ??:??
0x42043e52 - std::panicking::rust_panic_with_hook
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:763
3fc9af80: 0x00000010 0x3c0db048 0x00000002 0x3fc9b010 0x00000002 0x00000000 0x00000000 0x3c0d3a28
0x3c0db048 - $d
    at ??:??
0x3c0d3a28 - $d
    at ??:??
3fc9afa0: 0x3fc9afb8 0x00000001 0x3c0d3a28 0x42013084 0x3fcbd49c 0x3fcbd398 0x3c0db048 0x00000002
0x3c0d3a28 - $d
    at ??:??
0x42013084 - core::fmt::num::imp::fmt_u32
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/num.rs:213
0x3c0db048 - $d
    at ??:??
3fc9afc0: 0x3fc9b010 0x00000002 0x00000000 0x00000000 0x3c0d3a28 0x3fcb0001 0x3fc93688 0x42014e84
0x3c0d3a28 - $d
    at ??:??
0x3fc93688 - async_io::driver::unparker::UNPARKER
    at ??:??
0x42014e84 - <&T as core::fmt::LowerHex>::fmt
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:2382
3fc9afe0: 0x00001800 0x0000000c 0x3c0d39a4 0x00000028 0x3fc9b030 0x3c0d3760 0x3c0db048 0x00000002
0x3c0d39a4 - $d
    at ??:??
0x3c0d3760 - $d
    at ??:??
0x3c0db048 - $d
    at ??:??
3fc9b000: 0x3fc9b010 0x00000002 0x00000000 0x00000000 0x3fc9afe8 0x420138e6 0x3fc9aff0 0x420138f6
0x420138e6 - <&T as core::fmt::Display>::fmt
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:2382
0x420138f6 - <&T as core::fmt::Debug>::fmt
    at /.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:2382
3fc9b020: 0x00000003 0x3fcbfa14 0x3fc9b030 0x420541ea 0x00000003 0x3fcbfa14 0x00000008 0x4204b060
0x420541ea - lwip_fcntl
    at /.espressif/esp-idf/v5.2.2/components/lwip/lwip/src/api/sockets.c:3936
0x4204b060 - fcntl
    at /.espressif/esp-idf/v5.2.2/components/newlib/syscalls.c:172
3fc9b040: 0x3fca0548 0x00000039 0x00000014 0x3fc9b068 0x3fc9fafe 0x3fca0458 0x00000004 0x00000001
3fc9b060: 0x00000002 0xffffffff 0x3fc9bcc8 0x00000039 0x3fc9b6d8 0x00000039 0x3fc9bcc8 0x4200c398
0x4200c398 - async_io::reactor::Reactor::insert_io
    at /.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-io-2.3.4/src/reactor.rs:123
3fc9b080: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0x3fca0050 0xa5a5a5a5
3fc9b0a0: 0x3fcbd1f4 0x00004e20 0xfb0000e0 0xa5a5a5a5 0x3fca13e8 0x01010101 0xa5a5a5a5 0xfefefeff
3fc9b0c0: 0x00000fff 0x80808080 0x3fc9fae8 0x3fc93838 0x80000002 0x077cb531 0x00000004 0x3fcbd0d8
0x3fc93838 - async_io::reactor::Reactor::get::REACTOR
    at ??:??
3fc9b0e0: 0x00000003 0x3fcb9780 0x00000000 0x00000000 0x00000001 0x3c0d1900 0x00000000 0x00000019
3fc9b100: 0x3c0d1b83 0x0000000e 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x3c0d1b83 - $d
    at ??:??
3fc9b120: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fc9b140: 0x00000000 0x00000000 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc9b160: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc9b180: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc9b1a0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc9b1c0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc9b1e0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc9b200: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc9b220: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc9b240: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fc9b260: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5

ELF file SHA256: 000000000

ivmarkov commented 2 months ago

You have to keep around the MountedEventfs thing returned from this call or else it would be immediately dropped and you achieve nothing.

Luni-4 commented 2 months ago

Yay, it works! Thanks a lot!

I had to update ESP IDF to v.5.3.1 to solve the ESP_ERROR_TIMEOUT issue on ESP32-C3 though. But now I'm not finding any more problems issuing cargo run many times in a row.

Unfortunately, I'm facing another problem with this example. When I run avahi-browse -a this is the output I get after some time:

+  device IPv4 service-name                                         Secure Web Site      local
-   device IPv4 service-name                                         Secure Web Site      local

It seems as if it shuts down itself after a while. Is this a wrong configuration on my side or is it a bug?

Luni-4 commented 2 months ago

@ivmarkov

I have pushed the final code here. I have added the mdns service responder example, but the issue pointed out in the message above remains.

ivmarkov commented 2 months ago

I have pushed the final code here. I have added the mdns service responder example, but the issue pointed out in the message above remains.

If you would like me to help with this issue, you have to do some basic checks yourself as well. For example:

Are you sure that the device does not lose power (if e.g. connected to a laptop that might into standby)?
Are you looking at the device logs? Could it be, that the device gets disconnected from wifi? Or are you seeing any other errors there?
Perhaps you can implement a simple loop on the device that runs in parallel with the mDNS responder, and which loop tries - every X seconds - to ping your gateway IP?

I hope you realize, that simply telling me "it seems as if it shuts down itself after a while" is not enough to even hypothesize what might be happening. :-)

Luni-4 commented 2 months ago

Yeah, you're right. I was erroneously supposing that my issue was a general and reproducible issue which might not have been specific to my environment, apologies for that.

A little of context. I have an ESP32-C3 and a laptop as devices. Both of them are connected through Wi-Fi to the same router. The ESP32-C3 is connected to the laptop through serial. At first, I issue the cargo run --release command in order to flash and run the code linked above, then, in another terminal, I issue the avahi-browse -a command from the laptop to verify if I can discover the device. Initially I can find the ESP32-C3 device and ping it, but after a while (nearly a minute), it occurs this in the avahi-browse log:

+  device IPv4 service-name                                         Secure Web Site      local
-   device IPv4 service-name                                         Secure Web Site      local

This is the log produced by the ESP32-C3

[2024-09-25T08:24:59Z INFO ] Serial port: '/dev/ttyACM0'
[2024-09-25T08:24:59Z INFO ] Connecting...
[2024-09-25T08:25:00Z INFO ] Using flash stub
Chip type:         esp32c3 (revision v0.4)
Crystal frequency: 40 MHz
Flash size:        4MB
Features:          WiFi, BLE
MAC address:       48:31:b7:3d:b6:84
App/part. size:    1,073,008/4,128,768 bytes, 25.99%
[2024-09-25T08:25:00Z INFO ] Segment at address '0x0' has not changed, skipping write
[2024-09-25T08:25:00Z INFO ] Segment at address '0x8000' has not changed, skipping write
[2024-09-25T08:25:00Z INFO ] Segment at address '0x10000' has not changed, skipping write
[2024-09-25T08:25:01Z INFO ] Flashing has completed!
Commands:
    CTRL+R    Reset chip
    CTRL+C    Exit

ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x15 (USB_UART_CHIP_RESET),boot:0xd (SPI_FAST_FLASH_BOOT)
Saved PC:0x40380576
0x40380576 - call_start_cpu0
    at /.espressif/esp-idf/v5.3.1/components/esp_system/port/cpu_start.c:773
SPIWP:0xee
mode:DIO, clock div:2
load:0x3fcd5820,len:0x1714
load:0x403cc710,len:0x968
load:0x403ce710,len:0x2f9c
entry 0x403cc710
I (19) boot: ESP-IDF v5.1.2-342-gbcf1645e44 2nd stage bootloader
I (20) boot: compile time Dec 12 2023 10:50:58
I (20) boot: chip revision: v0.4
I (24) boot.esp32c3: SPI Speed      : 40MHz
I (29) boot.esp32c3: SPI Mode       : DIO
I (33) boot.esp32c3: SPI Flash Size : 4MB
I (38) boot: Enabling RNG early entropy source...
I (44) boot: Partition Table:
I (47) boot: ## Label            Usage          Type ST Offset   Length
I (54) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (62) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (69) boot:  2 factory          factory app      00 00 00010000 003f0000
I (77) boot: End of partition table
I (81) esp_image: segment 0: paddr=00010020 vaddr=3c0d0020 size=2b174h (176500) map
I (129) esp_image: segment 1: paddr=0003b19c vaddr=3fc91600 size=02d80h ( 11648) load
I (132) esp_image: segment 2: paddr=0003df24 vaddr=40380000 size=020f4h (  8436) load
I (137) esp_image: segment 3: paddr=00040020 vaddr=42000020 size=c6adch (813788) map
I (323) esp_image: segment 4: paddr=00106b04 vaddr=403820f4 size=0f448h ( 62536) load
I (345) boot: Loaded app from partition at offset 0x10000
I (345) boot: Disabling RNG early entropy source...
I (357) cpu_start: Unicore app
I (365) cpu_start: Pro cpu start user code
I (365) cpu_start: cpu freq: 160000000 Hz
I (365) app_init: Application information:
I (368) app_init: Project name:     libespidf
I (373) app_init: App version:      fd4259c-dirty
I (379) app_init: Compile time:     Sep 25 2024 09:45:48
I (385) app_init: ELF file SHA256:  000000000...
I (390) app_init: ESP-IDF:          v5.3.1
I (395) efuse_init: Min chip rev:     v0.3
I (399) efuse_init: Max chip rev:     v1.99
I (404) efuse_init: Chip rev:         v0.4
I (409) heap_init: Initializing. RAM available for dynamic allocation:
I (416) heap_init: At 3FC989B0 len 00027650 (157 KiB): RAM
I (422) heap_init: At 3FCC0000 len 0001C710 (113 KiB): Retention RAM
I (429) heap_init: At 3FCDC710 len 00002950 (10 KiB): Retention RAM
I (436) heap_init: At 50000200 len 00001DE8 (7 KiB): RTCRAM
I (444) spi_flash: detected chip: generic
I (447) spi_flash: flash io: dio
I (452) sleep: Configure to isolate all GPIO pins in sleep state
I (458) sleep: Enable automatic switching of GPIO sleep configuration
I (465) main_task: Started on CPU0
I (465) main_task: Calling app_main()
I (475) pp: pp rom version: 9387209
I (485) net80211: net80211 rom version: 9387209
I (495) wifi:wifi driver task: 3fca358c, prio:23, stack:6656, core=0
I (495) wifi:wifi firmware version: ccaebfa
I (495) wifi:wifi certification version: v7.0
I (495) wifi:config NVS flash: enabled
I (495) wifi:config nano formating: disabled
I (505) wifi:Init data frame dynamic rx buffer num: 32
I (505) wifi:Init static rx mgmt buffer num: 5
I (515) wifi:Init management short buffer num: 32
I (515) wifi:Init dynamic tx buffer num: 32
I (515) wifi:Init static tx FG buffer num: 2
I (525) wifi:Init static rx buffer size: 1600
I (525) wifi:Init static rx buffer num: 10
I (535) wifi:Init dynamic rx buffer num: 32
I (535) wifi_init: rx ba win: 6
I (535) wifi_init: accept mbox: 6
I (545) wifi_init: tcpip mbox: 32
I (545) wifi_init: udp mbox: 6
I (555) wifi_init: tcp mbox: 6
I (555) wifi_init: tcp tx win: 5760
I (555) wifi_init: tcp rx win: 5760
I (565) wifi_init: tcp mss: 1440
I (565) wifi_init: WiFi IRAM OP enabled
I (575) wifi_init: WiFi RX IRAM OP enabled
W (585) wifi:OWE is enabled, but authmode threshold is 3 or password length is 20, making it impossible to connect to an AP with authmode OWE
I (595) phy_init: phy_version 1180,01f2a49,Jun  4 2024,16:34:25
W (635) phy_init: saving new calibration data because of checksum failure, mode(0)
I (705) wifi:mode : sta (48:31:b7:3d:b6:84)
I (705) wifi:enable tsf
I (715) foo_esp: Wifi started
I (3125) wifi:new:<11,0>, old:<1,0>, ap:<255,255>, sta:<11,0>, prof:11, snd_ch_cfg:0x0
I (3125) wifi:state: init -> auth (0xb0)
I (3145) wifi:state: auth -> assoc (0x0)
I (3155) wifi:state: assoc -> run (0x10)
I (3195) wifi:connected with MyThing, aid = 2, channel 11, BW20, bssid = hidden
I (3195) wifi:security: WPA2-PSK, phy: bgn, rssi: -75
I (3195) wifi:pm start, type: 1

I (3195) wifi:dp: 1, bi: 102400, li: 3, scale listen interval from 307200 us to 307200 us
I (3205) wifi:set rx beacon pti, rx_bcn_pti: 0, bcn_timeout: 25000, mt_pti: 0, mt_time: 10000
I (3215) foo_esp: Wifi connected
I (3225) wifi:<ba-add>idx:0 (ifx:0, 2c:3a:fd:cd:5b:54), tid:6, ssn:2, winSize:64
I (3235) wifi:AP's beacon interval = 102400 us, DTIM period = 1
I (4215) esp_netif_handlers: sta ip: 192.168.178.126, mask: 255.255.255.0, gw: 192.168.178.1
I (4215) foo_esp: Wifi netif up
I (4215) foo_esp: Wifi DHCP info: IpInfo { ip: 192.168.178.126, subnet: Subnet { gateway: 192.168.178.1, mask: Mask(24) }, dns: Some(192.168.178.1), secondary_dns: Some(0.0.0.0) }
I (4235) foo_esp: About to run an mDNS responder for our PC. It will be addressable using mypc.local, so try to `ping mypc.local`.
I (4255) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (15635) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.57]:5353
I (16665) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.57]:5353
I (18615) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.57]:5353
I (29055) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.1]:5353
I (29055) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.1]:5353
I (30695) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.57]:5353
I (46675) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.57]:5353
I (53015) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.57]:5353
I (56185) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.57]:5353
I (58955) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.57]:5353
I (62025) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.57]:5353
I (78725) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.57]:5353
I (89165) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.1]:5353
I (89175) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.1]:5353

I have also tried to connect the ESP32-C3 to a power supply far from my pc and see if I can discover the device, but the issue remains.

For what concerns your questions:

The laptop doesn't go into standby
I pasted the devices logs above. I opened the router gateway configuration from browser and ESP32-C3 is still connected to the network. To better verify that, I have also added an HTTP server to my offline code, and it works. I can push this addition to my repository if it can be of help. I cannot see any other errors around.
Actually, I had not thought at this solution, thanks! I'm going to later report the results

As a final test, I have also tried to replace

loop {
        // Sleep for one second and then continue the execution.
        std::thread::sleep(std::time::Duration::from_millis(1000));
    }

with

loop { }

but the issue persists the same.

Thanks a lot for your help! I hope I have provided a comprehensive explanation. I can add more information if necessary.

ivmarkov commented 1 month ago

Thanks for the detailed explanations. Looking at your logs, there does not seem to be any error output in the ESP device logs. Furthermore, it seems the device continues to reply on mDNS queries from both your gateway and other IPs (if you could confirm that the "replying to mDNS" blah blah log continues to happen when you trigger an avahi-browse command after a while).

What I can try to do (but tmr) is to try to run your example at my end, and see if it breaks on me.

As for:

As a final test, I have also tried to replace

loop {
        // Sleep for one second and then continue the execution.
        std::thread::sleep(std::time::Duration::from_millis(1000));
    }

with

loop { }

I'm not even sure from where this loop is coming. Is it in the edge-mdns example?

The thing is, the program would never exit the block_on call, unless an error happens. You are not hitting this loop in the first place, so to say.

Luni-4 commented 1 month ago

Thanks for the detailed explanations. Looking at your logs, there does not seem to be any error output in the ESP device logs. Furthermore, it seems the device continues to reply on mDNS queries from both your gateway and other IPs (if you could confirm that the "replying to mDNS" blah blah log continues to happen when you trigger an avahi-browse command after a while).

@ivmarkov

The device continues to reply to mDNS queries even after avahi-browse -a cannot discover ESP32-C3 anymore.

When I run ping mypc.local and we are in this state:

+  device IPv4 service-name                                         Secure Web Site      local

I get

PING mypc.local (192.168.178.126) 56(84) bytes of data.
64 bytes from my.router (192.168.178.126): icmp_seq=1 ttl=64 time=61.1 ms
64 bytes from my.router (192.168.178.126): icmp_seq=2 ttl=64 time=69.4 ms
64 bytes from my.router (192.168.178.126): icmp_seq=3 ttl=64 time=94.0 ms
64 bytes from my.router (192.168.178.126): icmp_seq=4 ttl=64 time=175 ms
64 bytes from my.router (192.168.178.126): icmp_seq=5 ttl=64 time=33.8 ms
^C
--- mypc.local ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 33.806/86.716/175.376/48.312 ms

So I can find the device and everything works perfectly.

After nearly 1 minute (it's not a precise time, it varies among tries), the outcome of avahi-browser -a becomes

-   device IPv4 service-name                                         Secure Web Site      local

and if I run ping mypc.local I get

ping: mypc.local: Name or service not known

The log still replies to that query from the ping command. Here's the log content:

I (271985) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.57]:5353
I (273015) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.57]:5353
I (275055) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.57]:5353

I'm not even sure from where this loop is coming. Is it in the edge-mdns example?

The thing is, the program would never exit the block_on call, unless an error happens. You are not hitting this loop in the first place, so to say.

This is an attempt to solve the issue trying another solution, but it's now a typo. I've removed it from the code and pushed on the repository, thank you for catching it! Now, the code should be the same as the edge-mdns example.

ivmarkov commented 1 month ago

It does work for only one minute, because initially, the mDNS responder is doing this:

I (4255) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353

After that it is not broadcasting anymore, because it is not supposed to broadcast anymore. The weird thing in your case is, that your avahi does not try to contact the mDNS responder on an IPv4 address, but only on ipv4- over-ipv6, which is very weird.

Anyway, I'll try to repro once I'm back.

Luni-4 commented 1 month ago

@ivmarkov

Sorry for the late reply, but I have been quite busy lately.

Well, this is my current avahi.conf

# This file is part of avahi.
#
# avahi is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as
# published by the Free Software Foundation; either version 2 of the
# License, or (at your option) any later version.
#
# avahi is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
# or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
# License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with avahi; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
# USA.

# See avahi-daemon.conf(5) for more information on this configuration
# file!

[server]
#host-name=foo
#domain-name=local
#browse-domains=0pointer.de, zeroconf.org
use-ipv4=yes
use-ipv6=yes
#allow-interfaces=eth0
#deny-interfaces=eth1
#check-response-ttl=no
#use-iff-running=no
#enable-dbus=yes
#disallow-other-stacks=no
#allow-point-to-point=no
#cache-entries-max=4096
#clients-max=4096
#objects-per-client-max=1024
#entries-per-entry-group-max=32
ratelimit-interval-usec=1000000
ratelimit-burst=1000

[wide-area]
enable-wide-area=yes

[publish]
#disable-publishing=no
#disable-user-service-publishing=no
#add-service-cookie=no
#publish-addresses=yes
publish-hinfo=no
publish-workstation=no
#publish-domain=yes
#publish-dns-servers=192.168.50.1, 192.168.50.2
#publish-resolv-conf-dns-servers=yes
#publish-aaaa-on-ipv4=yes
#publish-a-on-ipv6=no

[reflector]
#enable-reflector=no
#reflect-ipv=no
#reflect-filters=_airplay._tcp.local,_raop._tcp.local

[rlimits]
#rlimit-as=
#rlimit-core=0
#rlimit-data=8388608
#rlimit-fsize=0
#rlimit-nofile=768
#rlimit-stack=8388608
#rlimit-nproc=3

I have tried to disable ipv6 entirely, changing these options:

- use-ipv6=yes
+ use-ipv6=no

- #publish-aaaa-on-ipv4=yes
+ publish-aaaa-on-ipv4=no

- #publish-a-on-ipv6=no
+ publish-a-on-ipv6=no

And restarting avahi-daemon, but anything changed. The log and avahi-browse outputs remained the same of the previous message.

ivmarkov commented 1 month ago

The good news is, I can reproduce your problem now if I completely switch off ipv6 from the edge-mdns responder. Whether that's an Avahi configuration problem, or a responder issue - I need to research. Will look at it later today.

Luni-4 commented 1 month ago

This is great news! Reproducibility is always a good fact :laughing:

Thanks a lot!

ivmarkov commented 1 month ago

I added a fix on master where - regardless how we were contacted (on ipv4 or ipv6) we always broadcast on all available addresses where we have subscribed.

Just pull latest from master, use edge-mdns from master and try again.

Luni-4 commented 1 month ago

Thanks a lot! It is fixed now! I can ping mypc.local hostname from my laptop and the ESP32-C3 replies.

I've also performed further tests, though.

If I ping mpyc.local from Windows and macOS laptops, where both of them are connected to the same ESP32-C3 access point, everything works correctly.

When I ping the board from my Android smartphone, though, it cannot resolve the hostname. I can ping the IP directly instead. I'm using the connectbot app to run the ping command.

Here's the connectbot error:

ping mypc.local
ping: unknown host mypc.local

Here's the log where we cannot find the current smartphone IP, which is 192.168.178.115, but only the macOS and the gateway IPs:

I (4167) esp_netif_handlers: sta ip: 192.168.178.126, mask: 255.255.255.0, gw: 192.168.178.1
I (4167) foo_esp: Wifi netif up
I (4167) foo_esp: Wifi DHCP info: IpInfo { ip: 192.168.178.126, subnet: Subnet { gateway: 192.168.178.1, mask: Mask(24) }, dns: Some(192.168.178.1), secondary_dns: Some(0.0.0.0) }
I (4187) foo_esp: About to run an mDNS responder for our PC. It will be addressable using mypc.local, so try to `ping mypc.local`.
I (4207) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (15607) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.1]:5353
I (15607) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (46957) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.122]:5353
I (46957) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (47157) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.122]:5353
I (47157) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (47567) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.122]:5353
I (47567) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (47667) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.122]:5353
I (47667) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (47767) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.122]:5353
I (47767) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (47877) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.122]:5353
I (47877) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (48177) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.122]:5353
I (48177) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (75727) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.1]:5353
I (75727) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353

If I run ping 192.168.178.126 (the board) from 192.168.178.115 (my phone), always through connectbot, it works perfectly.

ivmarkov commented 1 month ago

Ok but... can you ping - from your phone - your WIndows and MacOS workstations on the .local domain?

ivmarkov commented 1 month ago

Can you run avahi-browse -a from your phone or better yet - avahi-resolve? Is your phone even configured to resolve addresses via mDNS lookup?

Luni-4 commented 1 month ago

Ok but... can you ping - from your phone - your WIndows and MacOS workstations on the .local domain?

Yep, my Android version supports mDNS resolver https://source.android.com/docs/core/ota/modular-system/dns-resolver#mdns-local-resolution

I tried to run a server on my laptop which implements the mdns-sd crate and I can access to the main server page from my phone using the .local domain.

Moreover, if I run Service Browser I can find the service

photo_2024-10-09_19-05-06

and its properties

photo_2024-10-09_19-03-20

Here's the log now that the phone (192.168.178.115) can be discovered

I (4157) esp_netif_handlers: sta ip: 192.168.178.126, mask: 255.255.255.0, gw: 192.168.178.1
I (4157) foo_esp: Wifi netif up
I (4157) foo_esp: Wifi DHCP info: IpInfo { ip: 192.168.178.126, subnet: Subnet { gateway: 192.168.178.1, mask: Mask(24) }, dns: Some(192.168.178.1), secondary_dns: Some(0.0.0.0) }
I (4177) foo_esp: About to run an mDNS responder for our PC. It will be addressable using mypc.local, so try to `ping mypc.local`.
I (4197) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (4437) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.57]:5353
I (4437) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (5457) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.57]:5353
I (5457) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (7507) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.57]:5353
I (7507) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (7917) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.115]:5353
I (7917) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (8117) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.115]:5353
I (8117) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (8327) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.1]:5353
I (8327) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (8337) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.1]:5353
I (8337) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (8437) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.115]:5353
I (8437) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (8627) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.115]:5353
I (8637) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (8837) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.115]:5353
I (8837) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (11497) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.57]:5353
I (11497) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (11907) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.115]:5353
I (11907) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (19487) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.57]:5353
I (19487) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (28087) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.115]:5353
I (28087) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (28297) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.115]:5353
I (28297) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (28597) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.115]:5353
I (28597) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (28807) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.115]:5353
I (28807) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (35457) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.57]:5353
I (35467) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (42937) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.115]:5353
I (42937) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (43147) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.115]:5353
I (43147) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (43447) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.115]:5353
I (43447) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (43657) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.115]:5353
I (43657) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (46517) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.115]:5353
I (46527) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (47547) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.115]:5353
I (47547) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (50517) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.115]:5353
I (50517) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (53387) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.57]:5353
I (53387) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (67517) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.57]:5353
I (67517) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (68437) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.1]:5353
I (68437) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (68457) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.1]:5353
I (68457) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353
I (68467) edge_mdns::io: Replying to mDNS query from [::ffff:192.168.178.1]:5353
I (68467) edge_mdns::io: Broadcasting mDNS entry to 224.0.0.251:5353

ivmarkov commented 1 month ago

But all I'm asking is if you can ping your desktop from the phone by using its .local suffixed name

ivmarkov commented 1 month ago

I really do not understand what you are trying to do. :)

You say:

"I can't ping (on the .local domain) the c3 from my phone"
Then I'm asking you to do exactly the same with your workstations - try to ping your workstations from your phone (and it SHOULD work because they run mDNS or else they themselves would not be able to ping the c3!; so if pinging your workstations from your phone ALSO does not work, it means that whatever mDNS your phone supports, it is not really integrated on the shell/OS/libc level)

... but then you are doing something completely different, which is to install an mdns-sd responder on your workstations, and a 3rd party mDNS browser on your phone? Not sure what that proves?

Also, the c3 does not "discover" your phone. It is your phone - which - because you installed this 3rd party "Service Browser" mDNS query-er - now discovers the c3. Not the other way around. And by the way the fact that the c3 is discovered by your phone means that you really should do this ping test with your workstations from the SSH console of your phone, as it (your phone that is) might just be broken on the SSH/command-line level w.r.t. mDNS-based hostname resolution.

ivmarkov commented 1 month ago

@Luni-4 Argh OK, I should have read this link as to what your Android phone actually implements. They don't have an "mDNS responder", not even an "mDNS queryer" but implement the simplest of all hacks which is called a "one-shot query".

We don't (yet) support in edge-mdns replying to those types of queries. It might not be too difficult to add support for this.

But in any case, let me know what the outcome of trying to ping your workstations is as well.