Re: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV?
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
From: Vincent Li X <vin...@er...> - 2019-01-30 11:25:08
|
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...@re...> Sent: Wednesday, January 30, 2019 11:50 AM To: Miroslav Lichvar <mli...@re...> Cc: Mats Bergman H <mat...@er...>; Richard Jönsson <ric...@er...>; Lin...@li... 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:Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-devel |