This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

  • TI Thinks Resolved

Linux/CC2531EMK: GW_SEND_ZCL_FRAME_REQ generated 802.15.4 ACK instead of sending a ZCL frame

Prodigy 120 points

Replies: 4

Views: 194

Part Number: CC2531EMK

Tool/software: Linux


I'm running the latest Z-Stack on a CC2531 USB stick, using the Zigbee 3.0 Node.js Linux Gateway.

When trying to send a ZCL frame using GW_SEND_ZCL_FRAME_REQ from the Node.js gateway, the message is correctly processed by the full stack down to the NPI server sending the command to the ZNP on the dongle. The ZNP returns a SUCCESS status, but it does not send the ZCL frame over the air. Instead, it sends an unrelated IEEE 802.15.4 ACK with an incremented sequence number.

  • This is a valid ZCL frame, with correct headers payload etc.
  • This is similar to a packet sent by the ZNP when responding to read_attribute request, that I saw over the air.
    • This is simply an AF_DATA_REQUEST of a ZCL payload with commandId 0x01 (READ_ATTRIBUTE_RESPONSE), of attribute 0x0005 in cluster 0x0000, with string value "N/A"
  • Debug logs from the original packet (read_attribute_response sent by the Z-stack) and from my GW_SEND_ZCL_FRAME_REQ are identical. The request is correctly processed, but the final OTA packet sent by the ZNP is completely wrong

What could cause the ZNP to silently reject a valid frame and generate a 802.15.4 Ack instead?

Here is the excerpt of the debugging information from the Z-Stack Linux Servers of the incriminated packet:

Sending GwSendZclFrameReq from Node.js application to servers

[21:51:01.288,601] [GATEWAY/LSTN] PKT_HEX: [                                    GATEWAY<<<<<<<<<<<CON006] [read] 33:00:13:1B:08:1B:12:0D:08:00:11:F6:EC:AB:14:00:4B:12:00:28:01:18:01:20:84:02:28:01:30:00:38:00:40:00:48:00:58:01:60:01:68:DD:01:70:01:7A:08:05:00:00:42:03:4E:2F:41
[21:51:01.288,666] [GATEWAY/LSTN] PKTTYPE: [                                    GATEWAY<<<<<<<<<<<CON006] GwSendZclFrameReq
[21:51:01.288,856] [GATEWAY/LSTN] PKTBODY:                                                          cmdId = GW_SEND_ZCL_FRAME_REQ
[21:51:01.288,900] [GATEWAY/LSTN] PKTBODY:                                                          dstAddress :
[21:51:01.289,017] [GATEWAY/LSTN] PKTBODY:                                                            addressType = UNICAST
[21:51:01.289,148] [GATEWAY/LSTN] PKTBODY:                                                            ieeeAddr = 00:12:4B:00:14:AB:EC:F6
[21:51:01.289,248] [GATEWAY/LSTN] PKTBODY:                                                            endpointId = 0x00000001 (1)
[21:51:01.289,371] [GATEWAY/LSTN] PKTBODY:                                                          endpointIdSource = 0x00000001 (1)
[21:51:01.289,414] [GATEWAY/LSTN] PKTBODY:                                                          profileId = 0x00000104 (260)
[21:51:01.289,605] [GATEWAY/LSTN] PKTBODY:                                                          qualityOfService = APS_ACK
[21:51:01.289,645] [GATEWAY/LSTN] PKTBODY:                                                          securityOptions = APS_SECURITY_DISABLED
[21:51:01.290,099] [GATEWAY/LSTN] PKTBODY:                                                          clusterId = 0x00000000 (0)
[21:51:01.290,148] [GATEWAY/LSTN] PKTBODY:                                                          frameType = FRAME_VALID_ACCROSS_PROFILE
[21:51:01.290,238] [GATEWAY/LSTN] PKTBODY:                                                          manufacturerSpecificFlag = NON_MFR_SPECIFIC
[21:51:01.290,385] [GATEWAY/LSTN] PKTBODY:                                                          clientServerDirection = SERVER_TO_CLIENT
[21:51:01.290,431] [GATEWAY/LSTN] PKTBODY:                                                          disableDefaultRsp = DEFAULT_RSP_DISABLED
[21:51:01.290,527] [GATEWAY/LSTN] PKTBODY:                                                          sequenceNumber = 0x000000DD (221)
[21:51:01.290,655] [GATEWAY/LSTN] PKTBODY:                                                          commandId = 0x00000001 (1)
[21:51:01.290,785] [GATEWAY/LSTN] PKTBODY:                                                          payload (hex string) = 05:00:00:42:03:4E:2F:41
[21:51:01.290,956] [GATEWAY/LSTN] MISC1  : Processing Send ZCL Frame Request

The request is correctly processed and passed down to Z-Stack

[21:51:01.294,872] [GATEWAY/LSTN] PKT_HEX: [                  Z_STACK<<<<<<<<<<<GATEWAY         ] [SREQ] 25:00:31:22:08:22:12:08:08:02:10:00:20:01:28:00:20:01:28:00:30:00:3A:02:10:01:40:1E:4A:0B:18:DD:01:05:00:00:42:03:4E:2F:41
[21:51:01.295,099] [GATEWAY/LSTN] PKTTYPE: [                  Z_STACK<<<<<<<<<<<GATEWAY         ] afDataReq
[21:51:01.295,194] [GATEWAY/LSTN] PKTBODY:                                                          cmdID = AF_DATA_REQ
[21:51:01.295,314] [GATEWAY/LSTN] PKTBODY:                                                          dstAddr :
[21:51:01.295,351] [GATEWAY/LSTN] PKTBODY:                                                            addrMode = SHORT
[21:51:01.295,390] [GATEWAY/LSTN] PKTBODY:                                                            shortAddr = 0x00000000 (0)
[21:51:01.295,461] [GATEWAY/LSTN] PKTBODY:                                                            endpoint = 0x00000001 (1)
[21:51:01.295,616] [GATEWAY/LSTN] PKTBODY:                                                            panID = 0x00000000 (0)
[21:51:01.295,667] [GATEWAY/LSTN] PKTBODY:                                                          srcEndpoint = 0x00000001 (1)
[21:51:01.295,703] [GATEWAY/LSTN] PKTBODY:                                                          clusterID = 0x00000000 (0)
[21:51:01.295,739] [GATEWAY/LSTN] PKTBODY:                                                          transID = 0x00000000 (0)
[21:51:01.295,772] [GATEWAY/LSTN] PKTBODY:                                                          options :
[21:51:01.295,811] [GATEWAY/LSTN] PKTBODY:                                                            ackRequest = 1
[21:51:01.295,896] [GATEWAY/LSTN] PKTBODY:                                                          radius = 0x0000001E (30)
[21:51:01.295,982] [GATEWAY/LSTN] PKTBODY:                                                          payload (hex string) = 18:DD:01:05:00:00:42:03:4E:2F:41

This is then passed down to NPISRVR and ultimately SOCZIGB

[21:51:01.297,083] [Z_STACK/LSTN] PKT_HEX: [         NPISRVR<<Z_STACK                           ] [SREQ] 1F:24:02:02:00:00:76:60:00:B0:76:28:01:00:00:01:00:00:00:10:1E:0B:00:18:DD:01:05:00:00:42:03:4E:2F:41
[21:51:01.297,218] [Z_STACK/LSTN] PKTTYPE: [         NPISRVR<<Z_STACK                           ] [SREQ] 1F:24:02:02:00:00:76:60:00:B0:76:28:01:00:00:01:00:00:00:10:1E:0B:00:18:DD:01:05:00:00:42:03:4E:2F:41

[21:51:01.299,293] [NPISRVR/MAIN] PKT_HEX: [SOCZIGB<<NPISRVR                                    ] [send] 1F:24:02:02:00:00:76:60:00:B0:76:28:01:00:00:01:00:00:00:10:1E:0B:00:18:DD:01:05:00:00:42:03:4E:2F:41

The ZNP on the CC2531 responds with a SUCCESS status:

[21:51:01.309,551] [NPISRVR/U_RX] PKT_HEX: [SOCZIGB>>NPISRVR                                    ] [SRSP] 01:64:02:00
[21:51:01.309,917] [NPISRVR/MAIN] PKT_HEX: [         NPISRVR>>Z_STACK                           ] [ucst] 01:64:02:00
[21:51:01.311,029] [Z_STACK/LSTN] PKT_HEX: [                  Z_STACK>>>>>>>>>>>GATEWAY         ] [ucst] 04:00:71:FA:08:22:10:00
[21:51:01.311,082] [Z_STACK/LSTN] PKTTYPE: [                  Z_STACK>>>>>>>>>>>GATEWAY         ] zstackDefaultRsp
[21:51:01.311,130] [Z_STACK/LSTN] PKTBODY:                                                          cmdID = AF_DATA_REQ
[21:51:01.311,166] [Z_STACK/LSTN] PKTBODY:                                                          status = ZSuccess
[21:51:01.311,611] [GATEWAY/LSTN] MISC1  : Sending ZigBee Generic Confirmation 
[21:51:01.311,776] [GATEWAY/LSTN] PKT_HEX: [                                    GATEWAY>>>>>>>>>>>CON006] [ucst] 04:00:73:00:08:00:10:00
[21:51:01.311,827] [GATEWAY/LSTN] PKTTYPE: [                                    GATEWAY>>>>>>>>>>>CON006] GwZigbeeGenericCnf
[21:51:01.311,867] [GATEWAY/LSTN] PKTBODY:                                                          cmdId = ZIGBEE_GENERIC_CNF
[21:51:01.311,905] [GATEWAY/LSTN] PKTBODY:                                                          status = STATUS_SUCCESS


  • Hum, let me rephrase the question.
    I'm aware there is a system in Z-Stack Linux to avoid sending frames with an incorrect sequenceId.
    If I were to bypath this system, is there a similar system in the ZNP to avoid sending packets with an incorrect Zigbee sequence ID ?
    Would this system silently drop such packets?

  • In reply to Julien Le Guen:

    Hi Julien,

    Do you have a sniffer log of the offending IEEE 802.15.4 ACK packet? Are you able to debug the CC2531 ZNP MT_AfDataRequest() function? I would have expected the AF_DataRequest() to return a failed status due to incorrect parameter values. That being said, the user is allowed to set their own transaction sequence number at the ZCL layer. Perhaps your sniffer is confused due to the packet header.


    To better aid the community, please click on the "This Resolved my issue" button whenever a post answers your question!

  • In reply to Ryan Brown1:

    Hi Ryan,

    Here is a screenshot of my sniffer. I'm sure I don't lose any packet, there is no other traffic on the frequency.

    Instead of having a full ZCL Read_attribute_response packet I crafted, I just have the 802.15.4 Ack '02 00 0a e2 1a'

    I'm aware that there is a transaction Id that the user can set in the ZCL frame, but here I'm talking about the network sequence Id.
    What happens at the ZNP level if I'm trying to send a packet with a network sequence Id which does not make sense in the current context?

    I'm on the CC2531 usb dongle on a raspberryPi, I'm not aware of how to run a debugger on the ZNP.

    It returns a SUCCESS status (cf. the frame "01:64:02:00" from the ZNP which indicates a successful AF_DATA_REQ_EXT)

    Thank you for your help!

  • In reply to Julien Le Guen:

    Hi Julien,

    There are no checks inside of AF_DataRequest to prevent the message from being passed to APSDE_DataReq and returning ZSuccess but the AF_DATA_REQUEST is not populated with the correct information to send the ZCL frame to the target destination (short address/PanID of 0, endpoints of 1, etc). This is most likely an addressing issue which you need to correct.

    You can debug the CC2531EMK with a CC-DEBUGGER.  Also, please refer to the following Firmware/README note:

    To use Zigbee Linux Gateway 3.0 with CC2531-GW-ZNP, please disable the flag SKIP_BOOTLOADER_VALIDATION and compile the all the Linux servers, as this device must support the bootloader initialization performed by the gateway host.


    To better aid the community, please click on the "This Resolved my issue" button whenever a post answers your question!

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.