Broadcast NwkAddrReq not resolved by ZC

Hi,

I've done some more tests: I've substituted the ZR (netvox) by a CC2531 that runs the ZStack 2.5.0 as a router. When this router sends a NwkAddrReq with the IEEE addr of the coordinator (broadcast as well, FFFD (I was wrong in my first post)) the ZC reply.

But when the ZED (netvox) sends the same request, the ZC does not reply.

I used sniffer to analyze OTA messages content, I didn't see any significant differences between the 2 NwkAddrReq.

Any suggestion will be helpful at this point.

Thanks,

BR

Mathias

Hi,

my last tests seems to indicate that this is a "basic" ZigBee routing problem:

Indeed when the ZED's parent is the ZR (at initial state I mean), the ZC replies to the NwkAddrReq.

So it seems that the ZED is still known in the ZC's route cache table after migration. and even hours after the migration happened, the ZC does not reply, just as if it waits for a DataReq from the ZED to respond.

Is there a way to force route cache update from the application layers ?

Thanks

BR

Mathias

Hi

In order to go deeper into my investiguations, I tried to do the following experimentation: 

I use the ZStack 2.5.1, 

the application "HomeAutomation/SwitchApp" provided with the ZStack 2.5.1 and add NV_RESTORE and NV_INIT in the f8wCnfig.cfg file.

I have compiled it as a Coordinator and have downloaded it on a CC2530EM.

I first associate a End Device to the coordinator, and secondly a router (so that the ZED is associated directly to the ZC, and not the ZR)

Then I switch off the coordinator (to simulate a node failure) and the ZED get associated to the ZR.

Then I restart the ZC, it restarts sending its periodic "Link Status" and the ZR can successfully communicate with the ZC.

But when the ZED sends a request that the ZC should respond (broadcast NWKAddrReq with the IEEE address of the ZC), it does not. In fact the ZC first broadcasts the NWKAddrReq as it has to, but does not send any NWKAddrRsp (my supposition is that it waits for a DataReq from the ZED before sending it).

Finally when I switch off the router, the ZED rejoin to the coordinator, and it works fine.

From my understanding and from what I read on this forum, this should work (?)

When the ZED migration is caused by moving the ZC away from the ZED, it works well: the ZC first broadcasts the NWKAddrReq and then sends a NWKAddrRsp.

I also tried to set ZCD_NV_ROUTER_OFF_ASSOC_CLEANUP to TRUE, as it is suggested in ZStack developer's guide, and the route gets effectively restored when sending unicast request, but still fails with broadcast NwkAddrReq...

Is this a normal behavior ?

Is it a known bug with broadcast requests ?

Do I need to add another compilation option to make it work ?

Thanks

BR

Mathias

Hi Mathias,

The problem comes from the situation that the ZC misses the device announce from the new parent of the ZED while it is powered off. Z-Stack 2.5.1 includes the fix for this problem.

Can you please set zgRouterOffAssocCleanup to TRUE in zGlobals.c on your ZC/ZRs and give it a try?

- Cetri

Hi Cetri,

thank you very much for your quick answer,

I tested what you've proposed, and this doesn't work for the Broadcast NwkAddrReq (the ZC still broadcast the request, but does no send any NwkAddrRsp).

But it works with unicast request (I tried with a IEEEAddrReq sent from the ZED to the ZC); and then the Broadcast NwkAddrReq works (as route from ZC to ZED is restored).

In fact my root problem is that the ZED (a NetVox temperature sensor I have to work with) sends periodic report attribute to the ZC, and when I switch off the ZC and the ZED gets associated to the ZR, it starts sending broadcast NwkAddrReq with the bound IEEE address (the ZC in my case). If the ZC replies to the NWKAddrReq the ZED restarts sending report attribute.

I read in another post someone that tried to repair the route by sending a DeviceAnnce as soon as the ZC rejoins. Do you think it can help ?

Mathias

Hi, 

Cetri, my idea of broadcasting a DeviceAnnce was to force update of routing tables on the ZED. I did this test and of course it cannot work as far as by definition the ZED does not receive the DeviceAnnce (not RxOnWhenIdle device type…). At least it gave me the opportunity to understand some details on broadcast mechanisms that I hadn’t got yet.

I also tried to send NWKAddrReq from the ZC for all IEEE address that I know in my application. Even if the ZR responds, this didn’t refresh the neighbor associated device list.

My last attempt was a completely different approach, I tried to send a unicast MgmtLeaveReq to each node known in my application (the ZR and the ZED), I can see the outgoing MgmtLeaveReq message to the ZR, but of course not the one to the ZED. And it didn't lead to clean up this table entry, as the ZC continues not to reply to the NwkAddrReq.

So for now I have no other solution. Does anyone have another idea to workaround this issue ?

Thanks,

BR

Mathias

Hi Mathias,

Device announce needs to be sent from the ZED or the new parent of the ZED in your case so that the association table in the former parent is updated properly.

How about sending device announce from the ZED before it broadcast NWKAddrReq?

- Cetri

Hi Cetri,

For sure it should have solve many issues but unfortunately I cannot change the behavior of the ZEDs or the ZRs (we are only developping the coordinator, and using end devices and routers from our today provider NetVox). 

I've had a new idea, looking at the thread of discussion "Help to remove child device from coordinator association list!!!"

what if I remove every RFD from AssociatedDevList at ZStack start ? doing something like this, for instance in osal_start_znp:

 for ( _nodeCounter = 0; _nodeCounter < NWK_MAX_DEVICES; _nodeCounter++ )
 {
 if ( (AssociatedDevList[_nodeCounter].nodeRelation == CHILD_RFD_RX_IDLE) || 
 (AssociatedDevList[_nodeCounter].nodeRelation == CHILD_RFD) ) 
 {
 // set up device info
 addrEntry.user = ADDRMGR_USER_DEFAULT;
 addrEntry.index = AssociatedDevList[_nodeCounter].addrIdx;
 AddrMgrEntryGet( &addrEntry );
      
 // Remove...
 AssocRemove( addrEntry.extAddr );
 } 
 }
 // and save changes on NV
 AssocWriteNV();

Ideally I would have preferred removing each RFD in the callback function associated to NwkAddrReq (zdpProcessAddrReq ?) but I'm not sure that this function is really invoked in my case, maybe due to the fact that this is a broadcast message ??

Doing this way may fit more specifically to my case, and may have less side effects ?

Mathias

Hi,
The solution I've proposed on Apr 25 gives a partial workaround to my problem: RFDs send report attribute to the coordinator, and reports are forwarded to the ZNP layer.
But if RFDs don't migrate to routers while the coordinator is stopped, the coordinator (which remains the peer in this case) is no more able to reach these nodes ("0xCD" status code in AF_DATA_CONFIRM message). So this is not acceptable...
Even if the RFD sends a DeviceAnnce, the situation is not restored: the coordinator receives the DeviceAnnce, it broadcasts it, and sends a RouteReq with the short address of the RFD node.
Of course the better solution would be to have a corrective patch (if any?) on broadcast messages. But I have to find a workaround in the meanwhile.
Does anyone have any suggestion ?
thx
BR
Mathias