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 Children
  • Hi,

    The Zigbee team is still looking into your concerns, but I have feedback on a couple of them.

    NWK_addr_req Extended Response

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

    Access to standard ZBOSS PICS descriptors

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

    If you or any customers have issues completing certification, we recommend creating a ticket on DevZone or contacting your local sales representative from Nordic Semiconductor.

    Best regards,
    Marte

  • > 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.

  • 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

Related