CC2530: Software Reset on Network Leave

Dear Jose,

I will share a screen shot of the packet.

Dear Jose,

Here is the command fired from coordinator.

ZigBee Network Layer Data, Dst: 0x8ab5, Src: 0x0000

   Frame Control Field: 0x0248, Frame Type: Data, Discover Route: Enable, Security Data

       .... .... .... ..00 = Frame Type: Data (0x0)

       .... .... ..00 10.. = Protocol Version: 2

       .... .... 01.. .... = Discover Route: Enable (0x1)

       .... ...0 .... .... = Multicast: False

       .... ..1. .... .... = Security: True

       .... .0.. .... .... = Source Route: False

       .... 0... .... .... = Destination: False

       ...0 .... .... .... = Extended Source: False

       ..0. .... .... .... = End Device Initiator: False

   Destination: 0x8ab5

   Source: 0x0000

   Radius: 29

   Sequence Number: 47

   [Extended Source: TexasIns_00:09:dd:6a:97 (00:12:4b:00:09:dd:6a:97)]

   [Origin: 125]

   ZigBee Security Header

       Security Control Field: 0x28, Key Id: Network Key, Extended Nonce

           ...0 1... = Key Id: Network Key (0x1)

           ..1. .... = Extended Nonce: True

       Frame Counter: 30784

       Extended Source: TexasIns_00:09:e2:90:65 (00:12:4b:00:09:e2:90:65)

       Key Sequence Number: 0

       Message Integrity Code: aff38068

       [Key: 08bf0670002440db705b643b6b13ee0d]

       [Key Origin: 203]

ZigBee Application Support Layer Command

   Frame Control Field: Command (0x01)

       .... ..01 = Frame Type: Command (0x1)

       .... 00.. = Delivery Mode: Unicast (0x0)

       ..0. .... = Security: False

       .0.. .... = Acknowledgement Request: False

       0... .... = Extended Header: False

   Counter: 95

   Command Frame: Remove Device

       Command Identifier: Remove Device (0x07)

       Device Address: TexasIns_00:01:c3:19:99 (00:12:4b:00:01:c3:19:99)

And then a Leave command is boradcasted by the device, and it has the following params

ZigBee Network Layer Command, Dst: Broadcast, Src: 0x8ab5

   Frame Control Field: 0x1209, Frame Type: Command, Discover Route: Suppress, Security, Extended Source Command

       .... .... .... ..01 = Frame Type: Command (0x1)

       .... .... ..00 10.. = Protocol Version: 2

       .... .... 00.. .... = Discover Route: Suppress (0x0)

       .... ...0 .... .... = Multicast: False

       .... ..1. .... .... = Security: True

       .... .0.. .... .... = Source Route: False

       .... 0... .... .... = Destination: False

       ...1 .... .... .... = Extended Source: True

       ..0. .... .... .... = End Device Initiator: False

   Destination: 0xfffd

   Source: 0x8ab5

   Radius: 1

   Sequence Number: 168

   Extended Source: TexasIns_00:01:c3:19:99 (00:12:4b:00:01:c3:19:99)

   ZigBee Security Header

       Security Control Field: 0x28, Key Id: Network Key, Extended Nonce

           ...0 1... = Key Id: Network Key (0x1)

           ..1. .... = Extended Nonce: True

       Frame Counter: 35

       Extended Source: TexasIns_00:01:c3:19:99 (00:12:4b:00:01:c3:19:99)

       Key Sequence Number: 0

       Message Integrity Code: db8ea232

       [Key: 08bf0670002440db705b643b6b13ee0d]

       [Key Origin: 203]

   Command Frame: Leave

       Command Identifier: Leave (0x04)

       ..0. .... = Rejoin: False

       .0.. .... = Request: False

       0... .... = Remove Children: False

Dear Jose,

I have also tried by the method that you have suggested by defining a Callback in application code and I face the same problem here also, that the device rejoins the network without even having permit join by the coordinator.

If you are calling bdb_resetLocalAction() then that is weird. Can you share your callback function?

Rejoins doesn't need the network to be open because the device was already authenticated and has the network information. Permit join allowed is only required by devices that will be associated to the network for the first time.

  

Dear Jose,

Here is my code structure:

In samplelight_init I have registered the CB as  ZDO_RegisterForZdoCB( ZDO_NWK_DISCOVERY_CNF_CBID, App_NwkDiscoveryCnfCB );

and its declaration is as static void *App_NwkDiscoveryCnfCB( void *param );

and its callback is

static void *App_NwkDiscoveryCnfCB( void *param )
 {

zclApp_BasicResetCB();
bdb_resetLocalAction();

}

For testing purpose I have not checked any parameters, directly called bdb_resetLocalAction();

This looks good. So App_NwkDiscoveryCnfCB() but the device doesn't leave the network and is not reset to factory new?

Dear Jose,

So here I get a App_NwkDiscoveryCnfCB() callback on device leave and in this I have called bdb_resetLocalAction();.

But the problem is device leaves the network and rejoins again without permit join, so as you said early it is already authenticated so it does not need validation again because it already has the keys, I think it is not clearing the NV.

Hi Ajit_Wadekar,

I just noticed that you used ZDO_NWK_DISCOVERY_CNF_CBID instead of ZDO_LEAVE_CNF_CBID change your ZDO_RegisterForZdoCB() like this:

ZDO_RegisterForZdoCB(ZDO_LEAVE_CNF_CBID, App_NwkDiscoveryCnfCB)

Also look for ZDO_LEAVE_CNF_CBID in your project to see if the callback isn't registered for another function, then put a breakpoint on App_NwkDiscoveryCnfCB() to see if is triggered after a network leave is received.

I just tested this and it's working. Please let me know if works for you.

Dear Jose,

I tried as you suggested but the porblem still persists. It joins the network without permit join (NV not cleared).

I have following code in the Samplelight_Init, does this affect the code device remove and rejoin automatically?

ZDO_RegisterForZdoCB(ZDO_LEAVE_CNF_CBID, App_NwkDiscoveryCnfCB);

 ZDOInitDevice(0);

 status_test = ZDApp_RestoreNetworkState();

 if( status_test != ZDO_INITDEV_NEW_NETWORK_STATE  )

 {

   bdb_StartCommissioning(BDB_COMMISSIONING_REJOIN_EXISTING_NETWORK_ON_STARTUP);

 }

 else

 {

   bdb_StartCommissioning(BDB_COMMISSIONING_MODE_NWK_STEERING | BDB_COMMISSIONING_MODE_NWK_FORMATION | BDB_COMMISSIONING_MODE_FINDING_BINDING);

 }

 

Hi Ajit_Wadekar,

My advice is to start with a fresh new project, add just the changes to have your App_NwkDiscoveryCnfCB() try again and continue from there adding your stuff. There is something in your application that is preventing this to work as expected, when the ZDO_LEAVE_CNF_CBID callback is properly configured, then add your other changes.

Start just with this and tell me how it goes. If there is something wrong it will be easier to track.

Regards,

Dear Jose,

I have tried this with fresh samplelight project, my project has following modifications:

void *App_NwkDiscoveryCnfCB( void *param );

In samplelight_init

  //Find New network if not already in some network
  ZDO_RegisterForZdoCB(ZDO_LEAVE_CNF_CBID, App_NwkDiscoveryCnfCB);
  ZDOInitDevice(0);
  status_test = ZDApp_RestoreNetworkState();
  if( status_test != ZDO_INITDEV_NEW_NETWORK_STATE  )
  {
    bdb_StartCommissioning(BDB_COMMISSIONING_REJOIN_EXISTING_NETWORK_ON_STARTUP);
  }
  else
  {
    bdb_StartCommissioning(BDB_COMMISSIONING_MODE_NWK_STEERING | BDB_COMMISSIONING_MODE_NWK_FORMATION | BDB_COMMISSIONING_MODE_FINDING_BINDING);
  }

in samplelight_event_loop

case ZDO_STATE_CHANGE:
        UI_DeviceStateUpdated((devStates_t)(MSGpkt->hdr.status));
        switch ((devStates_t)(MSGpkt->hdr.status))
        {
        case DEV_HOLD:
          bdb_StartCommissioning(BDB_COMMISSIONING_MODE_NWK_STEERING | BDB_COMMISSIONING_MODE_NWK_FORMATION | BDB_COMMISSIONING_MODE_FINDING_BINDING);
        }
        break;

And CB function

static void *App_NwkDiscoveryCnfCB( void *param )
{
  bdb_resetLocalAction();
}

Hi Ajit_Wadekar,

bdb_StartCommissioning() automatically inits the ZDO device and restores the network state. You can remove this piece of code:

In samplelight_init

 ZDOInitDevice(0);

 status_test = ZDApp_RestoreNetworkState();

 if( status_test != ZDO_INITDEV_NEW_NETWORK_STATE  )

 {

   bdb_StartCommissioning(BDB_COMMISSIONING_REJOIN_EXISTING_NETWORK_ON_STARTUP);

 }

 else

 {

   bdb_StartCommissioning(BDB_COMMISSIONING_MODE_NWK_STEERING | BDB_COMMISSIONING_MODE_NWK_FORMATION | BDB_COMMISSIONING_MODE_FINDING_BINDING);

 }

Just leave this at the end of samplelight_init:

ZDO_RegisterForZdoCB(ZDO_LEAVE_CNF_CBID, App_NwkDiscoveryCnfCB);

bdb_StartCommissioning(0);

and instead of using ZDO_STATE_CHANGE, look at zclSampleLight_ProcessCommissioningStatus() and use the bdb initalization case as follows:

case BDB_COMMISSIONING_INITIALIZATION:
//Initialization success
if(bdbCommissioningModeMsg->bdbCommissioningStatus == BDB_COMMISSIONING_NETWORK_RESTORED)
{
/*************************************************************************************
The device is now in its network prior power cycle.
start application logic, Ej. send commands...
**************************************************************************************/
}
if(bdbCommissioningModeMsg->bdbCommissioningStatus == BDB_COMMISSIONING_NO_NETWORK)
{
/*************************************************************************************
ZC or ZR were not in a network prior power cycle.
Possible options:
1.- bdb_StartCommissioning(BDB_COMMISSIONING_MODE_NWK_STEERING)
2.- bdb_StartCommissioning(BDB_COMMISSIONING_MODE_NWK_FORMATION)
**************************************************************************************/

bdb_StartCommissioning(BDB_COMMISSIONING_MODE_NWK_STEERING | BDB_COMMISSIONING_MODE_NWK_FORMATION | BDB_COMMISSIONING_MODE_FINDING_BINDING);
}
break;

Try fresh sample light with this changes and tell me how it goes.

Regards

Dear Jose,

I have tried what you have suggested with fresh Z-Stack 3.0.1. Here only change I have made is -DDEFAULT_CHANLIST=0x07FFF800 in f8wConfig.cfg in order to have dynamic channel assignment.

But still the device get added in the network without permit join.

Hi Ajit_Wadekar,

That's weird. Are you able to use the user interface of the sample app to reset the device to factory new or add bdb_resetLocalAction() to a switch button.

Regards,

Just to clarify in case that you are unaware, reprogramming the chip doesn't erase the non volatile memory, this is to keep the network data on firmware updaes.

Dear Jose,

Sorry for the delayed reply.

I tested it further. The problem is with NV Clear, could you please tell me how can I debug this problem.

If you could tell me the points where I can check the NV on Bootup where it should have cleared memory I would be able to debug it using breakpoints.

Hi Ajit_Wadekar,

Look at ZDOInitDeviceEx() on networkStateNV must be equal to ZDO_INITDEV_NEW_NETWORK_STATE after ZDApp_ReadNetworkRestoreState() is executed when device is reset after bdb_resetLocalAction(), Reset your device and execute the initialization then you should end on this piece of code:

  if ( networkStateNV == ZDO_INITDEV_NEW_NETWORK_STATE )
  {
    ZDAppDetermineDeviceType();

    // Only delay if joining network - not restoring network state
    extendedDelay = (uint16)((NWK_START_DELAY + startDelay)
              + (osal_rand() & EXTENDED_JOINING_RANDOM_MASK));

    runtimeChannel = zgDefaultChannelList;
    
    // Set the NV startup option to force a "new" join.
    zgWriteStartupOptions( ZG_STARTUP_SET, ZCD_STARTOPT_DEFAULT_NETWORK_STATE );
    
#if !defined (DISABLE_GREENPOWER_BASIC_PROXY) && (ZG_BUILD_RTR_TYPE)
    gp_ProxyTblInit( TRUE );
#endif

    _NIB.nwkDevAddress = INVALID_NODE_ADDR;
    _NIB.nwkCoordAddress = INVALID_NODE_ADDR;
    _NIB.nwkPanId = 0xFFFF;
    osal_memset(_NIB.extendedPANID, 0, Z_EXTADDR_LEN);
    NLME_SetUpdateID( 0 );
    
    if(ZG_DEVICE_RTRONLY_TYPE)
    {
      if(1 == mode)
      {
        //Update TC address as distributed network (TC none)
        ZDSecMgrUpdateTCAddress(0);
      }
      else
      {
        // Centralized mode
        uint8 tmp[Z_EXTADDR_LEN];
        osal_memset(tmp,0x00,Z_EXTADDR_LEN);
        ZDSecMgrUpdateTCAddress(tmp);
      }
    }

    // Update NIB in NV
    osal_nv_write( ZCD_NV_NIB, 0, sizeof( nwkIB_t ), &_NIB );

    // Reset the NV startup option to resume from NV by clearing
    // the "New" join option.
    zgWriteStartupOptions( ZG_STARTUP_CLEAR, ZCD_STARTOPT_DEFAULT_NETWORK_STATE );
  
  }

Here the network data is restored to factory defaults.

I hope this helps.

Regards

Dear Jose,

After testing and debuggig further I found that the problem is not with the device but with the coordinator.

Here I am using Z-Stack 3.0 with Linux Gateway 1.2 in this I have observed the following points:

1) When a device leaves the network through manual reset, it does not join the network as the beacan response from coordinator has Association Permit = False (can be seen on line no 132 of sniffer log) and it remains false until the Gateway sends permit join command.

2) But when we remove device from Coordinator using Linux Gateway the device broadcasts leave request and does system reset and start sending beacons for new network join, so when a becaon is sent by the device the becon response from Cooridnator consists of Association Permit = True (can be seen on line no 217 of sniffer log), due to which the device joins the network without permit join.

3) Now I have updated the Coorindator with ZNP of Z-Stack HA 1.2, so when I use this Old Stack ZNP I dont see above problem and device does not join the network  automatically as Association Permit = False for beacon response from coordinator.

So I would like to know how can we make Z-Stack 3.0 ZNP make compatible with Z-Stack Linux Gateway 1.2?

Also here is the sniffer logs for above cases, here my network key is the default one as mentioned in

Device Leave Auto Rejoin because of Coordinator.zip

Hi Ajit_Wadekar,

By Zigbee spec is not permitted for zigbee coordinator to process leave requests because you don't want a router or end device kicking the coordinator from the network. If you change this on code your device will not be certifiable.

Regards,

Dear Jose,

I don't understand.

Remove command was sent from the coordinator(Linux Gateway) and based on that we added a callback for Leave Request which clears the NV.
But you are saying that the device cant leave.

Did you check my Sniffer Log? The device is leaving the network, not the coordinator.

If it is not supposed to leave the network, how come manual reset is working? Because it also sending the same Leave Command.

Dear Jose,

Please check my Sniffer log shared in previous post, it will give a clear idea of the case scenario.
The key for my log is 5a6967426565416c6c69616e63653039

In the log the Leave command on Line No 127 is from Manual Switch which works fine and the other Leave command on Line no 214 is from due to Remove command from Zigbee Coordinator.

Hi Ajit_Wadekar,

That's the Zigbee alliance pre-configured trust center link key. I need the network key to decrypt the capture. If you are using a secret network key that will be used in production then is not recommendable to share it. You can configure another key an repeat the test again.

Did you checked if the device falls on App_NwkDiscoveryCnfCB() that you registered for ZDO_LEAVE_CNF_CBID when a leave command is received?

Regards,

Dear Jose,

Yes I have checked, we get a callback as per registered ZDO_RegisterForZdoCB(ZDO_LEAVE_CNF_CBID, App_NwkDiscoveryCnfCB);

I have sent you a friend request, please accept it so that I can messeg you the keys.

Dear Jose,

I have already check that I get a callback on Leave Request, but as said earlier that the problem is because of following reasons is what I feel and this can be observed in the following sniffer log:

8032.Device Leave Auto Rejoin because of Coordinator.zip

1) When a device leaves the network through manual reset, it does not join the network as the beacan response from coordinator has Association Permit = False (can be seen on line no 132 of sniffer log) and it remains false until the Gateway sends permit join command.

2) But when we remove device from Coordinator using Linux Gateway the device broadcasts leave request and does system reset and start sending beacons for new network join, so when a becaon is sent by the device the becon response from Cooridnator consists of Association Permit = True (can be seen on line no 217 of sniffer log), due to which the device joins the network without permit join.

Hi Ajit_Wadekar,

From your capture is clear that the device is set to factory new when leaves the network, the device with IEEE 00:12:4b:00:01:c3:19:99 performs association instead of rejoin, that means that the network info was erased and each new join gives a different short address (0x446C, 0xBB67, 0xEC30).

As you said the packet 217 is a beacon from the coordinator with Association permit equal to TRUE, this means that is open for joining. ZDO permit join is a command that opens the network for a period of time, in the packet 145 the coordinator sent a permit join with duration of 60 seconds, this means Association permit equal to TRUE for 60 seconds so any device that gets a beacon for this open network can attempt to join.

There is nothing bad on this capture.

Regards,

 

Dear Jose,

Yes you are right, once device joins the network it broadcasts Permit Join request of 180 seconds which is not visible on Z-Stack Linux Gateway, due to which when we remove the device in that time the device rejoins the network. But If I remove the same device after 180 seconds it does not join the network.

Can you please tell me why does device broadcasts permit join after it joins the network?

Dear Jose,

Thank you for the help.