Zigbee read attribute request not well managed ?

[Elyxoft]

Hi,

I have an issue when I want to read an attribute from a toll to my nrf52840 device.

For exemple attribut 0 of cluster basic, if I forge a general read request for this public attribute, nRF answer correctly, but is I do the same request on an attribut 0 of cluster basic with a manufacturer code, nRF answer with the value of the public attribute, it shall send an unsupported attribute in place.

Is it a bug of zboss 3.3 stack ? How to well managed manufacturer attribute field for read/write request ?

regards,

Elyxoft

[Marte Myrvold]

Hi Elyxoft,

Can you provide a sniffer log of this? Please upload the log as a pcap file.

It would also be helpful to know more about your set up and how you are sending the commands. What SDK are you using, nRF Connect SDK or nRF5 SDK, and what version? Are both devices implementing using one of our SDKs? How are you creating and sending the read attributes command?

Best regards,

Marte

[Elyxoft]

wrong_answer_for_msp_read_attribute.pcapng

Hi,

I use nRF5 SDK: nRF5_SDK_for_Thread_and_Zigbee_v4.1.0_32ce5f8 on a nRF52840-DK board.

Read attribute request is send with a custom software used since several years now on many zigbee products from other vendors without problem. Only think it do not welle managed joining a zb3.0 network so you can see several from from nRF who request tool to leave network, but not important for our current problem.

Set "zep" filter on catpure file to remove unwanted udp frame.

First try a standard read on attribute 0x0007 (PowerSource) from cluster 0x00 (Basic):

request at packet number 1377 and answer at packet 1381: all is fine

Second try same request but for an MSP attribute 0x0007 on cluster 0x00, we attempt to have an unsopprted attribute answer:

request at packet 1484 and answer at packet 1488: WRONG it answer success with value of public attribute, MSP filter is not apply !

Same test as been done with declare an MSP attribute to 0x0F00 on nRF product, a MSP request answer correctly but a public request answer with value of MSP and not with unsupported attribute.

Thank you for your help.

Elyxoft

[Marte Myrvold]

Hi Elyxoft,

I have forwarded this to the developers. I will get back to you when I get a response from them.

Best regards,

Marte

[Marte Myrvold]

Hi Elyxoft,

I have discussed this with the developers.

The way attribute reading is handled in our SDK follows the Zigbee Cluster Library specification. The specification does not specify how the device should handle a read attributes command for a standard cluster and attribute, but with the manufacturer specific sub-shield set to 1. It only specifies that a device receiving a read attributes command shall check whether the attribute exists on the device or not. From ZCL spec:

For each attribute identifier included in the command frame, the device SHALL first check that it corresponds to an attribute that exists on this device. If it does not, the device SHALL set the status field of the corresponding read attribute status record to UNSUPPORTED_ATTRIBUTE and SHALL not include an attribute value field. The device SHALL then move on to the next attribute identifier.

If the attribute identified by the attribute identifier is supported, the device SHALL set the status field of the corresponding read attribute status record to SUCCESS and SHALL set the attribute value field to its current value. The device SHALL then move on to the next attribute identifier.

In your case, the PowerSource attribute is supported on the device, so following the specification, the device shall set the status field to SUCCESS and respond with a read attributes response command.

Best regards,

Marte

[Elyxoft]

Hi,

I am not completely agree with your analyse, before checking the attribut id you shall check if it is a manufacturer specific read request and in this case check the manufacturer code, and of course do not response with the value of a public attribut.

2.5.1.1.1 ZCL Header Fields

The frame control field SHALL be specified as follows. The frame type sub-field SHALL be set to indicate a global command (0b00). The manufacturer specific sub-field SHALL be set to 0 if this command is being used to Read Attributes defined for any cluster in the ZCL or 1 if this command is being used to read manufacturer specific attributes.

The command identifier field SHALL be set to indicate the Read Attributes command (see Table 2-3).

An attribute set as manufacturer specific is not the same as a public attribute and the way to check it is done on the zcl header field. The worst case is to have two products from two differents manufacturer who decide to use the same identifier on the same cluster with the same datatype, the first manufacturer do a read with his manufacturer code on this attribute and receive a success answer from product of the other manufacturer ?

Is there a way to fix it ?

Regards,

Elyxoft