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.

CC2530: temporary communication lapse on coordinator restart

Part Number: CC2530

We have a zigbee network with one router and a coordinator.
It's a znp coordinator. The communication between the router and the coordinator works fine until coordinator is restarted.
we are using zstack 302.

Coordinator does not receive messages from the router.

For sample here in wireshark sniffer logs we restarted the coordinator after packet no. 94.

Read attribute was successful before this point, but after restart of coordinator read attribute response was not received for first few attempts?

Why is this?

Some times coordinator wont receive reports from the router for upto 10-15 minutes after restart of coordinator.  

PFA Sniffer logs 

Key used is "{0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F}"

packets_not_delivered_on_coordinator_restart.zip

  • Hi,

    The reason why router is not responding (besides MAC ack) to coordinator is that the frame counter in the NWK security header on the coordinator is lower after it resets.
    (In packet 93, this frame counter is 1288, and in packet 96, the frame counter is 0).

    For security reasons (e.g. replay attacks), the receiving device will process the frame only if the NWK security frame counter is greater than the frame counter of the last known valid frame received from that device (in this case from coordinator).

    Have you made any modifications to the ZNP example from the default project?

    Regards,
    Toby

  • Hi Toby Pan,


    We are using ZNP coordinator, changes include default-Key and OTA_DONGLE_INTEGRATION only.

    On Regenerating the scenario several times, it was noticed that the frame counter in the NWK security header was reset to 6256 on every reset.

    How can we fix this?

    Thanks

  • The NWK frame counter would be incremented once per reset in function ZDApp_RestoreNwkSecMaterial(.) .
    Can you debug to see if the NV write is successful here?

    Also, can you try with out-of-box ZNP, then incrementally add your changes to see which one causes this behavior?