Re: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV?

[Richard Cochran]

On Wed, Jan 30, 2019 at 11:50:00AM +0100, Jiri Benc wrote:
> 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).

+1

Thanks,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] How to stop feeding ntpshm when my master clock is no longuer reacheable.

[FUSTE Emmanuel]

Le 30/01/2019 à 14:42, Miroslav Lichvar a écrit :
> On Wed, Jan 30, 2019 at 12:02:28PM +, FUSTE Emmanuel wrote:
>> Hello,
>>
>> When I lost communication with my grandmaster clock, my local ptp clock
>> is free running and becoming local grandmaster (the port is still slave
>> because of the "slaveOnly" option).
> That doesn't sound right. If the port is configured with the slaveOnly
> option, it should switch to the listening state when the grandmaster
> stops announcing. Without slaveOnly, it should switch to the master
> state.
That is what I expected. But not what I saw with some older versions of 
ptp4l (see below).
>
>> In this case, I would like phc2sys stop feeding the ntpshm to allow the
>> ntp daemon (chrony in this case) to select another ntp source, or stop
>> announcing time/pretending serving stratum 0 time.
> It should stop updating the SHM segment when the port is not in the
> slave state.
>
> How exactly do you start phc2sys? With -a -r or -a -r -r?
>
phc2sys in my case started by timemaster with -a -r.
I just do a test on a fresh install (latest git master) and it seems to 
work.

Jan 30 15:56:41 testhost ptp4l: [98619.476] [0:eno2] port 1: SLAVE to LISTENING 
on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
Jan 30 15:56:41 testhost ptp4l: [98619.476] [0:eno2] selected local clock 
xx..xx as best master
Jan 30 15:56:47 testhost ptp4l: [98625.752] [0:eno2] selected local clock 
xx..xx as best master
Jan 30 15:56:54 testhost ptp4l: [98632.252] [0:eno2] selected local clock 
xx..xx as best master
Jan 30 15:57:01 testhost ptp4l: [98639.548] [0:eno2] selected local clock 
xx..xx as best master
Jan 30 15:57:01 testhost ptp4l: [98640.009] [0:eno2] selected best master clock 
yy..yy
Jan 30 15:57:01 testhost ptp4l: [98640.009] [0:eno2] port 1: LISTENING to 
UNCALIBRATED on RS_SLAVE
Jan 30 15:57:05 testhost ptp4l: [98644.186] [0:eno2] port 1: UNCALIBRATED to 
SLAVE on MASTER_CLOCK_SELECTED
Jan 30 15:58:27 testhost ptp4l: [98725.328] [0:eno2] port 1: SLAVE to LISTENING 
on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
Jan 30 15:58:27 testhost ptp4l: [98725.328] [0:eno2] selected local clock 
xx..xx as best master
Jan 30 15:58:33 testhost ptp4l: [98731.900] [0:eno2] selected local clock 
xx..xx as best master
Jan 30 15:58:40 testhost ptp4l: [98738.820] [0:eno2] selected local clock 
xx..xx as best master
Jan 30 15:58:45 testhost ptp4l: [98744.023] [0:eno2] selected best master clock 
yy..yy
Jan 30 15:58:45 testhost ptp4l: [98744.023] [0:eno2] port 1: LISTENING to 
UNCALIBRATED on RS_SLAVE
Jan 30 15:58:49 testhost ptp4l: [98747.200] [0:eno2] port 1: UNCALIBRATED to 
SLAVE on MASTER_CLOCK_SELECTED

The logs show "selected local clock xx..xx as best master" but as 
you said, phc2sys seems to have stopped the SHM segment update (as seen with 
chronyc).
That was  not the case on a older install.

The actual test was a very quick one.
Before the end of the week, I have a bigger maintenance to do on the 
grandmaster with a cut of several minutes.
I will check that the SHM is not updated and that chrony eject the refclok and 
get the opportunity to switch to another source.

Thank you
Emmanuel.



___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] How to stop feeding ntpshm when my master clock is no longuer reacheable.

[Miroslav Lichvar]

On Wed, Jan 30, 2019 at 12:02:28PM +, FUSTE Emmanuel wrote:
> Hello,
> 
> When I lost communication with my grandmaster clock, my local ptp clock 
> is free running and becoming local grandmaster (the port is still slave 
> because of the "slaveOnly" option).

That doesn't sound right. If the port is configured with the slaveOnly
option, it should switch to the listening state when the grandmaster
stops announcing. Without slaveOnly, it should switch to the master
state. 

> In this case, I would like phc2sys stop feeding the ntpshm to allow the 
> ntp daemon (chrony in this case) to select another ntp source, or stop 
> announcing time/pretending serving stratum 0 time.

It should stop updating the SHM segment when the port is not in the
slave state.

How exactly do you start phc2sys? With -a -r or -a -r -r?

-- 
Miroslav Lichvar


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

[Linuxptp-devel] How to stop feeding ntpshm when my master clock is no longuer reacheable.

[FUSTE Emmanuel]

Hello,

When I lost communication with my grandmaster clock, my local ptp clock 
is free running and becoming local grandmaster (the port is still slave 
because of the "slaveOnly" option).
In this case, I would like phc2sys stop feeding the ntpshm to allow the 
ntp daemon (chrony in this case) to select another ntp source, or stop 
announcing time/pretending serving stratum 0 time.

I did not find how to achieve this and suspect that support should be 
added to phc2sys to do this.
I am right ? What would be the best way to do this ?

Best regards,
Emmanuel.
___
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?

[Miroslav Lichvar]

On Wed, Jan 30, 2019 at 11:23:45AM +, Vincent Li X wrote:
> 
> 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.

One-zero padding sounds like beginning of another frame. I'm not sure
why a follow up message would need some special padding.

What NIC do you use? Can you show us a tcpdump -xx output? And do you
see it also on other NICs, i.e. is such packet actually transmitted by
the master?

-- 
Miroslav Lichvar


___
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?

[Vincent Li X]

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  
Sent: Wednesday, January 30, 2019 11:50 AM
To: Miroslav Lichvar 
Cc: Mats Bergman H ; Richard Jönsson
; Linuxptp-devel@lists.sourceforge.net
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:Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel


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?

[Jiri Benc]

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
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV?

[Miroslav Lichvar]

On Wed, Jan 30, 2019 at 05:33:58AM +, 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

Re: [Linuxptp-devel] [PATCH] unicast: limit message rate and grant duration

[Miroslav Lichvar]

On Tue, Jan 29, 2019 at 08:07:49AM -0800, Richard Cochran wrote: > On Tue, Jan 
29, 2019 at 10:00:37AM +0100, Miroslav Lichvar wrote:
> > Isn't that negligible when compared to the sync/announce traffic?
> 
> Not to the master or to the network itself.  I might have 1000 slaves
> renewing every 30 seconds.

Ok, but compare it to all network traffic that is generated by PTP.
With 1000 slaves in default configuration the master is on average
sending each second 1000 sync messages, 500 announce messages and
responding to 1000 delay requests. That's 3500 messages per second in
the network.

Now, 1000 slaves renewing their grants every 30 seconds adds to that
~66 messages per second (1.9% of all traffic).

With the proposed 3600 second maximum duration (2700 second renewal
interval) that would be only ~0.7 messages per second (0.02% of all
traffic). That's negligible.

With significantly longer durations I think it's more likely that the
master will be sending messages to slaves that are powered off without
canceling their grants, or changed their IP address, wasting much more
bandwidth than the grant renewals.

If you feel one hour is too short, would one day work for you?

-- 
Miroslav Lichvar


___
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?

[Vincent Li X]

 

Hi Steven,

Do you run with latest release?  I think the problem is ptp4l takes the
length as recvmsg() - carrierHeaderLen, instead of m->header. messageLength.

Or is it the driver’s responsibility to remove padding before socket?

 

Thanks,

Vincent

 

From: Sun, Steven (NSB - CN/Qingdao)  
Sent: Wednesday, January 30, 2019 6:34 AM
To: Vincent Li X ;
Linuxptp-devel@lists.sourceforge.net
Cc: Mats Bergman H ; Richard Jönsson

Subject: RE: ptp4l wrongly takes padding bytes as TLV?

 

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. 

 

Thanks,

Steven

 

From: Vincent Li X mailto:vincent.x...@ericsson.com> > 
Sent: Wednesday, January 30, 2019 12:48 AM
To: Linuxptp-devel@lists.sourceforge.net
 
Cc: Mats Bergman H mailto:mats.h.berg...@ericsson.com> >; Richard Jönsson
mailto:richard.jons...@ericsson.com> >
Subject: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV?

 

 

Hi,

We are running the old version 1.6.

1.  This is a normal FOLLOW-UP received with one-zero padding of 6
octets.



 

2.  sk.c this line returns 64, including eth header size 14.

cnt = recvmsg(fd, , flags);

 

3.  msg.c, cnt is 50, pdulen 44.

m->tlv_count = suffix_post_recv(suffix, cnt - pdulen,
>last_tlv);

 

4.  msg.c, this func takes 0x80 from above padding as tlv->length and
returns below EBADMSG.

static int suffix_post_recv(uint8_t *ptr, int len, struct tlv_extra *last)

{

  …

  if (tlv->length > len) {

return
-EBADMSG;

  } 

 

5.  It seems that eth standard doesn’t say “padding must be 0”. So it
could be a bug of ptp4l? or has been fixed by later release?

 

Thanks,

Vincent

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel