linuxptp-users

Re: [Linuxptp-users] PTP Control Field bug

[Richard C. <ric...@gm...>]

On Fri, Jul 08, 2022 at 01:08:04AM +0000, joy...@ar... wrote:
> Hi,
> 

> Using a binary built on v3.1, I'm trying to synchronize a Slave
> device with a Grandmaster but the Slave does not accept the
> Grandmaster as Master. It does not lock or synchronize either.

Which node is running ptp4l?  GM, slave, or both?

> However, it does send delay requests to the GM.
> Upon close inspection, it turns out that the unless the 'Announce' message control field value is set to '5', the slave does not accept GM as master.
> Announce message(Control Field 0): Master ignored
> Announce message (Control Field 5): Master accepted
> Dataset comparison set to G8275.x for both, all other slave and master configurations identical for both scenarios.
> This is puzzling since PTPV2(which 3.1 is based on) should not use this field for BMCA, as far as I know, only PTPV1 uses this field.
> Is this a bug or can v3.1 be configured to ignore this field?

If ptp4l is GM and your slave is some other stack, then that stack
does not follow 1588 correctly.

If ptp4l is the slave, then you are mistaken in your analysis.  The
control field is set for transmitted messages, but never tested on
recieved messages:

Cscope finding symbol "control" yields:

*** nsm.c:
nsm_request[398]               msg->header.control = CTL_DELAY_REQ;

*** pmc_common.c:
pmc_message[453]               msg->header.control = CTL_MANAGEMENT;

*** port.c:
port_pdelay_request[1353]      msg->header.control = CTL_OTHER;
port_delay_request[1417]       msg->header.control = CTL_DELAY_REQ;
port_tx_announce[1469]         msg->header.control = CTL_OTHER;
port_tx_sync[1546]             msg->header.control = CTL_SYNC;
port_tx_sync[1582]             fup->header.control = CTL_FOLLOW_UP;
process_delay_req[1914]        msg->header.control = CTL_DELAY_RESP;
process_pdelay_req[2105]       rsp->header.control = CTL_OTHER;
process_pdelay_req[2153]       fup->header.control = CTL_OTHER;
port_management_construct[2929] msg->header.control = CTL_MANAGEMENT;

*** port_signaling.c:
port_signaling_construct[49]   msg->header.control = CTL_OTHER;

*** tc.c:
tc_fwd_sync[459]               fup->header.control = CTL_FOLLOW_UP;


TL;DR -- header.control is never used for anything.

Thanks,
Richard

Re: [Linuxptp-users] PTP Control Field bug

[Richard C. <ric...@gm...>]

On Mon, Jul 11, 2022 at 01:42:14AM +0000, joy...@ar... wrote:

> Slave is running ptp4l, GM is running custom time-sync solution
> (G8275.1). GM has already been tested with Calnex Paragon Neo and
> has passed the test so compliance with 1588 should not be the issue
> here.

How can it pass when sending incorrect values in the control field?

> I have attached the 'Announce' messages from both CTL0 and
> CTL5 tests. However, this issue is with linuxptp v3.1. Once we
> change to master branch, this issue does not happen.

Please bisect to find the offending commit.

Thanks,
Richard

Re: [Linuxptp-users] PTP Control Field bug

[Richard C. <ric...@gm...>]

On Tue, Jul 12, 2022 at 02:29:22AM +0000, joy...@ar... wrote:

> Therefore, there is no such thing as an 'incorrect value' for the control field as long as it is PTP V2.

You are mistaken.  Please read IEEE 1588.  You will find the following specification:

   13.3.2.10 controlField (UInteger8)

   The value of controlField depends on the message type defined in
   the messageType field (see 13.3.2.2) and shall have the value
   specified in Table 23.

   - IEEE 1588-2008 page 127

The word "shall" has a specific meaning in 1588:

   4.2 Word usage

   4.2.1 Shall

   The word "shall," which is equivalent to "is required to," is used
   to indicate mandatory requirements, strictly to be followed in
   order to conform to the standard and from which no deviation is
   permitted.

   - IEEE 1588-2008 page 9

So setting Announce.control to value 5 is a mandatory requirement.

> The GM has been tested by Calnex too, so conformance is not an issue here.

I can't answer for Calnex, but it is too bad that they allow such
non-conformance to go undeteced.

Thanks,
Richard

Re: [Linuxptp-users] PTP Control Field bug

[Richard C. <ric...@gm...>]

On Wed, Jul 13, 2022 at 01:28:18AM +0000, joy...@ar... wrote:

> Attached PDF document " IEEE Standard for a Precision Clock
> Synchronization Protocol for Networked Measurement and Control
> Systems" from the " IEEE Instrumentation and Measurement Society"
> for your perusal. Please refer to Page 221.

In the future, please do NOT post copyrighted material to this list
that is not freely distributable!

Thanks,
Richard

Re: [Linuxptp-users] PTP Control Field bug

[Richard C. <ric...@gm...>]

On Wed, Jul 13, 2022 at 01:28:18AM +0000, joy...@ar... wrote:

> Even under the erroneous presumption that what you claim is correct,

Sorry, I am going to ignore you now.

As I said before, linuxptp ignores the control field, and so the
control field difference, zero vs five, is likely a red herring.

Thanks,
Richard

Re: [Linuxptp-users] PTP Control Field bug

[Miroslav L. <mli...@re...>]

On Wed, Jul 13, 2022 at 09:29:46AM +0000, joy...@ar... wrote:
> Dear Miroslav,
> 
> Certainly, I have attached packet captures from both cases (controlField 0 and controlField 5).

The captures show other differences than the controlField. The most
suspicious is priority1. It is 0 in the working case and 128 in the
failing case. Have you tried changing that?

-- 
Miroslav Lichvar

Re: [Linuxptp-users] PTP Control Field bug

[Richard C. <ric...@gm...>]

On Thu, Jul 14, 2022 at 02:25:14AM +0000, joy...@ar... wrote:
> It is strange how the ptp4l slave can select a non-conformant GM as best master but not a conformant GM. Unfortunate that such non-conformance would be allowed to go undetected.

Whatever.

Re: [Linuxptp-users] PTP Control Field bug

[Miroslav L. <mli...@re...>]

(I didn't receive the original messages from the list)

> On Fri, Jul 08, 2022 at 01:08:04AM +0000, joy...@ar... wrote:
> > However, it does send delay requests to the GM.
> > Upon close inspection, it turns out that the unless the 'Announce' message control field value is set to '5', the slave does not accept GM as master.

If it's sending delay requests to the server, it means it was already
selected by the client.

> > Is this a bug or can v3.1 be configured to ignore this field?

I just did a test with 3.1 and a modified server sending announce
messages with control of 0 and it works, even with dataset_comparison
set to G.8275.x.

It might help if you could provide a packet capture.

-- 
Miroslav Lichvar