Ethernet event deserialization panic

[torkleyy]

Not quite sure how that can happen, using EspSystemEventLoop::subscribe_async::<EthEvent>(..), I was able to trigger this panic:

thread '<unnamed>' panicked at ~/.cargo/git/checkouts/esp-idf-svc-1132d30333045bb2/a3aefb7/src/eth.rs:1059:13:
Unknown event ID: 4

Using ESP-IDF 5.1.3

It's not a valid discriminant according to the docs, but maybe it's a good idea to add an Unknown variant?

[Vollbrecht]

hmm sounds like an of-by-one error. Maybe there is some bug lurking somewhere. Just downgrading it to a Unknown variant is i think not a good idea there as it is really unexpected here.

If it is some sort of a of-by-one, can this be triggerd when you force a ETHERNET_EVENT_DISCONNECTED externally?

[torkleyy]

Not quite sure how to trigger it, but I've encountered a similar bug:

let _ip_events = sysloop
  .subscribe_async::<IpEvent>()
  .unwrap();

I (100457) wifi:state: init -> auth (b0)
thread '<unnamed>' panicked at /Users/thomas/.cargo/git/checkouts/esp-idf-svc-1132d30333045bb2/b84572d/src/netif.rs:738:13:
Unknown event ID: 40
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
I (100467) wifi:state: auth -> assoc (0)
abort() was called at PC 0x4018d802 on core 0

TRACE 40083584 (40083596) panic_abort
TRACE 4008b240 (4008b245) esp_system_abort
TRACE 400925c0 (4009263e) abort
TRACE 4018d7fc (4018d802) panic_abort::__rust_start_panic::abort
TRACE 4018d7f0 (4018d7f6) __rust_start_panic
TRACE 401a4830 (401a4836) rust_panic
TRACE 401a5034 (401a52d9) std::panicking::rust_panic_with_hook
TRACE 401a4fe8 (401a5014) std::panicking::begin_panic_handler::{{closure}}
TRACE 401a4fdc (401a4fe4) std::sys_common::backtrace::__rust_end_short_backtrace
TRACE 401a56f8 (401a5717) rust_begin_unwind
TRACE 4017c754 (4017c770) core::panicking::panic_fmt
TRACE 40187c98 (40187cfc) <esp_idf_svc::netif::IpEvent as esp_idf_svc::eventloop::EspEventDeserializer>::deserialize

This gets triggered whenever I try to use WPS.

[torkleyy]

It's as if there wasn't proper filtering on the event base types, because that event ID apparently corresponds to "WIFI_EVENT_HOME_CHANNEL_CHANGE".

[Rantanen]

I've been confused by some weird behavior, where my custom event deserializer gets invoked for WIFI_EVENTs as well.

https://github.com/esp-rs/esp-idf-svc/blob/35e59fac0f16f12be8273bb97a628bf1b302bbd1/src/eventloop.rs#L567-L587

The subscribe_async seems to be setting up the actual event subscription using the generic EspEvent. Shouldn't it be using D instead? This would explain why arbitrary events seem to be coming through it.

I also had a panic on unknown event ID 22 at one point, which would be explained by the async subscription mixing Wifi and IP events and trying to use each other's deserializers.