Ask Your Question
0

PTPv2 announce messages malformed

asked 2020-07-26 10:46:11 +0000

Rick gravatar image

updated 2020-07-26 12:41:43 +0000

Within wireshark each announce messages of the IEEE1588 precition time synhronization protocol (PTPv2), after the organization extension TLV, the trail octets are regarded as malformed. What could be the issue?

pcap: https://drive.google.com/file/d/1H_Yy...

edit retag flag offensive close merge delete

Comments

Can you share a sample capture file? You can put one on a popular file sharing site and post a publicly accessible link here.

Jaap gravatar imageJaap ( 2020-07-26 12:16:05 +0000 )edit

Added the link to the initial request

Rick gravatar imageRick ( 2020-07-26 12:43:28 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2020-07-26 15:30:46 +0000

Jaap gravatar image

Thanks for the capture. Simply looking at the first packet, it shows:

Precision Time Protocol (IEEE1588)
    0000 .... = transportSpecific: 0x0
    .... 1011 = messageId: Announce Message (0xb)
    0000 .... = Reserved: 0
    .... 0010 = versionPTP: 2
    messageLength: 110
....
    TimeSource: INTERNAL_OSCILLATOR (0xa0)
    Organization extension TLV
        tlvType: Organization extension (3)
        lengthField: 18
        organizationId: 00:00:0c (Cisco Systems, Inc)
        organizationSubType: Unknown (0x010000)
        dataField: 030000000000000000000000
[Malformed Packet: PTP]
    [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
        [Malformed Packet (Exception occurred)]
        [Severity level: Error]
        [Group: Malformed]

0000  01 1b 19 00 00 00 00 b1 e3 74 13 01 88 f7 0b 02   .........t......
0010  00 6e 00 00 02 00 00 00 00 00 00 00 00 00 00 00   .n..............
0020  00 00 00 b1 e3 ff fe 74 13 00 00 01 5d 98 05 00   .......t....]...
0030  00 00 00 00 00 00 00 00 00 00 00 00 00 80 f8 fe   ................
0040  ff ff 80 00 b1 e3 ff fe 74 13 00 00 00 a0 00 03   ........t.......
0050  00 12 00 00 0c 01 00 00 03 00 00 00 00 00 00 00   ................
0060  00 00 00 00*00 09*00 38*00 00 00 00 00 00 00 00   .......8........
0070  00 00 00 00 00 00 00 03 55 54 43 00               ........UTC.

I've marked the next tag (0x0009) and length (0x0038) in the packet data. This tells there's a Alternate time offset indicator TLV with length 56. Clearly there are no 56 bytes left in the packet from that point. So the TLV seems malformed, as Wireshark reports.

Changing this length to 0x0014 (matching the actual amount of data left) results in:

TimeSource: INTERNAL_OSCILLATOR (0xa0)
Organization extension TLV
    tlvType: Organization extension (3)
    lengthField: 18
    organizationId: 00:00:0c (Cisco Systems, Inc)
    organizationSubType: Unknown (0x010000)
    dataField: 030000000000000000000000
Alternate time offset indicator TLV
    tlvType: Alternate time offset indicator (9)
    lengthField: 20
    keyField: 0
    currentOffset: 0
    jumpSeconds: 0
    timeOfNextJump: 000000000000
    displayName: UTC
        length: 3
        displayName: UTC

So this seems to indicate a bug in the software that created these PTP packets.

edit flag offensive delete link more

Comments

Thanks for your reply. The clock has a PTP power profile (IEEE C37.238, 2011). Setting the clock to the default PTP Layer 2 profile, with no TLV extension, shows no malformed packets

Rick gravatar imageRick ( 2020-07-28 07:28:06 +0000 )edit

Well, it definitely didn't send IEEE C37.238 TLVs, so that is strange in itself. Anyway, if not sending TLVs, then there's no bug triggered either, so that works.

Jaap gravatar imageJaap ( 2020-07-28 10:57:04 +0000 )edit

@Rick Out of interest, what software is generating the erroneous packets?

grahamb gravatar imagegrahamb ( 2020-07-28 11:57:08 +0000 )edit

I guess the IOS software running on the clock

Rick gravatar imageRick ( 2020-07-28 14:50:55 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

Stats

Asked: 2020-07-26 10:46:11 +0000

Seen: 1,272 times

Last updated: Jul 26 '20