# ESMC - extended QL TLV

Hi,

According G.8264/Y.1364 if a clock in an option 1 network supports both the QL TLV and the extended QL TLV, it should set the SSM code and the enhanced SSM code according, and send both the QL TLV and the extended QL TLV. Both TLVs shall be sent in one ESMC PDU.

In wireshark QL TLV is ok. TLV Type, TLV length and SSM Code are as expected.

But I'm having a problem with extended QL TLV saying that Timestamp is invalid?! https://imgur.com/MfTTlCk

Accoring to this table from G.8264 https://imgur.com/332Boxm 4. octat number of extended QL TLV should represent enhanced ssm code which is in this case 20, but as you can see from first picture that octate (and 3 more following) are assigned to Timestamp!?

Does someone knows is Wireshark supporting extended QL TLV, or the problem is in something else?

Link to a .pcap file: https://ufile.io/qmgbo0ud

Best regards

edit retag close merge delete

https://code.wireshark.org/review/git...
The length is hard coded:

#define ESMC_TIMESTAMP_TLV_LENGTH   0x08


And looks like it has been a while since last worked on:
https://bugs.wireshark.org/bugzilla/s...

( 2020-01-10 17:39:56 +0000 )edit

Hello, can you please tell me what is the need for an enhanced SSM code?

( 2021-12-08 07:54:03 +0000 )edit

The G.8264 standard has evolved to include a new set of more accurate reference clocks and the ESMC values needed to expand to include them. They have also added features to keep track of the chain of connection between the reference source: such as how many hops have been crossed, and what is the quality of those hops. This means that they added a TLV, which the dissector seems to get wrong.

( 2022-09-13 10:30:15 +0000 )edit
( 2022-09-13 14:47:25 +0000 )edit

Sort by » oldest newest most voted

This warrants a bug report here. Please attach the capture file to the bug as well.

more

Hi, this looks a bit old, but I've struck the same issue. I'll file a bug report.

( 2022-09-13 10:28:08 +0000 )edit