What's the state of the library?

[chrneumann]

Hey,

I'm using this library to receive UDP packets via multicast (ff03::1) on an ESP32H2 board. Sometimes it works as expected, sometimes it doesn't receive any packets at all. It's like its loosing the connection to the mesh and gets back again after some minutes. If I reboot, it normally gets back working in a short amount of time. My implementation is based mostly on the UDP example. Did you notice similar problems? Not sure where to start debugging, but as the library does not seem to be released yet, I thought I'd asked first if these are known problems and I should wait until the library gets released?

It's also the first time that I use Thread, but I would expect that there should not be any bigger radio level problems if sender and receiver (both ESP32H2, sender is using OT-CLI, also as suggested in the README/example) are next to each other.

Best
Christian

[chrneumann]

Might as well be a problem on the sender side. I now have two almost identical receivers (same board, same firmware with different settings) and both won't receive packages at the same time.

Update: Sometimes, only one of the receivers doesn't receive packages. So it often fails (and works fine) for both at the same time, but sometimes only for one.

[ivmarkov]

I have no idea what could be causing this as I have not played with OpenThread multicasting yet.

To be able to isolate the problem, I suggest you bypass for a moment the Rust openthread library and flash on both boards the OT-CLI example. If it then does not work with OT-CLI either, then we at least know this is not specific to the Rust openthread bindings.

[MattsGitCode]

I'm late to the party here, and you may have already solved this, but I faced a similar issue recently and thought I'd share my experience.

I had two ESP32-C6 boards, one acting as a FTD with SRP and DNS servers, and another acting as an MTD running DNS lookups. I found that when I ran larger DNS queries (querying by service name) it would fail to get a response, whereas smaller queries (querying by hostname) were fine.

The issue seemed to be timing issues on the FTD as it was recombining the received frames of the DNS request. The request was large enough to be split across two frames, and the FTD reliably received the first one but timed out waiting for the second because the device was too busy doing other things and the radio dropped the second frame.

I did a couple of things to try to solve this:

1. Reduced the log levels (DEFMT_LOG="info,openthread=warn" in my FTD's config.toml and .define("OT_LOG_LEVEL", "CRIT") in openthread-sys/gen/builder.rs)
2. Moved the OpenThread tasks into a higher priority executor, as per esp-hal's multiprio example. The OpenThread wrapper is not Send, due to its use of Arc, so everything OpenThready stays in the higher priority executor, and my app logic communicates with it via a Channel (from embassy-sync)

This is much more reliable for me now, although it does occasionally still fail to get a response. To diagnose this further I'd need to increase the log level again, but that in itself will cause problems.

Disclaimer: I used Google's Gemini to help me parse the incomprehensibly large mass of logs I got when I turned on trace logs (and OT_LOG_LEVEL=DEBG). This is what led me to the conclusions above.