Re: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV?
Hi Jiri, Our PHY engineers said that, we had no choice but to believe them, as we don't have time/approach to add sniffing machine in the middle to check the real packets over the media. How about #3, if in future new PTP message type(general) comes with smaller size than 44, our current code would reject it. It's not what we want, right? Thanks, Vincent -Original Message- From: Jiri Benc Sent: Tuesday, February 5, 2019 5:07 PM To: Vincent Li X Cc: Richard Cochran ; Miroslav Lichvar ; Mats Bergman H ; Richard Jönsson ; Linuxptp-devel@lists.sourceforge.net; Anders Selhammer Subject: Re: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV? On Tue, 5 Feb 2019 15:44:47 +, Vincent Li X wrote: > In our case, it's not wrong FCS or unwanted padding, but PHY replaced > original FCS with frame padding of random value. I very much doubt that. I bet the FCS was just stripped. I have yet to see a NIC that would replace FCS by a random value. Much more likely, there was (wrong and uninitialized = security problem) padding added by the sender, FCS was appended after it and stripped on the receiver side. What you see is the padding. > The thing is we should not try to decode any padding/bytes after PTP > message body as TLV, because TLV is part of PTP message and total > length is specified by the messageLength field. The description from > 1588 is attached > below: > > 13.3.2.4 messageLength (UInteger16) > The value of the messageLength shall be the total number of octets > that form the PTP message. The counted octets start with the first > octet of the header and include and terminate with the last octet of > any suffix or, if there are no suffix members with the last octet of > the message as defined in this clause. > NOTE—The message length does not include any padding bits specified in > Annex D. The only thing this says is it's wrong to add padding at the end by the sender (because that violates "the value of the messageLength shall be the total number of octets that form the PTP message"). It says nothing about what the receiver is supposed to do with a message in which messageLength is not the total number of octets. Specifically, it does not require the receiver to use messageLength; note that with correct messages it does not matter as both approaches (using messageLength vs. using real length) yield to the same result. Jiri smime.p7s Description: S/MIME cryptographic signature ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV?
On Tue, 5 Feb 2019 15:44:47 +, Vincent Li X wrote: > In our case, it's not wrong FCS or unwanted padding, but PHY replaced > original FCS with frame padding of random value. I very much doubt that. I bet the FCS was just stripped. I have yet to see a NIC that would replace FCS by a random value. Much more likely, there was (wrong and uninitialized = security problem) padding added by the sender, FCS was appended after it and stripped on the receiver side. What you see is the padding. > The thing is we should not try to decode any padding/bytes after PTP message > body as TLV, because TLV is part of PTP message and total length is > specified by the messageLength field. The description from 1588 is attached > below: > > 13.3.2.4 messageLength (UInteger16) > The value of the messageLength shall be the total number of octets that form > the PTP message. The > counted octets start with the first octet of the header and include and > terminate with the last octet of any > suffix or, if there are no suffix members with the last octet of the message > as defined in this clause. > NOTE—The message length does not include any padding bits specified in Annex > D. The only thing this says is it's wrong to add padding at the end by the sender (because that violates "the value of the messageLength shall be the total number of octets that form the PTP message"). It says nothing about what the receiver is supposed to do with a message in which messageLength is not the total number of octets. Specifically, it does not require the receiver to use messageLength; note that with correct messages it does not matter as both approaches (using messageLength vs. using real length) yield to the same result. Jiri ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] phc2sys: Add external time stamping support
...again just a few bystander opinions on my part: On 5 Feb 2019 at 9:37, Miroslav Lichvar wrote: > On Mon, Feb 04, 2019 at 11:31:01PM +, Vladimir Oltean wrote: > > On 2/4/19 2:53 PM, Miroslav Lichvar wrote: > > > I was thinking about a similar approach. I'm not suggesting to use a > > > second time source (e.g. a GNSS refclock) to pair the pulses with real > > > time, only to synchronize the PHC to the nearest second using the PPS > > > input. The PHC can be initially set by ptp4l from the network, by > > > phc2sys from the system clock, or something else from the refclock. > > > Then phc2sys using the PPS input can take over and keep it > > > synchronized to TAI (no leap seconds). ptp4l can work as a grandmaster > > > on the PHC. That is my use case. > > > > Who guarantees that the switchover time between the states "1. NTP GNSS > > refclock driver disciplines system clock", "2. NIC PHC takes a sip of > > system time for initial time of day" and "3. PHC keeps chugging along > > keeping time of day based on PPS only" will not cause the NIC PHC to > > lean towards the wrong second, throwing its absolute value off by one? > > phc2sys can require the clock to be very close to the pulse edge, e.g. > 10 milliseconds, and refuse to operate when the offset is larger. We > can make some assumptions about maximum frequency error of the clock > (e.g. 500 ppm) and calculate the maximum time for phc2sys to lock. > I believe that we should leave some responsibility to the admin :-) "Dear Admin: based on your configuration, you probably want to serve PTP with no upstream PTP source. You want to serve PTP using a NIC-based PHC disciplined by the PPS. Note that the PHC has no inherent notion of 'time of day' etc. We can initialize the PHC's wall time down to the second from the system clock, but THE RESPONSIBILITY IS YOURS to provide your Linux system clock with valid time, before you start the PTP service. Principally in theory, for a successful PHC initialization, your Linux system time should be accurate within < +/- 0.5s of the PPS edge that you provide to the PHC. Preferably much more accurate, for optimal results / safe PHC init." Note that low single-digit milliseconds of accuracy are possible with NTP off pool.ntp.org, i.e. using servers in the wild internet. There are so many different ways of providing plausible time to the Linux system clock... Let the admin pick one, using his best judgement - and let us take that "time reference" to initialize the PHC, and from there use the PPS input to servo the PHC. If the admin has an accurate PPS source that he can plug into our i210 PHC, does it even matter where the system clock's Time of Day information came from? Whether NTP from the wild internet, or incidentally that same GPS refclock providing the PPS ? On a decent timing GPS, the serial string alone is enough to get millisecond-level accuracy... And one more note specifically on: > > Who guarantees that [...] will not cause the NIC PHC to lean > > towards the wrong second, throwing its absolute value off by one? The algorithm in my proggie works in two steps: 1) ignoring the system clock or the absolute PHC time, just calculate the distance (nanoseconds) between the previous PPS event and the current PPS event. If the distance is short(-ish), probably the previous event was a leading edge and the current event is a trailing edge. We are interested in the leading edge, that's the whole-second boundary. (My algorithm actually looks for a particular expected pulse length +/- some margin, compile-time constants.) 2) now that we know the leading PPS edge, calculate its bipolar offset from the PHC's current whole-second boundary (which will be within +/- 0.5s) and start tuning the servo loop from there. Actually there should be a step 0) where the absolute PHC time is initialized by copy from the Linux system clock. So unless the system clock (used as initial reference) is off by more than 500 ms against the PPS edge used to discipline the PHC, the algorithm will converge to the correct second boundary. Simple quantisation math. If the system admin cannot get his act together, we can hardly decide this for him algorithmically (not having another reference to compare against). Though as Mr. Lichvar says, we could use an actual offset past some pedantic margin as a statistically probable indication that the admin has not done his homework :-) > A separate phc2sys instance can be used for monitoring the offset > between the system clock and PHC. > "just in case", I understand... to report errors into syslog, keep a watch in Nagios or something. Normally the deviation should not grow over time, if both the PHC and the system clock are disciplined, even if disciplined independently as we're suggesting here. > > And why pass GPS -> NIC PHC disciplining through the system time at all? > > I think that would be the easiest approach using the existing tools. >
Re: [Linuxptp-devel] [PATCH] phc2sys: Add external time stamping support
On Mon, Feb 04, 2019 at 11:31:01PM +, Vladimir Oltean wrote: > On 2/4/19 2:53 PM, Miroslav Lichvar wrote: > > I was thinking about a similar approach. I'm not suggesting to use a > > second time source (e.g. a GNSS refclock) to pair the pulses with real > > time, only to synchronize the PHC to the nearest second using the PPS > > input. The PHC can be initially set by ptp4l from the network, by > > phc2sys from the system clock, or something else from the refclock. > > Then phc2sys using the PPS input can take over and keep it > > synchronized to TAI (no leap seconds). ptp4l can work as a grandmaster > > on the PHC. That is my use case. > > Who guarantees that the switchover time between the states "1. NTP GNSS > refclock driver disciplines system clock", "2. NIC PHC takes a sip of > system time for initial time of day" and "3. PHC keeps chugging along > keeping time of day based on PPS only" will not cause the NIC PHC to > lean towards the wrong second, throwing its absolute value off by one? phc2sys can require the clock to be very close to the pulse edge, e.g. 10 milliseconds, and refuse to operate when the offset is larger. We can make some assumptions about maximum frequency error of the clock (e.g. 500 ppm) and calculate the maximum time for phc2sys to lock. A separate phc2sys instance can be used for monitoring the offset between the system clock and PHC. > And why pass GPS -> NIC PHC disciplining through the system time at all? I think that would be the easiest approach using the existing tools. But it's not a requirement and phc2sys shouldn't care about that. If you had a program that can timestamp serial data using the PHC, you could avoid the system clock completely. > Currently in core PTP kernel framework there is no way to distinguish > between rising edge and falling edge extts FIFO events. That being said, > the only sane options I see are (a) patch drivers to only report rising > edge (b) make the distinction at the level of individual extts FIFO entries. > I don't see why letting userspace guess whether the extts event was > rising or falling is a good idea. If the HW could report what edge it is, or could be configured to report only rising or falling edges, that would be great. I don't remember seeing a way to do that in the I210 datasheet. But what's strange is that I saw in one case with an I210 that it was reporting only the rising edge. I'm not sure if there was a problem with the PPS signal, or I accidentally put it in some weird state. -- Miroslav Lichvar ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
