[Bitcloud 3.2.0] dstNwkAddr member missing in ZDO_ZdpReq_t struct. permitDuration implementation.

Go To Last Post
19 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey Y'all.

 

I have been trying to implement the permitDuration functionality to only allow a device to join the network for a short period of time, however I don't seem to be able to implement it correctly. According to the documentation the dstNwkAddr still exists in the ZDO_ZdpReq_t. But doing a complete file search for this member, it only exists in a comment. I believe that it has been removed since the early versions and the documentation has not been updated. Thus trying all previous implementations of this on the forums, does not appear to work.

 

So with a slight modification, I tried the following:

 

volatile uint8_t permitCalledBack = 1;
static ZDO_ZdpReq_t zdpRequestJoining;
static APS_Address_t address;
				
static void zdoPermitJoiningResp(ZDO_ZdpResp_t *zdpResp) //callback function
{
	(void)zdpResp;
	permitCalledBack = 1;
}

//if button is pressed...
    if (permitCalledBack)
    	{
    		permitCalledBack = 0;
    		//address.shortAddress = BROADCAST_ADDR_ROUTERS;
    		address.shortAddress = 0;
    
    		zdpRequestJoining.reqCluster = MGMT_PERMIT_JOINING_CLID; //Request type
    		zdpRequestJoining.dstAddrMode = APS_SHORT_ADDRESS; //Addressing mode
    		//zdpRequestJoining.dstNwkAddr = BROADCAST_ADDR_ROUTERS; //Address of the destination
    		zdpRequestJoining.dstAddress = address;
    		
    		zdpRequestJoining.req.reqPayload.mgmtPermitJoiningReq.permitDuration = 0x00;
    		zdpRequestJoining.req.reqPayload.mgmtPermitJoiningReq.tcSignificance = 0;
    		zdpRequestJoining.ZDO_ZdpResp = zdoPermitJoiningResp; //Confirm callback
    		zdpRequestJoining.req.reqPayload.mgmtPermitJoiningReq.permitDuration = 0x00;
    		ZDO_ZdpReq(&zdpRequestJoining);
    	}

I am using the ATRCB256rfr2 and on button press, the above is executed. I can garuntee that this does somewhat work as when I set a breakpoint in the callback, it jumps into it. However, once pressing the button I power up a fresh router and it joins the network right away. Despite both being freshly programmed.

 

My application is based on the WSNDemo utilising STDLINK_SECURITY_MODE and security status 0 on both devices.

 

Any help would be greatly appreciated =D

Last Edited: Thu. Oct 15, 2015 - 09:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I do the following:

ZDO_MgmtPermitJoiningReq_t *permit = &ZdpRequest.req.reqPayload.mgmtPermitJoiningReq;

ZdpRequest.ZDO_ZdpResp = zdoPermitJoiningResp;
ZdpRequest.reqCluster  = MGMT_PERMIT_JOINING_CLID;
ZdpRequest.dstAddrMode = APS_SHORT_ADDRESS;

ZdpRequest.dstAddress.shortAddress = NWK_GetShortAddr();

if (PermitJoin)
	permit->permitDuration = 0xFF;
else
	permit->permitDuration = 0x00;

permit->tcSignificance = 0x01;

ZDO_ZdpReq(&ZdpRequest);

it works for me. Hopefully this will help you.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Sashal,

 

Thanks for your example. Where did you implement this? I am basing my application on the WSNDemo and put this request directly into the main loop with a button press.

 

Is yours somewhere else in the application? Perhaps in a callback function or added to the task list another way?

 

What security type are you running?

Last Edited: Tue. Sep 15, 2015 - 12:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It must work in interrupt too but only if your device does not sleep. But I would put it in APL_TaskHandler(). And as I know ZDP is working at any security type.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I thought only ED could sleep and they don't allow child devices anyway? It might not be the code then, just my implementation. See if you can catch where in the following I may have done a mistake.

 

When everything is working, my router should not be able to join my coordinator unless I press a button on the coordinator that allows connections for 120 seconds.

 

Test scenario run to disable all join requests

- I am testing only with a router and coodinator.

- Both are working on STDLINK Security with type 0.

- Randomly generated MAC and PAN is associated with the devices.

- My 128bit CS_NETWORK_KEY is matched on both devices

- I initiate your previous example with a button press on the coordinator, setting the permitDuration to 0x00 (commented out the if statement). This is done in the main loop. Also tried in the task handler, but no different.

- I also later set CS_PERMIT_DURATION to 0 for a test condition

- I first program my coordinator and press the button, request is ran, callback is called. while my router is off

- Then reprogram my router so it has no settings held form the coordinator.

 

router connects within 2 seconds to the coordinator. Sometimes up to 30, but generally very quick when this is done.

 

There has to be an implementation issue I have because the zdp request with permit join 0 is yet to stop any router that I have ever had from joining the coordinator.

 

Any ideas on what I might be doing wrong? or perhaps a step that I may have missed?

Last Edited: Tue. Sep 15, 2015 - 07:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Router can sleep too. But it must be done very carefully and intelligently. Stack has parameter for that: CS_FFD_SLEEP_PERIOD.

When do not press button is router connect? 

As I know CS_PERMIT_DURATION affects only when node join network through NWK_JOIN_VIA_ASSOCIATION. In another case, the node will join anyway.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The button is only on the coordinator, so I press the button on the coordinator it sends through the disable request.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, simply after create network send MGMT_PERMIT_JOINING_CLID request at COO. Is router connect? If yes, problem in request, otherwise in implementation your logic.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No change.

 

I added it to the appZdoStartNetworkConf callback. The router joined the network straight away still :(

 

static ZDO_ZdpReq_t ZdpRequest;

//permitDuration callback
static void zdoPermitJoiningResp(ZDO_ZdpResp_t *zdpResp) //callback function
{
    (void)zdpResp;
    //permitCalledBack = 1;
}

static void appZdoStartNetworkConf(ZDO_StartNetworkConf_t *startInfo)
{
	manageBlinkingDuringRejoin(STOP_BLINKING);

	//Check if the node has successfully started the network
	if (ZDO_SUCCESS_STATUS == startInfo->status)
	{
		appState = APP_IN_NETWORK_STATE;
		visualizeNwkStarted();
		#if APP_USE_OTAU == 1
		runOtauService();
		#endif // APP_USE_OTAU
		if (deviceInterface.appDeviceTaskReset)
		deviceInterface.appDeviceTaskReset();

		// Network parameters, such as short address, should be saved
		appNwkInfo.panID           = startInfo->PANId;
		appNwkInfo.shortAddr       = startInfo->shortAddr;
		appNwkInfo.parentShortAddr = startInfo->parentAddr;
		appNwkInfo.workingChannel  = startInfo->activeChannel;
		///////////////////////////////////////////////////////////////////////////////////////
		ZDO_MgmtPermitJoiningReq_t *permit = &ZdpRequest.req.reqPayload.mgmtPermitJoiningReq;

		ZdpRequest.ZDO_ZdpResp = zdoPermitJoiningResp;
		ZdpRequest.reqCluster  = MGMT_PERMIT_JOINING_CLID;
		ZdpRequest.dstAddrMode = APS_SHORT_ADDRESS;

		ZdpRequest.dstAddress.shortAddress = NWK_GetShortAddr();

		// 			if (PermitJoin)
		// 			permit->permitDuration = 0xFF;
		// 			else
		permit->permitDuration = 0x00;

		permit->tcSignificance = 0x01;

		ZDO_ZdpReq(&ZdpRequest);
		appState = APP_IN_NETWORK_STATE;
	}
	else
	appPostGlobalTask();
}

Might start with the base WSNDemo on 3.1.0...just to try and different version and see if I can at least block the join request with a simple application.

 

Could you possibly provide me with an example BASE wsndemo project that worked for you ;)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

If you are using rejoin (as opposed to association) for the joining router, then none of this will help. Rejoin is designed for devices that lost network connection and want to recover it.

 

It is assumed that rejoining device knows security keys (otherwise it won't be able to send a rejoin request).

 

If you are running unsecured network, then none of this makes sense, since any device can simply self-configure to work on that network without asking any other device.

 

Edit: I see you use security, but with preconfigured keys. So joining device has all the information it needs to rejoin the network. You can't really prevent it from joining, since it does not have to ask you for anything to be a part of the network.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Last Edited: Wed. Sep 16, 2015 - 01:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Alex,

 

Thanks for the info. What security type would your recommend for a product that must have a similar key of some kind so people can't just join in without knowing it, but can still be disallowed to join through permitDuration?

 

Does this mean I can only use security status's 1 with a trust center key or 2 with a master key?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

1 would be sufficient.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So after setting the coordinator and router to stdlink securtity with status 1, doing the same on the router I still get the same result with the code above. The router may take a little longer to join but in the end it still joins the network.

 

I also set CS_EXT_PANID 0xFFFFFFFFFFFFFFFFLL on the router and default 0xAAAAAAAAAAAAAAAALL on the coordinator...if that means anything.

 

I have attached the source if that helps...

 

I am using a Wireless Xplained RCB256RFR2 - Xpro as my coordinator and a Zigbit as my router. I changed the LED control in the bitcloud stack BSP to match the boards.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

CS_EXT_PANID should be 0 on the router. I have no idea what happens when it is 0xff...ff.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Despite what the documentation said, when I put it to 0LL, it wouldn't connect. However, when I put it to 0xFFF...it connected to whatever extended pan was available. Perhaps there could be an issue surrounding this?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Would not connect with what status code? Do you have permission enabled at this point?

 

And actually, change status to 3 and use standard security mode.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I put the extended pan back to 0LL instead of the 0xFF...LL and the permitDuration appears to be working correctly now. Rejoin (NWK_JOIN_VIA_COMMISSIONING) when the router restarts doesn't however, I think I just have to create an implementation for this, perhaps wasn't included in the wsndemo?

 

Interesting that when providing an extended PAN of 0xFF...LL it always connects despite the permitDuration value.

Last Edited: Fri. Sep 18, 2015 - 01:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

ryanafleming wrote:
Rejoin (NWK_JOIN_VIA_COMMISSIONING) when the router restarts doesn't however
And it should not. NWK_JOIN_VIA_COMMISSIONING is designed for starting a network with known parameters. You are supposed to manually put those parameters into proper places. 

 

The correct way to save and restore state is to use PDS. I don't think WSNDemo shows how to do that, but ZLLDemo and HADemo do, so you can look at their source code. It is not that hard, and don't forget to enable PDS in the configuration file.

 

ryanafleming wrote:
Interesting that when providing an extended PAN of 0xFF...LL it always connects despite the permitDuration value.
I'm not sure what happens exactly. I assume device still does rejoin, so it ignores permission settings. It is hard to say without a sniffer log.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Enabled PDS in the configuration file and it worked right away with no changes required!

 

Thanks for all the help alex and Sashal!