can't get ZCL cluster id with LUA dissector

asked 2020-06-23 10:38:58 +0000

updated 2020-06-23 12:56:25 +0000

grahamb gravatar image

I have specific data in the payload of a ZCL message, for which I want the (decoded) data to be shown in the packet detail pane.

My dissector as follow:

-- create a new dissector
local NAME = "LM_FCC0"
local CID = 0xFCC0
local LM_FCC0 = Proto(NAME, "lm 0xFCC0 Protocol")

-- dissect packet
function LM_FCC0.dissector (tvb, pinfo, tree)
  pinfo.cols.protocol =" LM Info")enter code here

  local subtree = tree:add(LM_FCC0, tvb())
  length = tvb:len()
  subtree:append_text(", length:" .. length)

DissectorTable.get("zbee.zcl.cluster"):add(CID, LM_FCC0)

when I loaded the dissector, I can find it in the View -> Internals -> Dissector Tables, but the dissector isn't work.

Somebody please guide me what is my mistake?


the attachment is my sniffer log. you can find the 0xFCC0 in the 642 line

I can't upload the attachment. I put the attachment on GitHub. The depositary address is as follows:

edit retag flag offensive close merge delete


Are you sure the CID value is correct for your traffic? Can you share a sample capture?

grahamb gravatar imagegrahamb ( 2020-06-23 11:00:06 +0000 )edit

The ZigBee traffic is encrypted so without the keying info there's not much to look at.

grahamb gravatar imagegrahamb ( 2020-06-23 13:07:19 +0000 )edit

sorry,nwkKey is : 56:E3:CC:61:B2:8F:88:ED:CE:FB:04:39:AA:27:40:45 gravatar image[email protected] ( 2020-06-23 14:44:45 +0000 )edit

sorry, the capture is converted by uibiqua,The data is encrypted on another computer in here.

I will capture it tomorrow using wireshark.

Thank you for you reply. gravatar image[email protected] ( 2020-06-23 15:04:15 +0000 )edit

Hi grahamb,

This problem may not be caused by encryption. I used wireshark to re-capture a new sample capture, it isn't work.

the files(packetNum232_0xFCC0_20200624.pcapng and packetNum232_0xFCC0_PacketInfo.pdf) has been updated to github.

If you are free, can you help me to check it?

thx gravatar image[email protected] ( 2020-06-24 06:15:09 +0000 )edit

Your key worked so I can see the decrypted traffic. As I'm unfamiliar with Zigbee I'm having to work may way through the code.

I'm uncertain about the CID value being used to register in the zbee.zcl.cluster table. This is a 16 bit unsigned integer and, according to the MACRO used in the zcl dissector, is formed from the cluster id and the manufacturer code:

#define ZCL_CLUSTER_MFR_KEY(cluster_id,mfr_code)    (((mfr_code)<<16) | (cluster_id))

I can't find where the two values (mfr_code and cluster_id) come from. Another concern is that the macro shifts the mfr_code 16 bits to the left, but the table index is only 16 bits.

grahamb gravatar imagegrahamb ( 2020-06-24 08:12:39 +0000 )edit

In the zigbee specification: If it is a standard cluster, the manufacturer code field does not appear in the data frame. If it is a manufacturer-defined cluster, the manufacturer code field will appear in the data frame.

Among them, the type of manufacturer code and CID are Uint16, and the manufacturer code and CID can specify a unique data service channel

Currently I am modifying the value of CID in the LUA dissector to 0x0000 (Basic Cluster Id of zigbee), the new dissector still does not work (Basic Cluster data on line 211 in the new sample capture still cannot be re-parsed) gravatar image[email protected] ( 2020-06-24 11:19:47 +0000 )edit

Example dissection:

ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
 Frame Control Field: Data (0x00)
 Destination Endpoint: 1
 Cluster: Manufacturer Specific (0xfcc0)
 Profile: Home Automation (0x0104)
 Source Endpoint: 1
 Counter: 13
ZigBee Cluster Library Frame, Mfr: Unknown (0x115f), Command: Report Attributes, Seq: 1
 Frame Control Field: Profile-wide (0x1c)
 .... ..00 = Frame Type: Profile-wide (0x0)
 .... .1.. = Manufacturer Specific: True //++++++++++++THIS bit indicates whether it is a manufacturer-defined Cluster+++++++++++++
 .... 1... = Direction: Server to Client
 ...1 .... = Disable Default Response: True
 Manufacturer Code: Unknown (0x115f)
 Sequence Number: 1
 Command: Report Attributes (0x0a)
 Attribute Field, Octets: 01:21:d4:0b:03:28:19:04:21:a8:01:05:21:0e:00:06:…
 Attribute: 0x00f7
 Data Type: Octet String (0x41)
 Octet String: 01:21:d4:0b:03:28:19:04:21:a8:01:05:21:0e:00:06: gravatar image[email protected] ( 2020-06-24 11:41:27 +0000 )edit

In the ZCL dissector, the table "index" for the sub-dissector is formed from calling the macro I listed above, e.g.

ZCL_CLUSTER_MFR_KEY(cluster_id, packet.mfr_code)

where cluster_id is (I think) generated from a previous packet and packet.mfr_code is the value displayed as the "Manufacturer Code" (in filter field which in this case is 0x115f.

However, further inspection of the dissector shows that it will only call the registered sub-dissector if the Frame Type (zbee_zcl.type) is NOT a "Profile-wide" type. In your case it is, so no sub-dissector will be called. I have no idea if this is correct, but it is what is implemented. Note this is on the current master branch, your output indicates you may be running an older version.

grahamb gravatar imagegrahamb ( 2020-06-24 13:28:02 +0000 )edit

Thank you for you reply.

Usually the Frame Type (zbee_zcl.type) isn't paid too much attention, and I need to further confirm its meaning here.

I had modified the value of CID in the LUA dissector to 0x0000 (0x0000 is Basic Cluster Id of zigbee), but the new dissector still does not work (Basic Cluster data Without Manufacture Code on line 211 in the new sample capture still cannot be re-parsed). In other words,it did not get zbee.zcl.cluster (CID = 0x0000) and replace with the new dissector. gravatar image[email protected] ( 2020-06-26 16:32:48 +0000 )edit

As noted above, if the Frame Type is Profile-wide then no sub-dissector will be called regardless of what the sub-dissector registers with.

grahamb gravatar imagegrahamb ( 2020-06-26 20:26:07 +0000 )edit

thank you very much gravatar image[email protected] ( 2020-06-27 03:04:59 +0000 )edit