On Tue, 5 Feb 2019 15:44:47 +0000, Vincent Li X wrote: > In our case, it's not wrong FCS or unwanted padding, but PHY replaced > original FCS with frame padding of random value.
I very much doubt that. I bet the FCS was just stripped. I have yet to see a NIC that would replace FCS by a random value. Much more likely, there was (wrong and uninitialized = security problem) padding added by the sender, FCS was appended after it and stripped on the receiver side. What you see is the padding. > The thing is we should not try to decode any padding/bytes after PTP message > body as TLV, because TLV is part of PTP message and total length is > specified by the messageLength field. The description from 1588 is attached > below: > > 13.3.2.4 messageLength (UInteger16) > The value of the messageLength shall be the total number of octets that form > the PTP message. The > counted octets start with the first octet of the header and include and > terminate with the last octet of any > suffix or, if there are no suffix members with the last octet of the message > as defined in this clause. > NOTE—The message length does not include any padding bits specified in Annex > D. The only thing this says is it's wrong to add padding at the end by the sender (because that violates "the value of the messageLength shall be the total number of octets that form the PTP message"). It says nothing about what the receiver is supposed to do with a message in which messageLength is not the total number of octets. Specifically, it does not require the receiver to use messageLength; note that with correct messages it does not matter as both approaches (using messageLength vs. using real length) yield to the same result. Jiri _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
