[Linuxptp-users] Parsing of organization extension TLVs

[Morten Flå]

Hi,
I'm currently testing a PTP Grandmaster clock that has the ability to
send out Organization Extension TLVs. However, it seems like ptp4l
treats these messages as a normal management message. The result of
this is that ptp4l evaluates the organizationId field as the
managementId, as they are located at the same byte offset.

It seems to me that both the clock_manage and the port_manage function
should be aware of this TLV type, and disregard the content if the
organizationId or organizationSubType is not recognized as per
14.3.2.3 in 1588-2008.

Currently the behavior is that ptp4l sends out an Management Error
Message (NO_SUCH_ID), but of course the parsing result is "random"
based on the OUI.

Regards,
Morten

[Richard Cochran]

Post by Morten Flå
I'm currently testing a PTP Grandmaster clock that has the ability to
send out Organization Extension TLVs. However, it seems like ptp4l
treats these messages as a normal management message. The result of
this is that ptp4l evaluates the organizationId field as the
managementId, as they are located at the same byte offset.

Management messages have TLV type 1.

Organization Extenstion messages have TLV type 3.

Sounds like your GM is sending Organization Extenstion message with
TLV type 1. That would be wrong.

Thanks,
Richard

[Morten Flå]

Hi,
I don't believe this is the case.
By following the current code sequence from git
d1bb9ecbd5a77cdb8d93accfa8c1bbf705002de0

In port.c:2259 we receive a packet, and the packet is rightly tagged
as a management msg type in the common message header, and we're thus
forwarded to the clock_manage function.
In the clock_manage function there is no check on what the TLV type
is. It's just assumed that the TLV type is 1, and thus the packet is
incorrectly parsed.

Below is a snippet of the packet. PTP payload starts at 0x2A.

0000 01 00 5e 00 01 81 ec 46 70 00 bf 9a 08 00 45 00 ..^....Fp.....E.
0010 00 80 2a 93 40 00 05 11 ba d9 ac 1b 02 64 e0 00 ..****@........d..
0020 01 81 01 40 01 40 00 6c c6 e5 0d 02 00 64 00 00 ***@.@.l.....d..
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ec 46 ...............F
0040 70 ff fe 00 bf 9a 00 01 74 c8 04 7f ff ff ff ff p.......t.......
0050 ff ff ff ff ff ff 01 01 03 00 00 03 00 30 68 97 .............0h.
0060 e8 00 00 01 00 00 00 19 00 00 00 01 01 00 ff ff ................
0070 ff db 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0080 00 00 ff ff ff fe ae 80 ff ff ff db 00 00 ..............

Thanks,
Morten

On Fri, May 12, 2017 at 10:16 AM, Richard Cochran

Post by Richard Cochran

Post by Morten Flå
I'm currently testing a PTP Grandmaster clock that has the ability to
send out Organization Extension TLVs. However, it seems like ptp4l
treats these messages as a normal management message. The result of
this is that ptp4l evaluates the organizationId field as the
managementId, as they are located at the same byte offset.

Management messages have TLV type 1.
Organization Extenstion messages have TLV type 3.
Sounds like your GM is sending Organization Extenstion message with
TLV type 1. That would be wrong.
Thanks,
Richard

[Richard Cochran]

Post by Morten Flå
In port.c:2259 we receive a packet, and the packet is rightly tagged
as a management msg type in the common message header, and we're thus
forwarded to the clock_manage function.

Ok, so the packet is a management message...

Post by Morten Flå
In the clock_manage function there is no check on what the TLV type
is. It's just assumed that the TLV type is 1, and thus the packet is
incorrectly parsed.

and there is no need to check the TLV type after that. According to
1588, management messages may have zero or one TLV (15.4.1.7), and
Table 38 makes it clear that only management TLVs are allowed.

For example:

GET action requires a single management TLV.

COMMAND action requires the "managementId field" to be set.

Post by Morten Flå
Below is a snippet of the packet. PTP payload starts at 0x2A.
0000 01 00 5e 00 01 81 ec 46 70 00 bf 9a 08 00 45 00 ..^....Fp.....E.

Here we have ......................... ^^
messageId: Management Message (0x0d)

Post by Morten Flå
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ec 46 ...............F
0040 70 ff fe 00 bf 9a 00 01 74 c8 04 7f ff ff ff ff p.......t.......
0050 ff ff ff ff ff ff 01 01 03 00 00 03 00 30 68 97 .............0h.

and then ....................... ^^
action: COMMAND (3)

followed by .......................... ^^ ^^
tlvType: Organization extension (3)

That is just plain wrong. The correct way to encode a vendor specific
management action is to use a managementId in range 0xC000-DFFF (Table 40).

For a correct example of the Organization extension, see sections

10.5.4 Signaling message
11.4.4.3 Follow_Up information TLV
E.5.2.1.1 CSN TLV (Follow_Up)

in IEEE 802.1AS-2011. Notice how none of the those TLVs appear on
management messages.

Thanks,
Richard

[Morten Flå]

Hi,
Thanks for the clarification.
This is how the SMPTE 2059-2 is defined with messageId field set to
Management Message and action set to Command followed by a
Organization Extension TLV, so I guess someone did not think this
through.

Thanks,
Morten

[Richard Cochran]

Post by Morten Flå
This is how the SMPTE 2059-2 is defined with messageId field set to
Management Message and action set to Command followed by a
Organization Extension TLV, so I guess someone did not think this
through.

Oh man.

I guess we'll have to reject management messages that lack a
management TLV.

Thanks,
Richard