RE: CC2538-CC2592EMK: Router sending leave request to end device.

Turned this into a new post, please provide the sniffer log (previous attachment was corrupted/missing) and remind me what Stack you are using for the ZC and ZED.

Regards,
Ryan

data req orphan rejoin req rejoin resp leave.rar

z-stack 3.0 for ZNP and ZR (cc2538-cc2592emk)

Z-stack 1.2.2a for  ZED (cc2650)

If BDB_DEFAULT_TC_REQUIRE_KEY_EXCHANGE is defined as true (default) then the end device is being requested to leave since no TC Link Key update procedure is initiated by the end device upon joining. The timeout for which this must occur is determined by BDB_DEFAULT_TC_REQUIRE_KEY_EXCHANGE. This is most likely not an issue since the device was successfully on the network before.

There are several MAC ACKs missing and difficulty between the ZC and ZED communicating as shown by the multiple rejoin requests followed by a 25s delay before the rejoin response. The data polls cease during this time, what timeout values are used? Compare this to the last time (32041, 32046) which showed a valid MAC ACK only took half a second for association, the packets are the exact same in both instances and yet a device announce immediately followed instead of a leave request. There appears to be difficulty in communicating between devices.

Regards,
Ryan

"The data polls cease during this time, what timeout values are used?"

1) what do you mean by data poll cease ?
2) which timeout values you are asking about?

I feel that there are too many packets missing to properly evaluate this issue. What I can guess is that the rejoin response is not acknowledged, causing the parent to send a leave request instead of device announce. Your network retry settings can help determine why the rejoin response is only attempted once.

Regards,
Ryan

1) you mean to say that after rejoin response ZED is not sending device announcement hence ZC is sending leave request?
2) how can I verify network retry setting?
3) this issue I have observed mainly with MTO routing

1) ZED is not acknowledging rejoin response, coordinator sends the device announce.
2) f8wConfig.cfg, nwk_globals.h, ZGlobals.h
3) We've discussed MTO routing in your other posts.

Regards,
Ryan

Network retry settings are as shown below -

-DAPSC_MAX_FRAME_RETRIES=5
MAX_POLL_FAILURE_RETRIES 1
MAX_DATA_RETRIES 2
MAX_BCAST_RETRIES 2

what modification should i do ??

Since Rejoin Response is not an APS packet, poll, or broadcast I would suggest trying MAX_DATA_RETRIES. But you need to figure out why your ZED is not acknowledging. Can you provide new or refreshed sniffer logs? Why does the link status of your ZC not have any list entries?

Regards,
Ryan

I have some observations during testing-
1) sometime it happens that packet is transmitted but disappears in air or not demodulated by receiving devices , this can be possibility that ZED is not acknowledging.But is it desired that if rejoin response is not acknowledged by ZED then ZR/ZC will send leave request?
2) Also during rejoin if ZED sends rejoin request to any router other then its previous PARENT ROUTER then the new router will send leave request with rejoin true.
3) Link status contains only routers in the list entries-and in 72EC pan there is no router only zc and zed