On Wed, Jan 30, 2019 at 05:33:58AM +0000, Sun, Steven (NSB - CN/Qingdao) wrote: > Vincent, > > We saw similar issue when co-work with Qulsar's PTP master clock. Qulsar > master clock added 4 extra bytes after the PTP payload in UDP payload. Bad > message error was reported by ptl4l which is running in slave mode. The > difference is that we are using UDP4 unicast rather than ether multicast. > > In our case, ptp4l takes the UDP payload length rather than PTP messageLength > to process the messages. So any extra byte after PTP payload which length > 3 > bytes will cause the "bad message" error. > > I am not sure whether it's correct or not. Checked PTP and UDP specs but no > clear definition for this.
As was pointed out here couple days ago, the PTP spec doesn't seem to allow a longer "checksum complement" than 2 octets. UDP certainly doesn't allow adding arbitrary data to the payload. That would break most protocols. If I understand it correctly, the PTP message lenght field was needed for Ethernet and other transports which allow padding. UDP is not one of them. 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. -- Miroslav Lichvar _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
