WEBENCH® Tools/CC2652R: Issue: if coord receives any AF-packet when waiting APS ack, that will cause APS retry.

My test target is Silicon-labs's router, whoes zigbee stack will send aps ack after ZCL-response or ZDP-response

Hi Aries,

I am having difficulty replicating this setup in order to verify your findings but there is one point in the sniffer log that I'd like to clarify.  Are you confident that this is caused by the hop and not the fact that the bind response is returned before the APS ACK?  This is unexpected behavior and if the device requesting the bind is waiting for acknowledgement before processing the response this could explain why the retry is attempted.

Regards,
Ryan

The ZDP-Bind-Req command in TI's z-stack is an Aps-Ack-Enabled command, ZCL commands could also replicate this issue. The command target is based on Silabs‘s zigbee-system whose Aps-Ack is transmitted after ZDP or ZCL response-command，and the target must be at multihop from initiator. If the multihop Silabs's target not reply response command when receives a Aps-Ack enabled command from TI's initiator, the TI's initiator will not retry.

My CC2652R coordinator has output error-status "ZApsNoAck"(0xb7) by AF_DATA_CONFIRM_MSG when receives any AF data packet from target before receives its Aps-Ack.

I think it is only a issue about compatibility. Some othes chip factory think that the order of Response and APS ACK is not a matter. But in TI’s zigbee platform,  it will determine APS ACK failed if the order of Response an APS ACK is wrong.

Hi Aries,

After further investigation and acquiring a third-party device, I was able to reproduce the setup but not the behavior.  The only difference is that the TI devices are routers and the third-party device is the coordinator.  Please look through the comments in the attached sniffer log and let me know of any changes I should make to help recreate the issue.  https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/158/APS_5F00_ACK_5F00_after_5F00_Bind_5F00_Response_5F00_through_5F00_hop.cubx

Regards,
Ryan

To reproduce this issue must meet these conditions.

1，The TI devices send ZDP-Binding-Request  with APS-Ack-Request enabled to third-party device.

2，The third-party device must has bug that the ZDP-Response command is sent earlier than APS-Ack. (Silabs device).

3，The target device must be more than 1-hop from  TI devices.

I believe all of these conditions are met by my test setup as shown in the sniffer log, please clarify which you think is missing.

Regards,
Ryan

Yes, in your sniffer log, packet 404 is the binding-requst that is sent from Z-stack Device to Ember Device. But the packet is sent not path router.

If you could please look at packets 1426 through 1436 instead (the ones with comments) you will understand the communication I've been intending to reference.

Regards,
Ryan

Yes, I have test this issue again. It seems that this issue will appear when Source-Routing is enabled. In your example, Source-Routing is disabled. But in z-stack, how can I disable Source-Routing directly?

Disable MTO routing by setting CONCENTRATOR_ENABLE to false in zglobals.h

Regards,
Ryan

Now I have disabled Source Routing on coordinator, it will not trigger this issue when Response is multiple-hop transmitted. But it will be still triggered when Request is multiple-hop transmitted.