• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 56 subscribers
  • Views 1246 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.

CC2538: Rejoin Policy in Zigbee 3.0.1

adrian humanes
Prodigy 230 points
Part Number: CC2538
Other Parts Discussed in Thread: Z-STACK

I am working with the z-stack 3.0.1 in a cc2538 as ZC and I have a question about the rejoins. I would like the ZC to follow the following policy about the rejoins:

-Secured Rejoin: When a device does a secured rejoin to allow it to rejoin the network (normal behaviour).

-Unsecured Rejoin: Do not let a device rejoins the network without the network key. When I say "Dont let" I mean dont send the device the network key. Here is when my problem comes because when a device performs a unsecured rejoin the ZC sends it a Leave command with rejoin field set to False, so the device is removed from the network forever (In the z-stack 1.2 the ZC sent the Leave with the rejoin to 1, allowing the device retry to do a secured rejoin a therefore join the network successfully).

At present, I have managed to not remove the device when performs a unsecured rejoin through a ZR beacuse I have commented the calls to APSME_RemoveDeviceReq( &remDevReq ) in the ZDSecMgrDeviceRemove function. But when the unsecured rejoin is directly to the ZC the device is removed.

I know that exist a variable on the code called zgAllowRejoins which I have set by default because dont want a device can rejoin without security.

Is there any way to got this for example changing any part of the code in the firmware?

Regards.

  • 0
    TI__Guru**** 202096 points
    You can try removing device validation from ZDSecMgrDeviceJoin. The Stack specifications do not allow unsecured rejoins with permit joining disabled.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Guru 735455 points

    Do you mean Z-Stack only allow secure rejoin by default and if we need insecure rejoin, we need to removing device validation from ZDSecMgrDeviceJoin in Z-Stack?

  • 0 in reply to Ryan Brown1
    Prodigy 230 points

    Hi Ryan,

    I have removed the device validation like you told me,  but I keep having the same problem: the ZC sends a Leave command with rejoin to FALSE (instead of to TRUE or do nothing) when a ZED perform a unsecured rejoin. (attached screenshots)

    Regards

    Unsecured rejoin.zip

  • 0 in reply to adrian humanes
    TI__Guru**** 202096 points
    Hi YK,

    Apologies for the confusion, Z-Stack currently processes rejoins as such: 1. Secure 1 channel 2.Secure all channels 3. Unsecure 1 channel 4. Unsecure all channels continuously. At this point, the parent will tell it to factory reset.

    Hi adrian,

    Accepting the rejoin packet (rejoin response) and processing the security part (allowing a ZED rejoin) are two separate steps. At first Z-Stack accepts an unsecure rejoin, then it checks to see if your TC policy is to accept or reject unsecure rejoins if you allow it, followed by sending the transport key or a leave w/o rejoin. Can you please clarify what you would like to happen? If you don't want to allow unsecure rejoins then why do you care if the joining device is factory reset if it is trying to perform an unsecure rejoin?

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Guru 735455 points
    I am still confused on “At this point, the parent will tell it to factory reset.” Can you elaborate this a little bit?
  • 0 in reply to Ryan Brown1
    Prodigy 230 points

    Hi Ryan,

    I want that when a device performs a unsecured rejoin my ZC 3.0 has the same behaviour like in 1.2: the ZC accepts the rejoin packet and sends a leave ind with the REJOIN field equals to TRUE. 

    For my is important this point because I always work with thrid party devices (until now the most are 1.2), and some ZED like sensors follow the following policy when are insolated: To do an unsecured rejoin and if this is not successful they performs a secured rejoin. So if my ZC send the sensor a Leave ind with rejoin equals to FALSE, they will never try to do a rejoin again and will leave the network forever.

    I attach two screenshot in a .zip in which you will find the behaviour of my ZC 1.2 and 3.0 facing a unsecured rejoin sent by the same sensor.

    Regards.

    Unsecured rejoin in 1.2 and 3.0.zip

  • 0 in reply to YiKai Chen
    TI__Guru**** 202096 points
    Hi YK,

    Leave request with rejoin equal to zero.

    Hi adrian,

    Thank you for clarifying, unfortunately that logic resides in the Z-Stack library and cannot be altered by users. I'll ask the software developers if they have any additional input.

    Regards,
    Ryan