CSA Certification Issues for ZBOSS 3.11.4.0 End Devices

We wanted to share our feedback as we recently went through Zigbee 3.0.1 BDB/cluster certification using the ZBOSS with our end device product. While we were ultimately able to meet the CSA's requirements for certification, we faced a large number of issues with the example use of the stack that proved to be non-certifiable, despite the ZBOSS platform being 'certification ready' for Zigbee.

Our hope is that these issues are addressed internally within the NCS + ZBOSS Zigbee components in order to reduce friction for other developers (and us, in the future) when trying to bring a Zigbee product to market with Nordic.

Immediate Post-OTA Validation (OTA Client Cluster)

The Zigbee spec lays out (11.13.9.3):

If the image fails any integrity checks, the client SHALL send an Upgrade End Request command to the
upgrade server with a status of INVALID_IMAGE. In this case, the client MAY reinitiate the upgrade
process in order to obtain a valid OTA upgrade image. The client SHALL not upgrade to the bad image and
SHALL discard the downloaded image data.

In our application, we use OTA via the NRF SDK Zigbee FOTA library with MCUboot as the underlying bootloader. Since our images are signed for MCUboot, we will always inherently reject bad images and discard them, as expected. However, the stack does not manage the INVALID_IMAGE response, which is explicitly mandated by the CSA test cases around OTA. Since MCUboot does not provide an effective pathway for user-space validation of the OTA image, the most straightforward response to this is to download the image, reset into MCUboot to confirm the image is valid, then boot back and send an INVALID_IMAGE or OK response accordingly. However, since resetting would cause a disconnect from the Zigbee network, this is hard to do in a timely fashion + it is not clear if this would actually successfully pass the CSA test cases.

Our solution for this was to implement user-space validation for MCUboot images, where we decrypt/validate the image payload from the app space, which requires importing the signing/encryption keys into the app and duplicating many of the responsibilities from MCUboot. This is not a trivial solution - ideally, we would be able to call into MCUboot from the app space in the worst case to re-use the existing validation logic, rather than repeating it from the app space. The complication involved in this flow, unless there's a better solution that we are unaware of, greatly complicates one's ability to certify the OTA client cluster with ZBOSS + NCS. 

FOTA Endpoint Restriction

The Zigbee FOTA implementation is restricted to a single endpoint, which is reserved and may only be used for the OTA client implementation. While this isn't against any spec, it does provide complication layers that we have found during product introduction. Namely, the testing software + harnesses established by the CSA are primarily designed around single-endpoint tests, and switching endpoints for OTA tests versus product functional tests proved to be a complicated communication barrier between our engineers + the test lab. Further, our Zigbee controller partners in the industry have provided us direct feedback that the multiple endpoint design for OTA is causing customers to have slower experiences during pairing / discovery of our Zigbee device, due to the additional endpoint discovery required.

This is a limitation explicitly called out in the documentation, but it isn't extremely transparent to end device developers, so we thought it was important to highlight since there were noticable caveats that arose during product certification and field trial. We will likely overcome this limitation by patching the FOTA system to enable better access to the FOTA endpoint.

Resetting Attribute State on Leave

The Zigbee BDB 3.0.1 spec defines (9.4):

Zigbee-PRO provides an Mgmt_Leave_req ZDO command which is designed to request that a remote node leaves the network by clearing all Zigbee persistent data (see sub-clause 6.9), except the outgoing NWK frame counter, and perform a reset such that the node is in much the same state as it was when it left the factory.

In our findings, a leave request does not trigger a wipe of persistent data, because some amount of data is cached in memory. While NVRAM writes are performed to wipe the network / attribute state as expected, and the network disconnects immediately, attribute state is still generally preserved in memory, allowing those values to carry over to a new network if the device is re-paired without power cycling. This causes the device to explicitly fail CSA's test suite, which specifically tests configuring a reporting interval on an attribute, sending a leave request, re-pairing, and testing to ensure the reporting interval is the default value, not the one previously configured. The sample applications handling the ZB_ZDO_SIGNAL_LEAVE signal do not demonstrate any need to reboot the system, causing the device to fail the CSA test cases (the default signal handler merely starts joining a new network upon leaving, without any reset).

Our workaround for this issue was simply to trigger a full factory reset + power cycle the DUT when we receive the appropriate leave signal (Mgmt_Leave_req with rejoin = false).

NWK_addr_req Extended Response

When configured as an end device, it seems that calls to NWK_addr_req with RequestType = Extended Response flag set are not well-handled. The specification does not clearly indicate the defined behavior when handling this request as an end device, only for coordinators and routers, in section 2.4.3.1.1.2:

If the RequestType was Extended response and the Remote Device is either the ZigBee coordinator or router, a NWK_addr_resp command shall be generated and sent back ...

As such, the expected behavior to respond to this command in this instance is not clear. However, we found that the CSA test cases test this behavior (end device receiving NWK_addr_req with extended request set) and failed our DUT. Seemingly, the stack behavior is to respond to NWK_addr_req with RequestType=Extended in the same way that it would respond if RequestType=Single Device, rather than throwing an error for an unsupported argument or otherwise handling the behavior. This caused an error in the CSA test executor as it tried to unpack a shortened, single device response as a longer, extended response, where the test was really not expecting a response in the first place. I am not clear if this is an explicit issue with the ZBOSS implementation, or a short-sided mistake in the test development from the CSA's perspective, but in any case, it did not pass this test and we had to receive a special exemption from the CSA to allow certifying this result. Since this behavior is contained within the ZBOSS stack, we did not have much surface area for a possible resolution on our side.

Access to standard ZBOSS PICS descriptors

One of the requirements for filing CSA certification is a collection of PICS files that describes fundamental behavior of the product + its networking behavior. While some of these aspects are user-controlled (e.g. which + how much of a cluster was implemented), some of the PICS files (especially the BDB 3.0.1 definition) rely on a lot of information that is internal to the ZBOSS stack and not user-facing. While many of the required PICS questions can be answered with testing + analysis of the Zigbee stack, we would expect that the NCS + ZBOSS certifiable implementation would provide basic information of the stack internals to fill out the PICS requirements plainly. We have found that other chipset manufacturers have provided detailed information about what PICS need to be filled out, and how to fill it out respective to their stack implementations. This can greatly reduce the amount of noise involved in approaching certification, since many of the nuanced questions are transferrable ZBOSS details that apply in all cases of implementation.

The issues listed above caused great friction with our test lab + with the CSA certification process, which was unexpected during final development and complicated our product timelines. Many of these issues are subtle and hard to catch until final certification is happening, which makes them especially poignant during the development process with ZBOSS.

Parents Reply
  • > We are using tests provided by DSR and test towards the specification, so our devices should follow the specifications set by DSR.

    While this may be the case, DSR is not (solely) the certifying body for Zigbee. The test cases available directly from the CSA and executed by CSA's ZUTH tool, which are the mandatory executions for Zigbee 3.0.1 certification, do not pass this test, whereas other Zigbee platforms like EmberZNet do. As mentioned, we had to receive an exemption from the CSA to bypass this requirement.

    > The ZBOSS PICS are available to download on CSA's webpage, where our SoCs are listed

    My understanding is that these PICS are the platform certification PICs, however they do not cover the full scope of questions required to be answered for the end-device certification PICs using the ZBOSS platform. Other vendors have both sample end device PICs as well as the published platform PICs available. This is a minor ask, since the PICs are not terribly difficult to figure out, but having official documentation for an expected certification pathway would be valuable.

Children
  • Hi,

    Can you provide more information about the exact tests that failed, what software was used, and upload logs if you have any so we can investigate?

    If there is any information you do not wish to share in a public ticket, you can either create a new private ticket with the information and refer to this ticket, or I can make this ticket private. Please let me know what you prefer if this is relevant.

    Best regards,
    Marte

  • Marte,

    Here are some example failing test cases that we found, relating to issues mentioned above. All testing was performed using CSA's ZUTH software v3.1.20240514. The specific test hash is included in the log header of each submission.

    OTA Validation

    OTA-TC-10C - Cryptographically invalid file OTA; failed due to not receiving invalid response from DUT, resolved with user-space OTA validation as per above.

    2024-08-20 17:31:16:442 | INFO | *******************Start test script : OTA-TC-10C.py*******************
    2024-08-20 17:31:16:443 | INFO | Script Version: 4:2:20230710:provisional
    2024-08-20 17:31:16:443 | INFO | User Tag: 3.1.20240514
    2024-08-20 17:31:16:443 | INFO | Hash Tag: e85b3d3bafdf26fb6182a3d19ffce1d9f5f022e0
    2024-08-20 17:31:16:443 | INFO | ===== HOST SYSTEM DETAILS =====
    2024-08-20 17:31:16:444 | INFO | Architecture: 64bit
    2024-08-20 17:31:16:444 | INFO | Machine     : AMD64
    2024-08-20 17:31:16:445 | INFO | System      : Windows
    2024-08-20 17:31:16:445 | INFO | Version     : 10.0.22621
    2024-08-20 17:31:16:446 | INFO | ===============================
    2024-08-20 17:31:21:058 | INFO | ++++++++ Step 1-3b ++++++++
    2024-08-20 17:31:21:059 | INFO | TH SERVER shall be informed of the NULL upgrade file for the OTA client indicating that it is the next upgrade file for the corresponding manufacturer ID and Image Type ID. This shall be done via a manufacturer specific process
    2024-08-20 17:31:21:076 | INFO | TH : TX | plugin test-harness z3 ota-server activate 0x4C76 5 0x127F 0x0141 0x03020007 0x000B476D
    2024-08-20 17:31:21:078 | PROMPT | Waiting for the QueryNextImageRequest command : 4200 seconds
    2024-08-20 17:31:21:095 | SERIAL_RX | TH : RX | 'ZigbeeTH>TestHarnessZ3: Ota Server activate: 0x01'
    2024-08-20 17:31:25:228 | SERIAL_RX | TH : RX | 'ZigbeeTH>APS header: fc 40 grp 0000 dst_ep 01 clst 0019 pfl 0104 src_ep 05 seq 82'
    2024-08-20 17:31:25:228 | SERIAL_RX | TH : RX | ''
    2024-08-20 17:31:25:231 | SERIAL_RX | TH : RX | 'T0000012D:RX len 14, ep 01, clus 0x0019 (Over the Air Bootloading) FC 01 seq 04 cmd 01 payload[01 7F 12 41 01 06 00 02 03 34 00 ]'
    2024-08-20 17:31:25:231 | INFO | TH : RX | Rcvd Frame = T0000012D:RX len 14, ep 01, clus 0x0019 (Over the Air Bootloading) FC 01 seq 04 cmd 01 payload[01 7F 12 41 01 06 00 02 03 34 00 ]
    2024-08-20 17:31:25:232 | DEBUG | str dict: {'endpoint': 1, 'cluster_code': 25, 'FC': 1, 'sequence': 4, 'command_id': 1, 'payload': '01 7F 12 41 01 06 00 02 03 34 00'} 
    2024-08-20 17:31:25:237 | EXPECT | QueryNextImageRequest: | PASS
    2024-08-20 17:31:25:239 | PROMPT | Waiting for the response : 60 seconds
    2024-08-20 17:31:25:525 | INFO | TH : RX | Rcvd Frame = T0000012D:RX len 27, ep 01, clus 0x0019 (Over the Air Bootloading) FC 01 seq 05 cmd 03 payload[03 7F 12 41 01 07 00 02 03 00 00 00 00 40 48 E7 17 0B 59 36 CE F4 00 00 ]
    2024-08-20 17:31:25:526 | DEBUG | str dict: {'endpoint': 1, 'cluster_code': 25, 'FC': 1, 'sequence': 5, 'command_id': 3, 'payload': '03 7F 12 41 01 07 00 02 03 00 00 00 00 40 48 E7 17 0B 59 36 CE F4 00 00'} 
    2024-08-20 17:31:25:527 | INFO | TH : TX | raw 0x0019 { 19 05 05 00 7f 12 41 01 07 00 02 03 00 00 00 00 3f 1e f1 ee 0b 00 01 38 00 00 00 7f 12 41 01 07 00 02 03 02 00 0b 45 63 68 6f 5f 5a 69 67 62 65 65 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6d 47 0b 00 00 00 2f 47 0b 00 15 }
    2024-08-20 17:31:25:529 | PROMPT | Waiting for the response : 60 seconds
    
    ...
    
    2024-08-20 19:21:13:914 | INFO | TH : RX | Rcvd Frame = T00001A9E:RX len 27, ep 01, clus 0x0019 (Over the Air Bootloading) FC 01 seq DD cmd 03 payload[03 7F 12 41 01 07 00 02 03 6B 47 0B 00 40 48 E7 17 0B 59 36 CE F4 00 00 ]
    2024-08-20 19:21:14:034 | DEBUG | str dict: {'endpoint': 1, 'cluster_code': 25, 'FC': 1, 'sequence': 221, 'command_id': 3, 'payload': '03 7F 12 41 01 07 00 02 03 6B 47 0B 00 40 48 E7 17 0B 59 36 CE F4 00 00'} 
    2024-08-20 19:21:14:183 | INFO | TH : TX | raw 0x0019 { 19 DD 05 00 7f 12 41 01 07 00 02 03 6b 47 0b 00 02 74 ca }
    2024-08-20 19:21:14:311 | PROMPT | Waiting for the response : 60 seconds
    2024-08-20 19:21:14:580 | INFO | TH : RX | Rcvd Frame = T00001A9F:RX len 12, ep 01, clus 0x0019 (Over the Air Bootloading) FC 01 seq DE cmd 06 payload[00 7F 12 41 01 07 00 02 03 ]
    2024-08-20 19:21:14:694 | DEBUG | str dict: {'endpoint': 1, 'cluster_code': 25, 'FC': 1, 'sequence': 222, 'command_id': 6, 'payload': '00 7F 12 41 01 07 00 02 03'} 
    2024-08-20 19:21:14:816 | EXPECT | UpgradeEndRequest received with correct status = 0x96 | FAIL
    2024-08-20 19:21:14:930 | INFO | TH : TX | plugin test-harness z3 ota-server deactivate
    2024-08-20 19:21:15:135 | ERROR | Cryptographically invalid image file downloading failed, line = 88
    2024-08-20 19:21:15:136 | SERIAL_RX | TH : RX | 'TestHarnessZ3: Ota Server Deactivate: 0x00'
    2024-08-20 19:21:15:259 | EXPECT | Cryptographically invalid image file downloading | FAIL
    2024-08-20 19:21:15:500 | VERDICT | Step 1-3b | FAIL
    

    Mgmt_Leave_req

    DR-TAR-TC-03B - configured reporting then sent leave with no rejoin; upon re-pairing to the network, the reporting value had not been reset due to in-memory cached state of ZBOSS configurables. Manually resolved by power cycle on leave.

    2024-08-18 04:30:25:656 | INFO | *******************Start test script : DR-TAR-TC-03B.py*******************
    2024-08-18 04:30:25:656 | INFO | Script Version: BDB3.0.1:1:20221209:draft
    2024-08-18 04:30:25:657 | INFO | User Tag: 3.1.20240514
    2024-08-18 04:30:25:657 | INFO | Hash Tag: e85b3d3bafdf26fb6182a3d19ffce1d9f5f022e0
    2024-08-18 04:30:25:657 | INFO | ===== HOST SYSTEM DETAILS =====
    2024-08-18 04:30:25:667 | INFO | Architecture: 64bit
    2024-08-18 04:30:25:668 | INFO | Machine     : x86_64
    2024-08-18 04:30:25:668 | INFO | System      : Linux
    2024-08-18 04:30:25:669 | INFO | Version     : #46~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Jun 7 15:06:04 UTC 20
    2024-08-18 04:30:25:669 | INFO | ===============================
    ...
    2024-08-18 04:32:09:625 | INFO | ++++++++ Step P4 ++++++++
    2024-08-18 04:32:09:628 | INFO | Sending ReadReportingConfigurtation to discover default values for the reportable attribute provided in PIXIT
    2024-08-18 04:32:09:631 | INFO | THc1 : TX | custom lookup {f4ce3673080d0fc0}
    2024-08-18 04:32:09:653 | SERIAL_RX | THc1 : RX | 'shortaddress:0xD3CB'
    2024-08-18 04:32:10:135 | INFO | THc1 : RX | Rcvd Frame = shortaddress:0xD3CB
    2024-08-18 04:32:10:137 | DEBUG | strResponse:shortaddress:0xD3CB
    2024-08-18 04:32:10:139 | INFO | Short address of device :<< 0xD3CB >>
    2024-08-18 04:32:10:308 | INFO | THc1 : TX | raw 0x0101 { 00 04 08 00 00 00 }
    2024-08-18 04:32:10:309 | INFO | THc1 : TX | send 0xD3CB 0x01 0x0A
    2024-08-18 04:32:10:310 | PROMPT | Waiting for the ReadReportingConfigurationResponse command : 20 seconds
    2024-08-18 04:32:10:328 | SERIAL_RX | THc1 : RX | 'ZigbeeTH>Msg: clus 0x0101, cmd 0x08, len 6'
    2024-08-18 04:32:10:329 | SERIAL_RX | THc1 : RX | 'buffer: 00 04 08 00 00 00 '
    2024-08-18 04:32:13:913 | SERIAL_RX | THc1 : RX | 'ZigbeeTH>APS header: fc 40 grp 0000 dst_ep 01 clst 0101 pfl 0104 src_ep 0A seq 0C'
    2024-08-18 04:32:13:917 | SERIAL_RX | THc1 : RX | ''
    2024-08-18 04:32:13:937 | SERIAL_RX | THc1 : RX | 'T00000068:RX len 12, ep 01, clus 0x0101 (Door Lock) FC 18 seq 04 cmd 09 payload[00 00 00 00 30 05 00 00 00 ]'
    2024-08-18 04:32:13:941 | INFO | THc1 : RX | Rcvd Frame = T00000068:RX len 12, ep 01, clus 0x0101 (Door Lock) FC 18 seq 04 cmd 09 payload[00 00 00 00 30 05 00 00 00 ]
    2024-08-18 04:32:13:946 | DEBUG | str dict: {'endpoint': 1, 'cluster_code': 257, 'FC': 24, 'sequence': 4, 'command_id': 9, 'payload': '00 00 00 00 30 05 00 00 00'} 
    2024-08-18 04:32:14:328 | SERIAL_RX | THr1 : RX | 'beacon-req:rx'
    2024-08-18 04:32:14:729 | SERIAL_RX | THc1 : RX | 'beacon-req:rx'
    2024-08-18 04:32:14:835 | EXPECT | THc1: ReadReportingConfigurationResponse: Cluster 0x0101, Attribute 0x0000 | PASS
    2024-08-18 04:32:14:837 | INFO | DEFAULT MinimumReportingInterval : 5 and MaximumReportingInterval : 0
    2024-08-18 04:32:14:837 | INFO | DEFAULT MinimumReportingInterval : (5) and MaximumReportingInterval : (0)
    2024-08-18 04:32:14:838 | INFO | NON DEFAULT MinimumReportingInterval = 6
    2024-08-18 04:32:14:839 | INFO | Range limit reached
    2024-08-18 04:32:14:839 | INFO | NON DEFAULT MinimumReportingInterval = 10
    2024-08-18 04:32:14:840 | INFO | Sending ConfigureReporting to assign different min and max intervals for reportable attribute provided in PIXIT
    2024-08-18 04:32:14:840 | INFO | THc1 : TX | custom lookup {f4ce3673080d0fc0}
    2024-08-18 04:32:14:856 | SERIAL_RX | THc1 : RX | 'shortaddress:0xD3CB'
    2024-08-18 04:32:15:342 | INFO | THc1 : RX | Rcvd Frame = shortaddress:0xD3CB
    2024-08-18 04:32:15:346 | DEBUG | strResponse:shortaddress:0xD3CB
    2024-08-18 04:32:15:350 | INFO | Short address of device :<< 0xD3CB >>
    2024-08-18 04:32:15:510 | INFO | THc1 : TX | raw 0x0101 { 00 05 06 00 00 00 30 06 00 0a 00 }
    2024-08-18 04:32:15:512 | INFO | THc1 : TX | send 0xD3CB 0x01 0x0A
    2024-08-18 04:32:15:513 | PROMPT | Waiting for the ConfigureReportingResponse command : 20 seconds
    2024-08-18 04:32:15:531 | SERIAL_RX | THc1 : RX | 'ZigbeeTH>Msg: clus 0x0101, cmd 0x06, len 11'
    2024-08-18 04:32:15:533 | SERIAL_RX | THc1 : RX | 'buffer: 00 05 06 00 00 00 30 06 00 0A 00 '
    2024-08-18 04:32:15:616 | SERIAL_RX | THc1 : RX | 'ZigbeeTH>APS header: fc 40 grp 0000 dst_ep 01 clst 0101 pfl 0104 src_ep 0A seq 0D'
    2024-08-18 04:32:15:618 | SERIAL_RX | THc1 : RX | ''
    2024-08-18 04:32:15:631 | SERIAL_RX | THc1 : RX | 'T0000006A:RX len 19, ep 01, clus 0x0101 (Door Lock) FC 19 seq 06 cmd 20 payload[02 0D FF 00 FF 00 00 00 FF 00 00 00 07 00 00 00 ]'
    2024-08-18 04:32:15:724 | SERIAL_RX | THc1 : RX | 'APS header: fc 40 grp 0000 dst_ep 01 clst 0101 pfl 0104 src_ep 0A seq 0E'
    2024-08-18 04:32:15:735 | SERIAL_RX | THc1 : RX | ''
    2024-08-18 04:32:15:738 | SERIAL_RX | THc1 : RX | 'T0000006A:RX len 4, ep 01, clus 0x0101 (Door Lock) FC 18 seq 05 cmd 07 payload[00 ]'
    2024-08-18 04:32:15:740 | INFO | THc1 : RX | Rcvd Frame = T0000006A:RX len 4, ep 01, clus 0x0101 (Door Lock) FC 18 seq 05 cmd 07 payload[00 ]
    2024-08-18 04:32:15:740 | DEBUG | str dict: {'endpoint': 1, 'cluster_code': 257, 'FC': 24, 'sequence': 5, 'command_id': 7, 'payload': '00'} 
    2024-08-18 04:32:16:355 | EXPECT | THc1: ConfigureReportingResponse: Cluster 0x0101, Attribute 0x0000 | PASS
    2024-08-18 04:32:16:356 | INFO | Sending ReadReportingConfigurtation to discover default values for the reportable attribute provided in PIXIT
    2024-08-18 04:32:16:356 | INFO | THc1 : TX | custom lookup {f4ce3673080d0fc0}
    2024-08-18 04:32:16:375 | SERIAL_RX | THc1 : RX | 'shortaddress:0xD3CB'
    2024-08-18 04:32:16:858 | INFO | THc1 : RX | Rcvd Frame = shortaddress:0xD3CB
    2024-08-18 04:32:16:862 | DEBUG | strResponse:shortaddress:0xD3CB
    2024-08-18 04:32:16:866 | INFO | Short address of device :<< 0xD3CB >>
    2024-08-18 04:32:17:041 | INFO | THc1 : TX | raw 0x0101 { 00 06 08 00 00 00 }
    2024-08-18 04:32:17:043 | INFO | THc1 : TX | send 0xD3CB 0x01 0x0A
    2024-08-18 04:32:17:044 | PROMPT | Waiting for the ReadReportingConfigurationResponse command : 20 seconds
    2024-08-18 04:32:17:063 | SERIAL_RX | THc1 : RX | 'ZigbeeTH>Msg: clus 0x0101, cmd 0x08, len 6'
    2024-08-18 04:32:17:067 | SERIAL_RX | THc1 : RX | 'buffer: 00 06 08 00 00 00 '
    2024-08-18 04:32:18:770 | SERIAL_RX | THc1 : RX | 'ZigbeeTH>APS header: fc 40 grp 0000 dst_ep 01 clst 0101 pfl 0104 src_ep 0A seq 0E'
    2024-08-18 04:32:18:772 | SERIAL_RX | THc1 : RX | ''
    2024-08-18 04:32:18:785 | SERIAL_RX | THc1 : RX | 'T0000006D:RX len 4, ep 01, clus 0x0101 (Door Lock) FC 18 seq 05 cmd 07 payload[00 ]'
    2024-08-18 04:32:19:087 | SERIAL_RX | THc1 : RX | 'APS header: fc 40 grp 0000 dst_ep 01 clst 0101 pfl 0104 src_ep 0A seq 0F'
    2024-08-18 04:32:19:090 | SERIAL_RX | THc1 : RX | ''
    2024-08-18 04:32:19:111 | SERIAL_RX | THc1 : RX | 'T0000006D:RX len 12, ep 01, clus 0x0101 (Door Lock) FC 18 seq 06 cmd 09 payload[00 00 00 00 30 06 00 0A 00 ]'
    2024-08-18 04:32:19:117 | INFO | THc1 : RX | Rcvd Frame = T0000006D:RX len 12, ep 01, clus 0x0101 (Door Lock) FC 18 seq 06 cmd 09 payload[00 00 00 00 30 06 00 0A 00 ]
    2024-08-18 04:32:19:122 | DEBUG | str dict: {'endpoint': 1, 'cluster_code': 257, 'FC': 24, 'sequence': 6, 'command_id': 9, 'payload': '00 00 00 00 30 06 00 0A 00'} 
    2024-08-18 04:32:20:159 | EXPECT | THc1: ReadReportingConfigurationResponse: Cluster 0x0101 Attribute 0x0000 | PASS
    2024-08-18 04:32:20:159 | SERIAL_RX | THc1 : RX | 'beacon-req:rx'
    2024-08-18 04:32:20:160 | VERDICT | Step P4 | PASS
    
    2024-08-18 04:32:20:161 | SERIAL_RX | THr1 : RX | 'beacon-req:rx'
    2024-08-18 04:32:20:162 | INFO | ++++++++ Step 1 ++++++++
    2024-08-18 04:32:20:164 | INFO | THc1 is triggered to send to the DUT the NWK Leave command
    2024-08-18 04:32:20:164 | INFO | THc1 : TX | custom lookup {f4ce3673080d0fc0}
    2024-08-18 04:32:20:182 | SERIAL_RX | THc1 : RX | 'shortaddress:0xD3CB'
    2024-08-18 04:32:20:666 | INFO | THc1 : RX | Rcvd Frame = shortaddress:0xD3CB
    2024-08-18 04:32:20:668 | DEBUG | strResponse:shortaddress:0xD3CB
    2024-08-18 04:32:20:670 | INFO | Short address of device :<< 0xD3CB >>
    2024-08-18 04:32:20:810 | INFO | THc1 : TX | plugin test-harness z3 nwk nwk-leave 0 1 0 0xD3CB 0
    2024-08-18 04:32:20:907 | INFO | DUT MAY broadcast a network leave command
    2024-08-18 04:32:20:907 | SERIAL_RX | THc1 : RX | 'ZigbeeTH>TestHarnessZ3: Leave: 0x00'
    2024-08-18 04:32:20:908 | PROMPT | Waiting for the Leave command : 20 seconds
    2024-08-18 04:33:01:106 | EXPECT | THc1: NWK: No Rejoin request {xx} | PASS
    2024-08-18 04:33:01:107 | VERDICT | Step 1 | PASS
    
    2024-08-18 04:33:01:107 | INFO | ++++++++ Step 2a ++++++++
    2024-08-18 04:33:01:108 | INFO | Network steering is triggered on THr1
    2024-08-18 04:33:05:743 | VERDICT | Step 2a | PASS
    
    2024-08-18 04:33:05:743 | INFO | ++++++++ Step 2b ++++++++
    2024-08-18 04:33:18:355 | VERDICT | Step 2b | PASS
    
    ...
    
    2024-08-18 04:33:25:938 | INFO | ++++++++ Step 3d ++++++++
    2024-08-18 04:33:25:938 | INFO | Sending ReadReportingConfiguration for reportable attribute configured in PIXIT
    2024-08-18 04:33:25:939 | INFO | THr1 : TX | custom lookup {f4ce3673080d0fc0}
    2024-08-18 04:33:25:959 | SERIAL_RX | THr1 : RX | 'shortaddress:0xA70B'
    2024-08-18 04:33:26:440 | INFO | THr1 : RX | Rcvd Frame = shortaddress:0xA70B
    2024-08-18 04:33:26:442 | DEBUG | strResponse:shortaddress:0xA70B
    2024-08-18 04:33:26:443 | INFO | Short address of device :<< 0xA70B >>
    2024-08-18 04:33:26:608 | INFO | THr1 : TX | raw 0x0101 { 00 01 08 00 00 00 }
    2024-08-18 04:33:26:610 | INFO | THr1 : TX | send 0xA70B 0x01 0x0A
    2024-08-18 04:33:26:612 | PROMPT | Waiting for the ReadReportingConfigurationResponse command : 20 seconds
    2024-08-18 04:33:26:629 | SERIAL_RX | THr1 : RX | 'ZigbeeTH>Msg: clus 0x0101, cmd 0x08, len 6'
    2024-08-18 04:33:26:630 | SERIAL_RX | THr1 : RX | 'buffer: 00 01 08 00 00 00 '
    2024-08-18 04:33:26:743 | SERIAL_RX | THr1 : RX | 'ZigbeeTH>APS header: fc 40 grp 0000 dst_ep 01 clst 0101 pfl 0104 src_ep 0A seq 13'
    2024-08-18 04:33:26:745 | SERIAL_RX | THr1 : RX | ''
    2024-08-18 04:33:26:747 | SERIAL_RX | THr1 : RX | 'T000000AD:RX len 12, ep 01, clus 0x0101 (Door Lock) FC 18 seq 01 cmd 09 payload[00 00 00 00 30 06 00 0A 00 ]'
    2024-08-18 04:33:26:748 | INFO | THr1 : RX | Rcvd Frame = T000000AD:RX len 12, ep 01, clus 0x0101 (Door Lock) FC 18 seq 01 cmd 09 payload[00 00 00 00 30 06 00 0A 00 ]
    2024-08-18 04:33:26:749 | DEBUG | str dict: {'endpoint': 1, 'cluster_code': 257, 'FC': 24, 'sequence': 1, 'command_id': 9, 'payload': '00 00 00 00 30 06 00 0A 00'} 
    2024-08-18 04:33:27:659 | ERROR | THr1: ReadReportingConfigurationResponse: Incorrect MinimumReportingInterval for attrId = 0x0000, Expected = 5, Received = 6, line = 398
    2024-08-18 04:33:27:770 | ERROR | THr1: ReadReportingConfigurationResponse: Incorrect MaximumReportingInterval for attrId = 0x0000, Expected = 0, Received = 10, line = 398
    2024-08-18 04:33:27:771 | EXPECT | THr1: ReadReportingConfigurationResponse: Cluster 0x0101 Attribute 0x0000 | FAIL
    2024-08-18 04:33:27:771 | VERDICT | Step 3d | FAIL 
    

    NWK_addr_req

    FB-PRE-TC-02-ZED - failed due to improper received message for extended addr req message; exempted by CSA request (message too short to unpack, since the DUT responded to the extended request with a non-extended response).

    2024-08-14 18:03:20:814 | INFO | *******************Start test script : FB-PRE-TC-02-ZED.py*******************
    2024-08-14 18:03:20:814 | INFO | Script Version: BDB3.0.1:0:20220620:final
    2024-08-14 18:03:20:815 | INFO | User Tag: 3.1.20240514
    2024-08-14 18:03:20:815 | INFO | Hash Tag: e85b3d3bafdf26fb6182a3d19ffce1d9f5f022e0
    2024-08-14 18:03:20:815 | INFO | ===== HOST SYSTEM DETAILS =====
    2024-08-14 18:03:20:816 | INFO | Architecture: 64bit
    2024-08-14 18:03:20:816 | INFO | Machine     : AMD64
    2024-08-14 18:03:20:816 | INFO | System      : Windows
    2024-08-14 18:03:20:817 | INFO | Version     : 10.0.22621
    2024-08-14 18:03:20:817 | INFO | ===============================
    2024-08-14 18:03:20:818 | INFO | Port Detection: Auto
    2024-08-14 18:03:20:818 | INFO | Role Assignment: Auto
    2024-08-14 18:03:21:064 | INFO | THr1 serial port : COM5
    2024-08-14 18:03:21:065 | INFO | THr1 Firmware application version : v1.0.2.6
    2024-08-14 18:03:21:065 | INFO | Configuring THr1
    2024-08-14 18:03:21:066 | INFO | THr1 : TX | network leave
    ...
    2024-08-14 18:04:21:312 | INFO | ++++++++ Step 5a ++++++++
    2024-08-14 18:04:21:313 | INFO | Unicast NWK_addr_req, extended response
    2024-08-14 18:04:21:386 | INFO | THr1 : TX | custom lookup {f4ce36ebb42567c7}
    2024-08-14 18:04:21:409 | SERIAL_RX | THr1 : RX | 'ZigbeeTH>shortaddress:0x9BEA'
    2024-08-14 18:04:21:892 | INFO | THr1 : RX | Rcvd Frame = shortaddress:0x9BEA
    2024-08-14 18:04:21:892 | DEBUG | strResponse:shortaddress:0x9BEA
    2024-08-14 18:04:21:892 | INFO | Short address of device :<< 0x9BEA >>
    2024-08-14 18:04:21:893 | INFO | THr1 : TX | plugin test-harness z3 zdo nwk-addr-req {f4ce36ebb42567c7} 0x01 0x00 0x9BEA 0
    2024-08-14 18:04:21:893 | PROMPT | Waiting for the NWK_addr_rsp command : 5 seconds
    2024-08-14 18:04:21:923 | SERIAL_RX | THr1 : RX | 'ZigbeeTH>TestHarnessZ3: Network address request: 0x00'
    2024-08-14 18:04:23:343 | SERIAL_RX | THr1 : RX | 'ZigbeeTH>zdo:t0000003B:rx seq 02 cmd 8000 payload[00 C7 67 25 B4 EB 36 CE F4 EA 9B ]'
    2024-08-14 18:04:23:344 | INFO | THr1 : RX | Rcvd Frame = ZigbeeTH>zdo:t0000003B:rx seq 02 cmd 8000 payload[00 C7 67 25 B4 EB 36 CE F4 EA 9B ]
    2024-08-14 18:04:23:344 | DEBUG | str dict: {'sequence': '02', 'command_id': 32768, 'payload': '00 C7 67 25 B4 EB 36 CE F4 EA 9B'} 
    2024-08-14 18:04:23:345 | ERROR | Payload decode exception, error = stream read less then specified amount, expected 1, found 0
    2024-08-14 18:04:23:346 | ERROR | NWK_add_req failed ERROR: nwk_addr_rsp_ext
    2024-08-14 18:04:23:412 | ERROR | THr1: Failed to receive NWK address response, line = 176
    2024-08-14 18:04:23:413 | PROMPT | Wait for 2 seconds
    2024-08-14 18:04:25:428 | INFO | Step 5b applicable only when DUT is ZC/ZR
    2024-08-14 18:04:25:429 | INFO | Step 5c applicable only when DUT does not support ZLT3_2
    2024-08-14 18:04:25:430 | INFO | Step 6-7 applicable only when DUT is ZC/ZR
    2024-08-14 18:04:25:430 | PROMPT | Wait for 5 seconds
    2024-08-14 18:04:30:492 | VERDICT | Step 5a | FAIL
    ...
    

  • Hi,

    Thank you for providing the information and logs!

    I have forwarded it internally, and I will let you know if I have more questions or any updates.

    Best regards,
    Marte

  • Hi,

    Do you have any sniffer logs from test FB-PRE-TC-02 that you can share?

    Best regards,
    Marte

  • Hi Marte,

    I just took a capture now + attached the dissection below.

    Note in the capture the first packet which performs a nwk_addr_req with extended flag set, and receives a 20 byte response, only containing the status, IEEEaddr, NWKaddr fields, omitting NumAssocDev and StartIndex. The second request (third packet) is a nwk_addr_req without the extended flag set, which yields the same result.

    The specification states that

    If the RequestType in the request is Extended Response and there are no associated devices on the Remote Device, this field SHALL be set to 0. 

    Since the initial request type is extended, the CSA tests appear to expect this byte to at least be included and set to zero to properly parse the message, otherwise the test fails. Whether that is an issue with the ZBOSS stack or with CSA's expectations in their testing, I am not sure however. Regardless, it is an official CSA test that will inhibit certification until the discrepancy is resolved between ZBOSS + the CSA tests.

    No.     Time           Source                Destination           Protocol Length Info
        207 120.563806     0xc794                0xcbb4                ZigBee ZDP 54     Network Address Request, Address: NordicSe_73:08:0d:0f:c0
    
    Frame 207: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) on interface /dev/ttyACM1, id 0
        Interface id: 0 (/dev/ttyACM1)
            Interface name: /dev/ttyACM1
            Interface description: nRF Sniffer for 802.15.4
        Encapsulation type: IEEE 802.15.4 Wireless PAN with FCS not present (127)
        Arrival Time: Sep 26, 2024 18:29:02.823426000 UTC
        [Time shift for this packet: 0.000000000 seconds]
        Epoch Time: 1727375342.823426000 seconds
        [Time delta from previous captured frame: 0.001271000 seconds]
        [Time delta from previous displayed frame: 0.000000000 seconds]
        [Time since reference or first frame: 120.563806000 seconds]
        Frame Number: 207
        Frame Length: 54 bytes (432 bits)
        Capture Length: 54 bytes (432 bits)
        [Frame is marked: True]
        [Frame is ignored: False]
        [Protocols in frame: wpan:zbee_nwk:zbee_aps:zbee_zdp]
    IEEE 802.15.4 Data, Dst: 0xcbb4, Src: 0xc794
        Frame Control Field: 0x8861, Frame Type: Data, Acknowledge Request, PAN ID Compression, Destination Addressing Mode: Short/16-bit, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: Short/16-bit
            .... .... .... .001 = Frame Type: Data (0x1)
            .... .... .... 0... = Security Enabled: False
            .... .... ...0 .... = Frame Pending: False
            .... .... ..1. .... = Acknowledge Request: True
            .... .... .1.. .... = PAN ID Compression: True
            .... .... 0... .... = Reserved: False
            .... ...0 .... .... = Sequence Number Suppression: False
            .... ..0. .... .... = Information Elements Present: False
            .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x2)
            ..00 .... .... .... = Frame Version: IEEE Std 802.15.4-2003 (0)
            10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x2)
        Sequence Number: 39
        Destination PAN: 0xaabb
        Destination: 0xcbb4
        Source: 0xc794
        [Extended Source: SiliconL_ff:fe:32:29:3d (50:32:5f:ff:fe:32:29:3d)]
        [Origin: 115]
    ZigBee Network Layer Data, Dst: 0xcbb4, Src: 0xc794
        Frame Control Field: 0x0208, Frame Type: Data, Discover Route: Suppress, Security Data
            .... .... .... ..00 = Frame Type: Data (0x0)
            .... .... ..00 10.. = Protocol Version: 2
            .... .... 00.. .... = Discover Route: Suppress (0x0)
            .... ...0 .... .... = Multicast: False
            .... ..1. .... .... = Security: True
            .... .0.. .... .... = Source Route: False
            .... 0... .... .... = Destination: False
            ...0 .... .... .... = Extended Source: False
            ..0. .... .... .... = End Device Initiator: False
        Destination: 0xcbb4
        Source: 0xc794
        Radius: 30
        Sequence Number: 91
        [Extended Source: SiliconL_ff:fe:32:29:3d (50:32:5f:ff:fe:32:29:3d)]
        [Origin: 115]
        ZigBee Security Header
            Security Control Field: 0x28, Key Id: Network Key, Extended Nonce
                ...0 1... = Key Id: Network Key (0x1)
                ..1. .... = Extended Nonce: True
            Frame Counter: 606224
            Extended Source: SiliconL_ff:fe:32:29:3d (50:32:5f:ff:fe:32:29:3d)
            Key Sequence Number: 0
            Message Integrity Code: 73a29484
            [Key: 85acabc02f7ede90dae3d8455ecf80d1]
            [Key Label: ]
    ZigBee Application Support Layer Data, Dst Endpt: 0, Src Endpt: 0
        Frame Control Field: Data (0x40)
            .... ..00 = Frame Type: Data (0x0)
            .... 00.. = Delivery Mode: Unicast (0x0)
            ..0. .... = Security: False
            .1.. .... = Acknowledgement Request: True
            0... .... = Extended Header: False
        Destination Endpoint: 0
        Network Address Request (Cluster ID: 0x0000)
        Profile: ZigBee Device Profile (0x0000)
        Source Endpoint: 0
        Counter: 255
    ZigBee Device Profile, Network Address Request, Address: NordicSe_73:08:0d:0f:c0
        Sequence Number: 2
        Extended Address: NordicSe_73:08:0d:0f:c0 (f4:ce:36:73:08:0d:0f:c0)
        Request Type: Extended Response (1)
        Index: 0
    
    Frame (54 bytes):
    0000  61 88 27 bb aa b4 cb 94 c7 08 02 b4 cb 94 c7 1e   a.'.............
    0010  5b 28 10 40 09 00 3d 29 32 fe ff 5f 32 50 00 95   [(.@..=)2.._2P..
    0020  4e a9 98 13 9f 0e 10 27 cb f7 d8 0d 68 21 9d 65   N......'....h!.e
    0030  0e c1 73 a2 94 84                                 ..s...
    Decrypted ZigBee Payload (19 bytes):
    0000  40 00 00 00 00 00 00 ff 02 c0 0f 0d 08 73 36 ce   @............s6.
    0010  f4 01 00                                          ...
    
    No.     Time           Source                Destination           Protocol Length Info
        211 120.576539     0xcbb4                0xc794                ZigBee ZDP 71     Network Address Response, Status: Success, Address: NordicSe_73:08:0d:0f:c0 = 0xcbb4
    
    Frame 211: 71 bytes on wire (568 bits), 71 bytes captured (568 bits) on interface /dev/ttyACM1, id 0
        Interface id: 0 (/dev/ttyACM1)
            Interface name: /dev/ttyACM1
            Interface description: nRF Sniffer for 802.15.4
        Encapsulation type: IEEE 802.15.4 Wireless PAN with FCS not present (127)
        Arrival Time: Sep 26, 2024 18:29:02.836159000 UTC
        [Time shift for this packet: 0.000000000 seconds]
        Epoch Time: 1727375342.836159000 seconds
        [Time delta from previous captured frame: 0.002732000 seconds]
        [Time delta from previous displayed frame: 0.012733000 seconds]
        [Time since reference or first frame: 120.576539000 seconds]
        Frame Number: 211
        Frame Length: 71 bytes (568 bits)
        Capture Length: 71 bytes (568 bits)
        [Frame is marked: True]
        [Frame is ignored: False]
        [Protocols in frame: wpan:zbee_nwk:zbee_aps:zbee_zdp]
    IEEE 802.15.4 Data, Dst: 0xc794, Src: 0xcbb4
        Frame Control Field: 0x8861, Frame Type: Data, Acknowledge Request, PAN ID Compression, Destination Addressing Mode: Short/16-bit, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: Short/16-bit
            .... .... .... .001 = Frame Type: Data (0x1)
            .... .... .... 0... = Security Enabled: False
            .... .... ...0 .... = Frame Pending: False
            .... .... ..1. .... = Acknowledge Request: True
            .... .... .1.. .... = PAN ID Compression: True
            .... .... 0... .... = Reserved: False
            .... ...0 .... .... = Sequence Number Suppression: False
            .... ..0. .... .... = Information Elements Present: False
            .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x2)
            ..00 .... .... .... = Frame Version: IEEE Std 802.15.4-2003 (0)
            10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x2)
        Sequence Number: 121
        Destination PAN: 0xaabb
        Destination: 0xc794
        Source: 0xcbb4
        [Extended Source: NordicSe_73:08:0d:0f:c0 (f4:ce:36:73:08:0d:0f:c0)]
        [Origin: 165]
    ZigBee Network Layer Data, Dst: 0xc794, Src: 0xcbb4
        Frame Control Field: 0x3a48, Frame Type: Data, Discover Route: Enable, Security, Destination, Extended Source, End Device Initiator Data
            .... .... .... ..00 = Frame Type: Data (0x0)
            .... .... ..00 10.. = Protocol Version: 2
            .... .... 01.. .... = Discover Route: Enable (0x1)
            .... ...0 .... .... = Multicast: False
            .... ..1. .... .... = Security: True
            .... .0.. .... .... = Source Route: False
            .... 1... .... .... = Destination: True
            ...1 .... .... .... = Extended Source: True
            ..1. .... .... .... = End Device Initiator: True
        Destination: 0xc794
        Source: 0xcbb4
        Radius: 30
        Sequence Number: 6
        Destination: SiliconL_ff:fe:32:29:3d (50:32:5f:ff:fe:32:29:3d)
        Extended Source: NordicSe_73:08:0d:0f:c0 (f4:ce:36:73:08:0d:0f:c0)
        ZigBee Security Header
            Security Control Field: 0x28, Key Id: Network Key, Extended Nonce
                ...0 1... = Key Id: Network Key (0x1)
                ..1. .... = Extended Nonce: True
            Frame Counter: 6
            Extended Source: NordicSe_73:08:0d:0f:c0 (f4:ce:36:73:08:0d:0f:c0)
            Key Sequence Number: 0
            Message Integrity Code: a846c4dd
            [Key: 85acabc02f7ede90dae3d8455ecf80d1]
            [Key Label: ]
    ZigBee Application Support Layer Data, Dst Endpt: 0, Src Endpt: 0
        Frame Control Field: Data (0x40)
            .... ..00 = Frame Type: Data (0x0)
            .... 00.. = Delivery Mode: Unicast (0x0)
            ..0. .... = Security: False
            .1.. .... = Acknowledgement Request: True
            0... .... = Extended Header: False
        Destination Endpoint: 0
        Network Address Response (Cluster ID: 0x8000)
        Profile: ZigBee Device Profile (0x0000)
        Source Endpoint: 0
        Counter: 246
    ZigBee Device Profile, Network Address Response, Status: Success, Address: NordicSe_73:08:0d:0f:c0 = 0xcbb4
        Sequence Number: 2
        Status: Success (0)
        Extended Address: NordicSe_73:08:0d:0f:c0 (f4:ce:36:73:08:0d:0f:c0)
        Nwk Addr of Interest: 0xcbb4
    
    Frame (71 bytes):
    0000  61 88 79 bb aa 94 c7 b4 cb 48 3a 94 c7 b4 cb 1e   a.y......H:.....
    0010  06 3d 29 32 fe ff 5f 32 50 c0 0f 0d 08 73 36 ce   .=)2.._2P....s6.
    0020  f4 28 06 00 00 00 c0 0f 0d 08 73 36 ce f4 00 65   .(........s6...e
    0030  f7 f5 da 19 98 dc 06 d2 fb 8e 15 c0 9d 39 db c7   .............9..
    0040  36 a2 26 a8 46 c4 dd                              6.&.F..
    Decrypted ZigBee Payload (20 bytes):
    0000  40 00 00 80 00 00 00 f6 02 00 c0 0f 0d 08 73 36   @.............s6
    0010  ce f4 b4 cb                                       ....
    
    No.     Time           Source                Destination           Protocol Length Info
        383 189.785082     0xc794                0xcbb4                ZigBee ZDP 48     Extended Address Request, Nwk Addr: 0xcbb4
    
    Frame 383: 48 bytes on wire (384 bits), 48 bytes captured (384 bits) on interface /dev/ttyACM1, id 0
        Interface id: 0 (/dev/ttyACM1)
            Interface name: /dev/ttyACM1
            Interface description: nRF Sniffer for 802.15.4
        Encapsulation type: IEEE 802.15.4 Wireless PAN with FCS not present (127)
        Arrival Time: Sep 26, 2024 18:30:12.044702000 UTC
        [Time shift for this packet: 0.000000000 seconds]
        Epoch Time: 1727375412.044702000 seconds
        [Time delta from previous captured frame: 0.003604000 seconds]
        [Time delta from previous displayed frame: 69.208543000 seconds]
        [Time since reference or first frame: 189.785082000 seconds]
        Frame Number: 383
        Frame Length: 48 bytes (384 bits)
        Capture Length: 48 bytes (384 bits)
        [Frame is marked: True]
        [Frame is ignored: False]
        [Protocols in frame: wpan:zbee_nwk:zbee_aps:zbee_zdp]
    IEEE 802.15.4 Data, Dst: 0xcbb4, Src: 0xc794
        Frame Control Field: 0x8861, Frame Type: Data, Acknowledge Request, PAN ID Compression, Destination Addressing Mode: Short/16-bit, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: Short/16-bit
            .... .... .... .001 = Frame Type: Data (0x1)
            .... .... .... 0... = Security Enabled: False
            .... .... ...0 .... = Frame Pending: False
            .... .... ..1. .... = Acknowledge Request: True
            .... .... .1.. .... = PAN ID Compression: True
            .... .... 0... .... = Reserved: False
            .... ...0 .... .... = Sequence Number Suppression: False
            .... ..0. .... .... = Information Elements Present: False
            .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x2)
            ..00 .... .... .... = Frame Version: IEEE Std 802.15.4-2003 (0)
            10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x2)
        Sequence Number: 62
        Destination PAN: 0xaabb
        Destination: 0xcbb4
        Source: 0xc794
        [Extended Source: SiliconL_ff:fe:32:29:3d (50:32:5f:ff:fe:32:29:3d)]
        [Origin: 115]
    ZigBee Network Layer Data, Dst: 0xcbb4, Src: 0xc794
        Frame Control Field: 0x0208, Frame Type: Data, Discover Route: Suppress, Security Data
            .... .... .... ..00 = Frame Type: Data (0x0)
            .... .... ..00 10.. = Protocol Version: 2
            .... .... 00.. .... = Discover Route: Suppress (0x0)
            .... ...0 .... .... = Multicast: False
            .... ..1. .... .... = Security: True
            .... .0.. .... .... = Source Route: False
            .... 0... .... .... = Destination: False
            ...0 .... .... .... = Extended Source: False
            ..0. .... .... .... = End Device Initiator: False
        Destination: 0xcbb4
        Source: 0xc794
        Radius: 30
        Sequence Number: 111
        [Extended Source: SiliconL_ff:fe:32:29:3d (50:32:5f:ff:fe:32:29:3d)]
        [Origin: 115]
        ZigBee Security Header
            Security Control Field: 0x28, Key Id: Network Key, Extended Nonce
                ...0 1... = Key Id: Network Key (0x1)
                ..1. .... = Extended Nonce: True
            Frame Counter: 606247
            Extended Source: SiliconL_ff:fe:32:29:3d (50:32:5f:ff:fe:32:29:3d)
            Key Sequence Number: 0
            Message Integrity Code: 52981794
            [Key: 85acabc02f7ede90dae3d8455ecf80d1]
            [Key Label: ]
    ZigBee Application Support Layer Data, Dst Endpt: 0, Src Endpt: 0
        Frame Control Field: Data (0x40)
            .... ..00 = Frame Type: Data (0x0)
            .... 00.. = Delivery Mode: Unicast (0x0)
            ..0. .... = Security: False
            .1.. .... = Acknowledgement Request: True
            0... .... = Extended Header: False
        Destination Endpoint: 0
        Extended Address Request (Cluster ID: 0x0001)
        Profile: ZigBee Device Profile (0x0000)
        Source Endpoint: 0
        Counter: 5
    ZigBee Device Profile, Extended Address Request, Nwk Addr: 0xcbb4
        Sequence Number: 7
        Nwk Addr of Interest: 0xcbb4
        Request Type: Single Device Response (0)
        Index: 0
    
    Frame (48 bytes):
    0000  61 88 3e bb aa b4 cb 94 c7 08 02 b4 cb 94 c7 1e   a.>.............
    0010  6f 28 27 40 09 00 3d 29 32 fe ff 5f 32 50 00 de   o('@..=)2.._2P..
    0020  ea 89 60 52 a9 d3 e6 66 08 45 3c de 52 98 17 94   ..`R...f.E<.R...
    Decrypted ZigBee Payload (13 bytes):
    0000  40 00 01 00 00 00 00 05 07 b4 cb 00 00            @............
    
    No.     Time           Source                Destination           Protocol Length Info
        387 189.798560     0xcbb4                0xc794                ZigBee ZDP 71     Extended Address Response, Status: Success, Nwk Addr: 0xcbb4 = NordicSe_73:08:0d:0f:c0
    
    Frame 387: 71 bytes on wire (568 bits), 71 bytes captured (568 bits) on interface /dev/ttyACM1, id 0
        Interface id: 0 (/dev/ttyACM1)
            Interface name: /dev/ttyACM1
            Interface description: nRF Sniffer for 802.15.4
        Encapsulation type: IEEE 802.15.4 Wireless PAN with FCS not present (127)
        Arrival Time: Sep 26, 2024 18:30:12.058180000 UTC
        [Time shift for this packet: 0.000000000 seconds]
        Epoch Time: 1727375412.058180000 seconds
        [Time delta from previous captured frame: 0.003709000 seconds]
        [Time delta from previous displayed frame: 0.013478000 seconds]
        [Time since reference or first frame: 189.798560000 seconds]
        Frame Number: 387
        Frame Length: 71 bytes (568 bits)
        Capture Length: 71 bytes (568 bits)
        [Frame is marked: True]
        [Frame is ignored: False]
        [Protocols in frame: wpan:zbee_nwk:zbee_aps:zbee_zdp]
    IEEE 802.15.4 Data, Dst: 0xc794, Src: 0xcbb4
        Frame Control Field: 0x8861, Frame Type: Data, Acknowledge Request, PAN ID Compression, Destination Addressing Mode: Short/16-bit, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: Short/16-bit
            .... .... .... .001 = Frame Type: Data (0x1)
            .... .... .... 0... = Security Enabled: False
            .... .... ...0 .... = Frame Pending: False
            .... .... ..1. .... = Acknowledge Request: True
            .... .... .1.. .... = PAN ID Compression: True
            .... .... 0... .... = Reserved: False
            .... ...0 .... .... = Sequence Number Suppression: False
            .... ..0. .... .... = Information Elements Present: False
            .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x2)
            ..00 .... .... .... = Frame Version: IEEE Std 802.15.4-2003 (0)
            10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x2)
        Sequence Number: 160
        Destination PAN: 0xaabb
        Destination: 0xc794
        Source: 0xcbb4
        [Extended Source: NordicSe_73:08:0d:0f:c0 (f4:ce:36:73:08:0d:0f:c0)]
        [Origin: 165]
    ZigBee Network Layer Data, Dst: 0xc794, Src: 0xcbb4
        Frame Control Field: 0x3a48, Frame Type: Data, Discover Route: Enable, Security, Destination, Extended Source, End Device Initiator Data
            .... .... .... ..00 = Frame Type: Data (0x0)
            .... .... ..00 10.. = Protocol Version: 2
            .... .... 01.. .... = Discover Route: Enable (0x1)
            .... ...0 .... .... = Multicast: False
            .... ..1. .... .... = Security: True
            .... .0.. .... .... = Source Route: False
            .... 1... .... .... = Destination: True
            ...1 .... .... .... = Extended Source: True
            ..1. .... .... .... = End Device Initiator: True
        Destination: 0xc794
        Source: 0xcbb4
        Radius: 30
        Sequence Number: 14
        Destination: SiliconL_ff:fe:32:29:3d (50:32:5f:ff:fe:32:29:3d)
        Extended Source: NordicSe_73:08:0d:0f:c0 (f4:ce:36:73:08:0d:0f:c0)
        ZigBee Security Header
            Security Control Field: 0x28, Key Id: Network Key, Extended Nonce
                ...0 1... = Key Id: Network Key (0x1)
                ..1. .... = Extended Nonce: True
            Frame Counter: 14
            Extended Source: NordicSe_73:08:0d:0f:c0 (f4:ce:36:73:08:0d:0f:c0)
            Key Sequence Number: 0
            Message Integrity Code: 09a4e49d
            [Key: 85acabc02f7ede90dae3d8455ecf80d1]
            [Key Label: ]
    ZigBee Application Support Layer Data, Dst Endpt: 0, Src Endpt: 0
        Frame Control Field: Data (0x40)
            .... ..00 = Frame Type: Data (0x0)
            .... 00.. = Delivery Mode: Unicast (0x0)
            ..0. .... = Security: False
            .1.. .... = Acknowledgement Request: True
            0... .... = Extended Header: False
        Destination Endpoint: 0
        Extended Address Response (Cluster ID: 0x8001)
        Profile: ZigBee Device Profile (0x0000)
        Source Endpoint: 0
        Counter: 250
    ZigBee Device Profile, Extended Address Response, Status: Success, Nwk Addr: 0xcbb4 = NordicSe_73:08:0d:0f:c0
        Sequence Number: 7
        Status: Success (0)
        Extended Address: NordicSe_73:08:0d:0f:c0 (f4:ce:36:73:08:0d:0f:c0)
        Nwk Addr of Interest: 0xcbb4
    
    Frame (71 bytes):
    0000  61 88 a0 bb aa 94 c7 b4 cb 48 3a 94 c7 b4 cb 1e   a........H:.....
    0010  0e 3d 29 32 fe ff 5f 32 50 c0 0f 0d 08 73 36 ce   .=)2.._2P....s6.
    0020  f4 28 0e 00 00 00 c0 0f 0d 08 73 36 ce f4 00 c0   .(........s6....
    0030  25 fe d8 75 95 81 47 9c d1 bf 0d 33 6d 41 46 60   %..u..G....3mAF`
    0040  30 dc 20 09 a4 e4 9d                              0. ....
    Decrypted ZigBee Payload (20 bytes):
    0000  40 00 01 80 00 00 00 fa 07 00 c0 0f 0d 08 73 36   @.............s6
    0010  ce f4 b4 cb                                       ....
    

Related