Hi Jiri, Our PHY engineers said that, we had no choice but to believe them, as we don't have time/approach to add sniffing machine in the middle to check the real packets over the media. How about #3, if in future new PTP message type(general) comes with smaller size than 44, our current code would reject it. It's not what we want, right?
Thanks, Vincent -----Original Message----- From: Jiri Benc <jb...@redhat.com> Sent: Tuesday, February 5, 2019 5:07 PM To: Vincent Li X <vincent.x...@ericsson.com> Cc: Richard Cochran <richardcoch...@gmail.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 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
