Device is using the wrong byte order for its IEEE 802.15.4 MAC address (TZ-232)

[nomis]

The MAC addresses reported for my ESP32-C6 device are:

esp_read_mac ESP_MAC_BASE 40:4c:ca:43:0b:d0
esp_read_mac ESP_MAC_IEEE802154 40:4c:ca:ff:fe:43:0b:d0

The MAC address on the network of the Zigbee end device is d0:0b:43:fe:ff:ca:4c:40 which has been reversed.

All of the other devices on my network have MAC addresses with the OUI at the start, and some of them are using *:ff:fe:* addresses which is reversed as *:fe:ff:* on the ESP32, so it looks like the wrong byte order is being used when configuring the IEEE 802.15.4 peripheral.

[xieqinan]

The discrepancy might stem from a big/little endian issue. Would you be able to verify the printed order between esp_read_mac and the MAC address on the network of the Zigbee end device?

[nomis]

40:4c:ca is an Espressif OUI. I'm not printing it in the wrong order and it matches the USB serial number:

[1253105.500446] usb 5-2.5.4: Product: USB JTAG/serial debug unit
[1253105.500447] usb 5-2.5.4: Manufacturer: Espressif
[1253105.500447] usb 5-2.5.4: SerialNumber: 40:4C:CA:43:0B:D0

The MAC address (as reported by Home Assistant) is wrong on the network. It is reversed compared to all the other devices and the OUI is at the end when it should be at the start.

I'm not sure what more you need here.

[xieqinan]

Understood. The IEEE address presented in the example console appears to be reversed compared to the actual address. Thanks.

[nomis]

Setting the MAC address results in the right order but I can't get the device to finish joining the network like that. I just keep getting ESP_ZB_NWK_LEAVE_TYPE_RESET followed by a failure status for ESP_ZB_BDB_SIGNAL_STEERING.

I've tried different channel masks but nothing works:

esp_zb_mfg_tool.py -c 0x07FFF800 -m 404CCAFFFE430BD0
esp_zb_mfg_tool.py -c 0x7FFFFFFF -m 404CCAFFFE430BD0

[nomis]

If the address hasn't been set using the zb_fct partition then it'll be all zeros on startup (ESP_ZB_ZDO_SIGNAL_SKIP_STARTUP), and it can be fixed by setting it before the built-in address is automatically used with the wrong byte order:

esp_zb_ieee_addr_t long_address;
esp_zb_get_long_address(long_address);

if (all_zeros(long_address)) {
    esp_read_mac(long_address, ESP_MAC_IEEE802154);
    std::reverse(std::begin(long_address), std::end(long_address));
    esp_zb_set_long_address(long_address);
}

[xieqinan]

Hello,

The MAC address on the network of the Zigbee end device is d0:0b:43:fe:ff:ca:4c:40 which has been reversed.

Could you tell me how to get the reversed d0:0b:43:fe:ff:ca:4c:40 address ?

[nomis]

Could you tell me how to get the reversed d0:0b:43:fe:ff:ca:4c:40 address ?

The co-ordinator shows the IEEE address of all the devices. For ESP32-C6 end devices it is reversed.

If I use an ESP32-C6 as a co-ordinator, its default Extended PAN ID (based on the IEEE address) is also reversed.

[xieqinan]

Yes, it does, it's inverse. I has fixed it and will update to github in this week.

and it can be fixed by setting it before the built-in address is automatically used with the wrong byte order:

The aforementioned issue is merely related to incorrect printing. However, why does it lead to the unexpected behavior? Could you provide a comprehensive description of the application scenario where using the correct order of IEEE addresses results in a failure to join the network?

Let's work together to address and resolve this matter.

[nomis]

Yes, it does, it's inverse. I has fixed it and will update to github in this week.

This is now fixed.

Could you provide a comprehensive description of the application scenario where using the correct order of IEEE addresses results in a failure to join the network?

I've created #82 for this.