Hi Richard, In our case, it's not wrong FCS or unwanted padding, but PHY replaced original FCS with frame padding of random value. 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. NOTEThe message length does not include any padding bits specified in Annex D. Thanks, Vincent -----Original Message----- From: Richard Cochran <richardcoch...@gmail.com> Sent: Tuesday, February 5, 2019 5:15 AM To: Vincent Li X <vincent.x...@ericsson.com> Cc: Jiri Benc <jb...@redhat.com>; Miroslav Lichvar <mlich...@redhat.com>; Mats Bergman H <mats.h.berg...@ericsson.com>; Richard Jönsson <richard.jons...@ericsson.com>; Linuxptp-devel@lists.sourceforge.net; Anders Selhammer <anders.selham...@ericsson.com> Subject: Re: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV? On Mon, Feb 04, 2019 at 12:33:43PM +0000, Vincent Li X wrote: > You would accept and say "thank you" to the delivery man in case #1, > while reject #2 and #3. Hopefully I don't make it less > understandable. :) I think your analogy is not on the mark... > Happy Chinese Spring Festival to all! In the spirit of the new year, imagine you order 4 kilograms of pork. When the delivery arrives, you find that the butcher gave you 3.5 kg of pork and 0.5 of packaging. Surely you would complain about the unwanted padding! Cheers, Richard
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel