Ok. Thanks Jiri! How do you think about our case? We run 1.6 on raw ethernet. This is a normal FOLLOW-UP received with one-zero padding of 6 octets. Then ptp4l take the padding as TLV.
-----Original Message-----
From: Jiri Benc <jb...@redhat.com>
Sent: Wednesday, January 30, 2019 11:50 AM
To: Miroslav Lichvar <mlich...@redhat.com>
Cc: Mats Bergman H <mats.h.berg...@ericsson.com>; Richard Jönsson
<richard.jons...@ericsson.com>; Linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV?
On Wed, 30 Jan 2019 11:34:25 +0100, Miroslav Lichvar wrote:
> Are there other vendors than Qulsar that do this? If it's a common
> issue, it might need to be specified. IIRC there are few other cases
> where the spec had to be adjusted to follow what existing HW was doing.
The Qulsar hardware violates the PTP spec and as such, they cannot claim PTP
support. If they do, it's false advertisement and it's a reason to demand
fix from the vendor and if they can't deliver a fix, have the device
refunded.
I don't see reason why linuxptp should put hacks in place to workaround
broken hardware that knowingly violates the spec. I don't even see a reason
why the standard should be changed to accommodate such hardware with no real
technical reasons ("we were lazy to implement the spec correctly and we just
decided to violate the spec" is hardly a reason).
Jiri
_______________________________________________
Linuxptp-devel mailing list
mailto:Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
