Persistent Address Conflict Issues

RE: Persistent Address Conflict Issues

jemalkorra — Thu, 30 May 2024 11:14:32 GMT

Hello Marte,

We have performed some test with the encryption enabled. And it seems the problem has been solved. So we will continue working with encryprion active. If we have any news about this issue we will notify you.

Thanks for your support,

Julen

RE: Persistent Address Conflict Issues

Marte Myrvold — Mon, 22 Apr 2024 08:48:55 GMT

Hi Julen,

Based on this, it seems like the noise is not a factor. Please let me know if you find anything with your tests with security.
I will keep looking through your logs to see if I can find anything more.

Best regards,
Marte

RE: Persistent Address Conflict Issues

jemalkorra — Fri, 19 Apr 2024 14:04:24 GMT

Hello,

I have done a first try with encryption enabled. See the attached log. I will try to do more tests adding, removing, turnning on and off the devices. To see if I can replicate the addr conflict problem.

Thank you for your support,

Julendevzone.nordicsemi.com/.../log_5F00_encrypted.pcapng

RE: Persistent Address Conflict Issues

jemalkorra — Fri, 19 Apr 2024 11:59:03 GMT

Hello,

I've conducted some tests at home, where the environment is less noisy compared to the lab. In this setup, the coordinator is from Digi, and the network is unencrypted. We've decided to maintain this configuration for legacy reasons.

Next week, I plan to run the same tests but with an encrypted network, so we can see difference.

Thank you,

Julen

devzone.nordicsemi.com/.../log_5F00_addr_5F00_conflict_5F00_no_5F00_encrypted.pcapng

RE: Persistent Address Conflict Issues

Marte Myrvold — Thu, 18 Apr 2024 08:34:52 GMT

Hi Julen,

[quote user="jemalkorra"]If you'd like, I can share more logs with you for further analysis.[/quote]

If you could do that, then it would be great 🙂.

[quote user="jemalkorra"]However, considering that the commissioning process deviates from the specifications, do you foresee any potential challenges or complications with this setup?[/quote]

In theory, Zigbee and Xbee should be compatible, but there could be some issues, so it would be good to narrow down whether this only happens with Xbee.

Is it possible to enable security on your Xbee coordinator? Based on the Xbee documentation, this seems to be possible by setting the Encryption Enable (EE) parameter to 1. I am not sure this will solve the issue, but it is worth trying.

[quote user="jemalkorra"]Our testing environment in the lab is quite noisy. In addition to Wi-Fi signals, there are multiple Zigbee networks operational. [/quote]

Are you able to test in a less noisy environment to ensure that the issue is not related to noise?

Best regards,
Marte

RE: Persistent Address Conflict Issues

jemalkorra — Wed, 17 Apr 2024 10:36:12 GMT

Hello Marte,

I'm unable to confirm if the address conflict issue occurred solely with Xbee. However, based on the logs I have saved in the past, it seems to be associated with Xbee. Although this issue has been recurring, it doesn't happen frequently. I plan to conduct some tests with the Nordic coordinator to see if I can replicate the error. If you'd like, I can share more logs with you for further analysis.

Our ultimate objective is to utilize Xbee as the coordinator and Nordic routers within the network. However, considering that the commissioning process deviates from the specifications, do you foresee any potential challenges or complications with this setup?

Our testing environment in the lab is quite noisy. In addition to Wi-Fi signals, there are multiple Zigbee networks operational.

Best regards,

Julen

RE: Persistent Address Conflict Issues

Marte Myrvold — Wed, 17 Apr 2024 08:50:32 GMT

Hi,

From the sniffer log, it looks like the coordinator is an XBee coordinator from MaxStream. Do you see these issues if you use a Zigbee coordinator, e.g., our Zigbee network coordinator or Zigbee shell samples, or only when using XBee?
I am asking because I am seeing some strange behavior in the logs. The commissioning process does not follow the Zigbee specification, and there seem to be many issues with address conflicts for multiple devices.

[quote user="jemalkorra"]I'm curious about why IEEE addresses can sometimes be omitted, why is this happening? Could you please point out instances where you've observed this? [/quote]

I might have been mistaken, as it seems the packets where the IEEE addresses are omitted are retransmitted, i.e., forwarded from another device. In that case, this is to be expected.

I also noticed that the incoming and outgoing costs in the Link Status packets are high for some of the devices. Is the test environment noisy, or are the devices far apart such that they could have issues communicating? I see that signal 24 is generated on the child device, which indicates that it cannot reach any other routers or the coordinator.

Best regards,
Marte

RE: Persistent Address Conflict Issues

jemalkorra — Tue, 16 Apr 2024 13:09:02 GMT

Hello Marte,

I appreciate your assistance. During this particular test, I was using SDK version 2.5.1. However, last week, I updated to version 2.6.0. If I encounter the same issue in the new version, I'll be sure to send you the logs for further analysis.

I'm curious about why IEEE addresses can sometimes be omitted, why is this happening? Could you please point out instances where you've observed this?

In our debugging process, we've implemented additional traces and logic. When a router fails to join a coordinator after multiple attempts, we first erase Zigbee persistent data. If the issue persists, we then resort to restarting the device and clearing persistent memory each time. We do this because we see some behavior that can be problematic for us, for example we modify the network coordiantor and the router struggle to join the network.

I have some logs that might help clarify the situation. This are logs from the same day but I can not link them with the wireshark log traces. I hope they can be helpfull for you.

devzone.nordicsemi.com/.../log_5F00_addr_5F00_conflict_5F00_child.txt devzone.nordicsemi.com/.../log_5F00_addr_5F00_conflict_5F00_parent.txt

Thank you again for your support.

Best regards,

RE: Persistent Address Conflict Issues

Marte Myrvold — Tue, 16 Apr 2024 12:32:59 GMT

Hi,

Which version of the SDK are you using?

The sniffer log shows that the device's address has changed as a result of the address conflict, from 0x34e2 to 0x4d13 in packet number 34. However, the address conflict again starts with the new address.
I cannot see any other devices with the same network address as this device in the sniffer log, but I do see some packets from the device where the IEEE address is omitted. It seems like this is causing the issue, making the other devices believe that the packets from 0x4d13 without the IEEE address are sent from a different device than the ones including the IEEE address (f4:ce:36:45:86:1c:55:97).

Do you have application logs from the devices as well?

Best regards,
Marte