CC2531: Association response failed on Z-Stack Home 1.2.2a.44539 ZNP coordinator

The association table size is defined using NWK_MAX_DEVICE_LIST and can be increased as such.  AssocReset removes all devices from the association table and resets it, this would disrupt communication with any devices which have previously joined the network and would cause confusion as the ZC then has to tell devices it no longer recognizes to leave the network.

You may also consider using AssocRemove on devices which have not recently checked in or are no longer responding.

Regards,
Ryan

Thanks for the response!

The user now attempted the same but with one router still powered on.

The device associates correctly but right after this the coordinator sends "Remove device" commands.

Why does the coordinator do this?

Sniff:

Details of update/remove device (does the unsecured join have something to do with this??)

Can you attach your sniffer log instead of screenshot?

Has this ZED previously joined the network and would you be able to debug the ZC to determine the exact reason the Remove Device command is sent?  Some similar E2E threads imply the issue could be due to previous association or the ZC not being open for joining.

Regards,
Ryan

Sniff can be found below and the key here: https://pkg.blackdot.be/cores/zigbee/.key     

src_route_one_router_leaev.zip

I unfortunately don't see any Leave commands in the provided sniffer log, although the packets are decrypted and the same short addresses are communicating on the network.

Regards,
Ryan

The "Remove Device" request from the coordinator can be found on No. 71, the Leave response from the device on No. 75.

Understood, thank you for clarifying.  I had to add the key as you recommended.  Nothing appears out of the ordinary, the Update Device command for a Standard Device Unsecured Join should be responded to with a Tunnel: Transport Key from the ZC but the Remove Device occurs instead.  My previous questions remain: Has this ZED previously joined the network and would you be able to debug the ZC to determine the exact reason the Remove Device command is sent?  Also does this behavior occur if a Z-Stack 3.0 ZNP is used instead?

Regards,
Ryan

This is a sniff of the first attempt when the device tried to join the network: https://pkg.blackdot.be/cores/zigbee/src_route_full_network_leave.pcapng. Joining happens around no. 72, the remove device at no. 101. After that the user turned off all routers expect one (that the first sniff I've send).

I've investigated the code and I'm pretty sure the remove device comes from (line 1145).

This would mean that ZDSecMgrDeviceValidate() returns != SUCCESS, which only happens if zgSecurePermitJoin == FALSE OR ZDSecMgrPermitJoiningEnabled == FALSE.

As zgSecurePermitJoin is never set to FALSE, I cannot see how it could fail there so it's more likely that it fails at ZDSecMgrPermitJoiningEnabled. But as you can see in the sniff permit joining is enabled for sure. The only other point this could be set to FALSE is due to the permit join timer triggering too early. To avoid this we are now going to try permit join with 0xFF so that the timer is not activated.

Note that after the user rebooted the CC2531 the device immediately joined.

Thank you for providing an update and great debugging work, this indeed appears to be an issue with the permit join timer so please keep me updated.  This E2E post appears to show similar behavior: https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/470887 

Regards,
Ryan

Hi,Ryan,

     It seems like some bugs in Z-Stack 3.0.x(include 3.0.2 two years ago release version) of old,that devices join Trust Center(ZC) failure frequently through indirect manner,of course,direct join Trust Center successful everytimes.

    We hope to TI software team invest the times diagnostic and take a solutions.

BTW,I have mentioned previous topic https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/p/897857/3323659#3323659

Simple JPG capture and Ubiqua capture attachment archive files:

indirect join zigbee 3.0 failure.cubx.7z

Hi miffy,

We are aware of the issue previously raised, unfortunately due to COVID-19 we are limited on resources with which to further investigate the issue.  Furthermore, primary development efforts are given to the SIMPLELINK-CC13X2-26X2-SDK instead of CC253X products.  I would encourage you to further consider evaluating the CC2652R /P or CC1352R /P for your ZC/ZNP requirements.

Regards,
Ryan

Related post: https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/918364

After adding some debug code (to see where things fail) the issue magically disappeared, could this issue somehow be a race condition (as the added debug code increases the execution time)?

Hi Koen,

Thanks for providing the information from your additional debug efforts.  What you've described does sound like a race condition.  Would you be able to debug further and determine where/how long a delay is necessary in ZDSecMgrDeviceJoin?  Has it ever been determined what the fail status is when ZDSecMgrDeviceRemove is called (as ZDSecMgrSendNwkKey could also fail)?

Regards,
Ryan