• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 202 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

CC2538: Zigbee Coordinator and Multiple Devices, Link Keys on device set to zero.

CC2538: Zigbee Coordinator and Multiple Devices, Link Keys on device set to zero.

Mathew Heard
Intellectual 711 points
Part Number: CC2538

We hit this same issue and believe it occurs if a ZED or ZR asks the ZC to leave the network. The ZC goes on to delete it's network security keys (0's them - which in itself is probably a bug), panid and other network information and then do a soft reset. I our case we believe a COTS sensor we recently started experimenting with sends the erroneous packets.

Proposed fix in ZDApp.c:

@ -3127,6 +3127,13 @@ void ZDO_LeaveCnf( NLME_LeaveCnf_t* cnf )
  if ( osal_ExtAddrEqual( cnf->extAddr,
                          NLME_GetExtAddr() ) == TRUE )
  {
    // MH: Prevent other routers and EDs from destroying the network
    // by asking the ZC to leave.
    // Without this check the ZC will clear network keys, panid etc
    if(ZG_DEVICE_COORDINATOR_TYPE){
        return;
    }

    // Pass the leave confirm to higher layer if callback registered
    if ( ( zdoCBFunc[ZDO_LEAVE_CNF_CBID] == NULL ) ||
         ( (*zdoCBFunc[ZDO_LEAVE_CNF_CBID])( cnf ) == NULL ) )

We still need to confirm this fix fully.

  • 0
    TI__Guru**** 202186 points

    Hey Mathew,

    Thank you for alerting us to this issue and providing your fix, it appears to be a valid solution but please let me know if it resolves the issue after further testing.  Per Zigbee 3.0 Specification the ZC device should ignore all Leave Requests from any ZR/ZEDs in the network.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 711 points

    Thank you for your confirmation Ryan. We have the fix deployed over the development fleet and are watching.

    For anyone else who finds this and wonders if this issue affects them. How we determined the cause was by looking at the NVRAM.

    "133": {
"idName": "ZCD_NV_LEAVE_CTRL",
"value": "01"
},

    This indicates that ZC has been asked to leave the network. The rest of the network related parameters are 0xff* or 0x00*.

  • 0
    TI__Guru**** 202186 points

    Hi Mathew,

    Would you be able to provide the changes to the ZC code/settings and replication steps, as well as a sniffer log which captures the Leave Request that causes this behavior?  I attempted to reproduce it but was unable to break in ZDO_LeaveCnf or observe the ZC behavior described after a ZR Leave or Management Leave Request.

    Regards,
    Ryan