On Tue, 28 Feb 2023 at 22:08, Richard Cochran <richardcoch...@gmail.com> wrote: > On Tue, Feb 28, 2023 at 07:38:44PM +0100, Andrew Zaborowski wrote: > > On Tue, 28 Feb 2023 at 16:02, Richard Cochran <richardcoch...@gmail.com> > > wrote: > > > In the case of the PTP minor version field, there are already two > > > known bad HW devices that fail when the field is non-zero. Of course, > > > this violates 1588-2008, but it proves the point that vendors don't > > > follow the standard. > > > > Ok, that was a concern but I didn't know how likely it would be. > > Given this would you agree to zeroing those values based on a setting? > > No, I just wanted to point out the risk. So far, HW vendors track > record has been abysmal. If there is a way to do wrong, then somebody > sure will.
(That's consistent with a lot of protocol standards unfortunately) > > The SW should zero the controlField unconditionally as called out in > 1588-2019 clause 13.3.2.13. Previously I overlooked this silly detail > because the change is not identified in 19.4 "Compatibility ... to > IEEE Std 1588-2008". I was now made aware that Avnu conformance tests for 802.1AS-2011 do validate the 3 different values required in the control field in that version of IEEE802.1AS. While 1588-2008 did already say that the use of this field on the receiver is "deprecated", 802.1AS-2011 does not say anything like this. There's value for Avnu in having an option to go back to those values and perhaps shipping a "gPTP-2011.cfg" file with that option enabled. Would you be open to have this upstream? The difference with the minVersionPTP field is that that one was reserved in 802.1AS-2011 so it's not being validated. Best regards _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
