On Mon, Feb 12, 2018 at 08:12:38AM +0100, brain wrote: > I understand that you might find this requirement to be > pointless. However in protocols it is not uncommon that certain bits > are reserved for future use. In order to provide forward compatible > implementations it is a common practice to require reserved bits to > be ignored on reception.
That is not what is going on here. These bits are *not* reserved for future use. > In any case, the point of standards is not to cherrypick what one > finds good on them (and indeed there are bad standards too), but to > fully comply to them to get the maximum compatibility between > devices. But not to the point of madness. We have already seen many examples of PTP implementations ignoring the standard and creatively inventing new behavior. That is just the real world. > Due to the non-compliant implementation Linuxptp does not work in a > mixed AES67 network where Dante devices are present. Other AES67 > implementations work well because they correctly ignore bits 1-3. Ah, now we are getting somewhere. These bits are set by Dante devices when they try and do PTP, correct? Do you have a pointer to the Dante specification that explains this behavior? Thanks, Richard ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
