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

[Marte Myrvold]

Hi Elyxoft,

Elyxoft said:

2.5.1.1.1 ZCL Header Fields

This part of the specification specifies what the read attributes command should look like when it is sent from a device, and not how the receiving device should handle a command depending on the ZCL header field.

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.

According to this, the read attributes command you are sending from your device is incorrect and not according to the specification. Since the command is used to read attribute 0x0007 of the Basic cluster, both a cluster and an attribute that are defined in the ZCL, the manufacturer specific sub-field shall be set to 0. 

Elyxoft said:

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.

Yes, the ZCL header field is used to check if the command refers to a manufacturer specific extension. However, these manufacturer specific extensions can be of the following:

• Add manufacturer specific clusters to a standard device endpoint.
• Add manufacturer specific commands to a standard cluster.
• Add manufacturer specific attributes to a standard cluster.

When adding a manufacturer specific attribute to a standard cluster, the attribute ID should not be an ID that is already used by a standard attribute in the cluster.

I agree that the ZCL specification is not clear enough regarding this, which opens the possibility for different ways to interpret what the specification is saying. According to 2.5.1.1.1 ZCL Header Fields, the manufacturer field shall be set depending on whether the command is used to read a manufacturer specific attribute, or an attribute defined for any cluster in ZCL. Reading the PowerSource attribute in the Basic Cluster will be to read an attribute defined for a cluster in ZCL. However, you can argue that setting the manufacturer specific sub-field will make the attribute manufacturer specific, but in this case you are still using an attribute identifier that is already defined for a cluster in ZCL. Additionally, according to 2.5.1.3 Effect on Receipt, the only check is whether the attribute identifier corresponds to an attribute that exists on the device, which it does, as attribute 0x0007 (PowerSource) in cluster 0x0000 does exist.

Best regards,

Marte

[Elyxoft]

Hi,

Not agree section 2.5.1.1 is apply for generate and receive, generate specific section is specified in 2.5.1.2 and receive in 2.5.1.3. so when you do a manufacturer specific request only attributes set has manufacturer are concerned in the same way when you do a public request only public attributes are concerned.

When adding a manufacturer specific attribute to a standard cluster, the attribute ID should not be an ID that is already used by a standard attribute in the cluster.

You right since HA1.2 we can not use an existing id to put a manufacturer id, but if you try to read a manufacturer attribut with a silly tool, you have no reason to receive the value of the public attribute, it is not what you are request and the message if conform to specification, it is a stupid request ? yes. But conform and the answer is not. I have the same trouble when I request a anttribute id set as manufacturer and forge my request for a public attribute.

I search the PICS document but it can take time before I found the test apply to readattribute request during certification.

regards,

Elyxoft