Thomas Schaller
Thomas Schaller
@ivmarkov rebased.
Ah! Thanks for your solution. Yeah, it would be really handy to have these type-level integers.
I don't know why, but the functions were changed so I assumed that somebody needed that functionality...
Not quite sure how to trigger it, but I've encountered a similar bug: ```rust let _ip_events = sysloop .subscribe_async::() .unwrap(); ``` ``` I (100457) wifi:state: init -> auth (b0) thread...
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".
I cannot currently check anything, but I'm sure my main task priority is the default one.
This is the stack trace when the watchdog interrupts the thread: ``` 0x3FFC0160 - port_IntStack at ??:?? 0x40083CDD - _xt_lowint1 at S:\eval-esp-rust\target\xtensa-esp32-espidf\debug\build\esp-idf-sys-fcec888798d06ca6\out\build\C:/Users/me/.espressif/esp-idf/v5.1.1/components/freertos/FreeRTOS-Kernel/portable/xtensa\xtensa_vectors.S:1236 0x3FFC0190 - port_IntStack at ??:?? 0x4021A6AB - esp_vfs_safe_fd_isset...
Ha! I see. Thanks a bunch for all the information!
I haven't tested this much as we follow a different approach atm. In any case there is no way to reenable DHCP with just this method added.
@ivmarkov Yes, that's what happened to me. > Because we don't call core::mem::forget - we are simply destructuring the inner socket, so I'm not sure why you think we are...