zigbee zcl payload field Sample Start Time doe not get decoded
The payload field Sample Start Time for Zigbee pkt GetSampedData (ZCL metering cluster) is reported as Not representable but actually the value is valid (seconds since year 2000 little endian)
Extract of incriminated pkt below:
Frame 7220: 126 bytes on wire (1008 bits), 126 bytes captured (1008 bits) on interface \\.\pipe\tiwspc_data, id 0
Internet Protocol Version 4, Src: 192.168.1.3, Dst: 192.168.1.3
User Datagram Protocol, Src Port: 17754, Dst Port: 17754
ZigBee Encapsulation Protocol, Channel: 13, Length: 66
IEEE 802.15.4 Data, Src: 0xd0d9, Dst: 0x0000
ZigBee Network Layer Data, Dst: 0xdd37, Src: 0xd0d9
ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
ZigBee Cluster Library Frame
Frame Control Field: Cluster-specific (0x01)
Sequence Number: 124
Command: Get Sampled Data (0x08)
Payload
Sample ID: 0
Sample Start Time: Not representable
Sample Type: 0
Number of Samples: 8
ZCL Frame --> 01 7c 08 00 00 08 27 92 2f 00 08 00
Would expect Sample Start Time to show -> 16/04/2025 08:30:00
How can I get the pkt decoded properly?
Wireshark Version 4.4.5 (v4.4.5-0-g47253bcf3773)
Can you provide a sample capture or at least a hex dump of the entire frame.
I do not have enough points to upload a file.
Here it is the all frame hex dump of for a ZCL GetSampledData pkt
(more).... ..1. .... .... = Security: True
Are you using a network key to decrypt?
I would guess you are using Windows? I think that there was a bug introduced by https://gitlab.com/wireshark/wireshar... that is subtracting the Zigbee epoch offset where it should be added, which produces a negative seconds value. Some systems, like Windows, do not handle time_t with negative seconds (unlike systems with the GNU C library) that would indicate times before the Unix epoch when using functions like mktime.
I think you should file a bug at https://gitlab.com/wireshark/wireshar...
You will be able to upload your file there.