• State TI Thinks Resolved
  • Locked Locked
  • Replies 23 replies
  • Answers 4 answers
  • Subscribers 57 subscribers
  • Views 2329 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2538: Z-Stack 3.0.2 BDB reset issue.

Alvin Chen
Expert 3925 points

Part Number: CC2538
Other Parts Discussed in Thread: Z-STACK

Hi Team,

Customer use use bdb_resetLocalAction() to reset coordinator. The ZED will try to rejoin its preview network by bdb_ZedAttemptRecoverNwk(), but ZED can still send data request to new Coordinator(not permit join ), new Coordinator will send leave command to the End Device. Customer will provide more detail in a later.

Any information would be greatly appreciated.

  • 0
    TI__Mastermind 35070 points

    Hi Alvin,

    The described behavior of the ZED seems possible, since the coordinator always has nwk address of 0x0000 (even after resetting).
    Although the ZED sends a data request to the ZC, the ZC was reset, so it has no record of that ZED. In that case, I would expect that the ZC sends a leave request as you described.

    Let's wait for further details.
    A sniffer log of the process would help greatly.


    Regards,
    Toby

  • 0 in reply to Toby
    Guru 735695 points
    If ZC is factory reset, the PANID should be different after ZC forms new network. I suppose ZED should not do data requests to ZC with different PANID, right?
  • 0 in reply to YiKai Chen
    TI__Mastermind 35070 points
    YK,

    That's a good point.

    However, I'm not sure if they're setting up their network with a pre-defined PANID. The logs will give us more clues on what could be happening.


    Regards,
    Toby
  • 0 in reply to Toby
    TI__Expert 3925 points

    Hi Toby, YK

    Thanks for your reply. If setting up their network with a pre-defined PANID, the new coordinator and zed will have same PANID , so this described behavior of the ZED seems possible.

     If customer provide sniffer log, i will update this post. 

  • 0 in reply to Toby
    Guru 735695 points
    @Toby Pan, according to original poster of this issue on China E2E, he claim the PANIDs are different before and after ZC does factory reset. Anyway, let's check his sniffer log if he posts it.
  • 0 in reply to Alvin Chen
    Intellectual 780 points
    The first nwk key：59:f8:b9:22:b1:b9:f7:d2:87:fd:a3:21:78:78:a2:42
    The second nwk key (after Coordinator reset to factory setting) ：31:9b:54:eb:7c:6f:22:ac:d8:fd:99:01:6a:80:2e:40
    TC LINK KEY is default：0x5a, 0x69, 0x67, 0x42, 0x65, 0x65, 0x41, 0x6c, 0x6c, 0x69, 0x61, 0x6e, 0x63, 0x65, 0x30, 0x39
    Thank you for your help.
  • 0 in reply to Toby
    Intellectual 780 points

    Hi Toby！

    Let me briefly explain the packet capture data.

    Capture tool: SmartRF Packet Sniffer 2

    Analysis tool: Wireshark

    Channel: 26

    Description:

    1. The coordinator on line 18 is Permited Joining for 180 seconds, which is not captured here.

    2. From line 19 to line 81, the first device (0x2ac8) enters the network successfully.

    3. Starting from line 181, the coordinator restores the "factory settings" via the "bdb_resetLocalAction()" function. At this point, the first enddevice is still normally requested to restore the original network through the "bdb_ZedAttemptRecoverNwk()" function.

    4. From line 247 to line 314, the second enddevice is powered on and successfully joined in the network.

    5. At line 344, the coordinator begins requesting the first enddevice to leave the network.

    Thank you for your help！

    Coordinator reset to factory bug-2018.12.11.rar

  • 0 in reply to Jesse Huang
    Guru 735695 points
    Between packet 190 to 247, does your ZC already form new network? I mean does the new PANID is generated and network is formed after packet 190?
  • 0 in reply to YiKai Chen
    Intellectual 780 points
    Yes,you are right.The new PANID is generated and network is formed after packet 190.
  • 0 in reply to Jesse Huang
    TI__Mastermind 35070 points
    Hi Jesse,

    Referring the "Parent Lost" section of Z-Stack Overview, the application is responsible for restoring the network. However, in your case, the network that the first ZED joins no longer exists.
    The reset ZC and first ZED are using different NWK keys at this time, so they cannot decrypt the payloads of the Rejoin and Leave requests sent by each other.

    I would try resetting the first ZED to FN.


    Regards,
    Toby
  • 0 in reply to Toby
    Guru 735695 points
    but why ZED does polling to ZC which already forms new network and ZC does Mac ack in Jesse’s sniffer log?
  • 0 in reply to Toby
    Intellectual 780 points

    Hi Toby, Thanks for your reply.

    The"15.3 Parent Lost" in the《Z-Stack 3.0 Developer's Guide》document explains the situation when the enddevice lost its parent node. 

    15.3 Parent Lost
          If an end device loses contact with its parent device or is reset while being on a network, the BDB module will notify the application a status of BDB_COMMISSIONING_PARENT_LOST after which the end device cannot perform any other commissioning method. The device must either restore its network by finding another parent device or reset to factory new and then be commissioned again. To restore the network the device must call bdb_ZedAttemptRecoverNwk, this will cause the device to perform a single active scan in the same channel in which it was part of the network to search for any suitable parent (same Extended PANID and child device capacity). This means that the device will only send a single beacon request and if no suitable parent device is found, another notification BDB_COMMISSIONING_PARENT_LOST is sent to the application. The application is responsible for attempting to restore the network, but it is recommended to have a period in which the attempts have a short interval, then goes to a larger interval, to reduce the power consumption. If Finding and Binding was in progress while the device lost its parent, it will keep running and will resume its operation for the time left after the device restores its operation.

    This means that the enddevice can rejoin the same channel, the same ExtendedPANID but different PANID network?

    Is this the reason for my situation?

  • 0 in reply to Jesse Huang
    TI__Mastermind 35070 points
    The MAC data requests are not encrypted, so the ZC can still ACK.

    The ZED uses an active scan and sees the same extended PANID from the FN ZC. Usually the ZED will rejoin successfully, but since the ZC is now using a different NWK key, the Rejoin/Leave commands are not decrypted correctly.

    I believe that section is assuming that the two devices can communicate successfully at the NWK layer.
    Yes, you're right. For example, the PANID could change due to PANID conflict (see the "PAN ID Conflict" section of Z-Stack Overview).
  • 0 in reply to Toby
    Intellectual 780 points

    Hi Toby, Thanks for your reply.

    I understand the reason for the problem.But how do I restore the coordinator to factory settings and the coordinator is not affected by the original network?

  • 0 in reply to Jesse Huang
    TI__Mastermind 35070 points
    Would you clarify the meaning of "not affected by the original network"?

    Let's say the first network the ZC formed is NET1, and after resetting to FN, ZC forms network NET2.
    ZED1 connected to NET1. What behavior are you expecting for ZED1 when ZC forms NET2?
  • 0 in reply to Toby
    Intellectual 780 points

    Hi Toby, Thanks for your reply.

    Why does the ZC always send leave request command to ZED1 that has left the network?

    Does this not cause network congestion?

  • 0 in reply to Jesse Huang
    Guru 735695 points
    Since coordinator forms new network and cannot recognize the device, it will send leave request to the device to ask it leave. I think if there are lots of such end devices, it might cause network congestion.
  • 0 in reply to YiKai Chen
    Intellectual 780 points
    Yes, I think so. So I think this may not be reasonable.
  • 0 in reply to Jesse Huang
    TI__Mastermind 35070 points
    The issue is that ZED1 does not consider itself to have left the network because it cannot decrypt the Leave request from the FN ZC (since they are using different NWK keys).

    If you want to ensure that ZED1 has left the network, then perhaps the ZC should send a leave request before resetting to FN.
  • 0 in reply to YiKai Chen
    Intellectual 780 points

    Hi, yikai.

    Toby suggests that the coordinator send leave commands to all enddevices in the network before the coordinator reset to factory new?

    what do you think?

  • 0 in reply to Jesse Huang
    Guru 735695 points
    Yes, that’s one alternative. Another is to do factory reset to device itself.
  • 0 in reply to Toby
    Intellectual 780 points
    OK, thank you very mach for your help!