esp: fix extended-address byte order for the hardware RX filter

[snabb]

Problem

On ESP32 with esp-radio, OpenThread never attaches to a Thread network. The node transmits Parent Requests and receives multicast traffic fine, but receives zero unicast frames — so it never gets a Parent Response, and MLE attach times out. Because TX and multicast RX work, it looks like a higher-layer problem.

Root cause

An extended-address byte-order mismatch in the hardware RX address filter:

• otPlatRadioSetExtendedAddress delivers the address in little-endian order (per openthread/platform/radio.h), and esp-radio programs its hardware filter with ext_addr.to_le_bytes() (fix: use little-endian byte order for IEEE 802.15.4 extended address esp-hal#5314, "use little-endian byte order for IEEE 802.15.4 extended address").
• But the platform callback decoded it with from_be_bytes (and the MacRadio frame parser mirrored that), so Config.ext_addr / dst_ext_addr were byte-reversed vs the on-air little-endian address.

So the filter is loaded byte-reversed; the radio drops every unicast frame addressed to the node. (This was correct before esp-rs/esp-hal#5314, when esp-radio used big-endian; that change flipped esp-radio to the spec-correct little-endian and the decode side wasn't updated to match.)

Fix

Decode the extended address little-endian at the two sites that build the u64 from the byte slice — platform.rs (otPlatRadioSetExtendedAddress) and radio.rs (the MacRadio frame parser). This makes Config.ext_addr and the parsed dst_ext_addr match the on-air little-endian order and esp-radio's to_le_bytes hardware-filter programming.

Validation

esp32-c6, Matter over Thread: with the fix the device attaches to Thread and operates (commission, attribute reads, reboot auto-recovery); without it, attach never completes. (No nRF hardware here to exercise the MacRadio software-filter leg directly, but radio.rs is the matching counterpart so the two stay in agreement.)

🤖 Generated with Claude Code

[ivmarkov]

Thanks for figuring out the root cause!

As discussed, instead of this change, please replace from_be_bytes with from_le_bytes at these two places (which are the buggy ones):

• openthread/openthread/src/platform.rs

  Line 141 in b38ad1d

  OtContext::callback(instance).plat_radio_set_extended_address(u64::from_be_bytes(unwrap!(

• openthread/openthread/src/radio.rs

  Line 1267 in b38ad1d

  self.dst_ext_addr = u64::from_be_bytes(unwrap!(psdu[5..13].try_into()));

[snabb]

Done — replaced from_be_bytes with from_le_bytes at both platform.rs (otPlatRadioSetExtendedAddress) and radio.rs (the MacRadio ext-addr parse), and reverted the esp.rs swap.

Re-tested on an esp32-c6 (Matter over Thread) with this exact from_le_bytes version: Thread attaches, the device operates (HA reads attributes), and it auto-recovers across reboots. The esp path is byte-identical to the swap I'd validated earlier; the radio.rs change keeps the nRF MacRadio software-filter parser consistent (no nRF hardware here to exercise that leg directly).