Re: [Linuxptp-devel] [PATCH] Set controlField to zero in message headers
On Thu, Mar 16, 2023 at 02:58:33PM +0100, Andrew Zaborowski wrote: > I was now made aware that Avnu conformance tests for 802.1AS-2011 do > validate the 3 different values required in the control field in that > version of IEEE802.1AS. While 1588-2008 did already say that the use > of this field on the receiver is "deprecated", 802.1AS-2011 does not > say anything like this. There's value for Avnu in having an option to > go back to those values and perhaps shipping a "gPTP-2011.cfg" file > with that option enabled. Would you be open to have this upstream? That was twelve years ago. We needn't take such an overly pedantic test seriously. I'll just update the home page to say, "supports 802.1AS-2020". Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Set controlField to zero in message headers
On Tue, 28 Feb 2023 at 22:08, Richard Cochran wrote: > On Tue, Feb 28, 2023 at 07:38:44PM +0100, Andrew Zaborowski wrote: > > On Tue, 28 Feb 2023 at 16:02, Richard Cochran > > wrote: > > > In the case of the PTP minor version field, there are already two > > > known bad HW devices that fail when the field is non-zero. Of course, > > > this violates 1588-2008, but it proves the point that vendors don't > > > follow the standard. > > > > Ok, that was a concern but I didn't know how likely it would be. > > Given this would you agree to zeroing those values based on a setting? > > No, I just wanted to point out the risk. So far, HW vendors track > record has been abysmal. If there is a way to do wrong, then somebody > sure will. (That's consistent with a lot of protocol standards unfortunately) > > The SW should zero the controlField unconditionally as called out in > 1588-2019 clause 13.3.2.13. Previously I overlooked this silly detail > because the change is not identified in 19.4 "Compatibility ... to > IEEE Std 1588-2008". I was now made aware that Avnu conformance tests for 802.1AS-2011 do validate the 3 different values required in the control field in that version of IEEE802.1AS. While 1588-2008 did already say that the use of this field on the receiver is "deprecated", 802.1AS-2011 does not say anything like this. There's value for Avnu in having an option to go back to those values and perhaps shipping a "gPTP-2011.cfg" file with that option enabled. Would you be open to have this upstream? The difference with the minVersionPTP field is that that one was reserved in 802.1AS-2011 so it's not being validated. Best regards ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Set controlField to zero in message headers
On Tue, Feb 28, 2023 at 07:38:44PM +0100, Andrew Zaborowski wrote: > Hi Richard and Erez, > > On Tue, 28 Feb 2023 at 16:02, Richard Cochran > wrote: > > On Tue, Feb 28, 2023 at 09:36:07AM +0100, Erez wrote: > > > May break when using non Linuxptp, as far as I understand, linuxptp only > > > sets the field, but never checks the value. > > > > The risk is that some hardware implementations may check those fields > > and then fail to generate time stamps. > > > > In the case of the PTP minor version field, there are already two > > known bad HW devices that fail when the field is non-zero. Of course, > > this violates 1588-2008, but it proves the point that vendors don't > > follow the standard. > > Ok, that was a concern but I didn't know how likely it would be. > Given this would you agree to zeroing those values based on a setting? No, I just wanted to point out the risk. So far, HW vendors track record has been abysmal. If there is a way to do wrong, then somebody sure will. The SW should zero the controlField unconditionally as called out in 1588-2019 clause 13.3.2.13. Previously I overlooked this silly detail because the change is not identified in 19.4 "Compatibility ... to IEEE Std 1588-2008". Anyhow, since we advertise PTP v2.1 then we should really clear the controlField. As a general rule, linuxptp doesn't make special hacks for broken hardware designs. I want this change in linuxptp version 4.0 together with the PTP 2.1 version bump, and so that will delay the release to allow some minimum soak time. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Set controlField to zero in message headers
Hi Richard and Erez, On Tue, 28 Feb 2023 at 16:02, Richard Cochran wrote: > On Tue, Feb 28, 2023 at 09:36:07AM +0100, Erez wrote: > > May break when using non Linuxptp, as far as I understand, linuxptp only > > sets the field, but never checks the value. > > The risk is that some hardware implementations may check those fields > and then fail to generate time stamps. > > In the case of the PTP minor version field, there are already two > known bad HW devices that fail when the field is non-zero. Of course, > this violates 1588-2008, but it proves the point that vendors don't > follow the standard. Ok, that was a concern but I didn't know how likely it would be. Given this would you agree to zeroing those values based on a setting? If so would it need to default to preserve the 1588-2008 values or do you expect those customers are ok changing their configs? Best regards ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Set controlField to zero in message headers
On Tue, Feb 28, 2023 at 09:36:07AM +0100, Erez wrote: > On Tue, 28 Feb 2023 at 01:49, Andrew Zaborowski > > Since the default behaviour changes, in principle this could break > > > > May break when using non Linuxptp, as far as I understand, linuxptp only > sets the field, but never checks the value. The risk is that some hardware implementations may check those fields and then fail to generate time stamps. In the case of the PTP minor version field, there are already two known bad HW devices that fail when the field is non-zero. Of course, this violates 1588-2008, but it proves the point that vendors don't follow the standard. As a result, customers of those vendors get on our list and complain the linuxptp is broken! Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Set controlField to zero in message headers
On Tue, 28 Feb 2023 at 01:49, Andrew Zaborowski
wrote:
> From: Christopher S M Hall
>
> IEEE1588-2019 and 802.1AS-2020 both require the field to be 0 in
> transmitted messages except when the "version 1 hardware option" is set
> (IEEE1588-2019 C.4.2) and only with IPv4. Since ptp4l isn't padding
> the UDP messages to 124 bytes as required for compatibility with the
> "V.1 Hardware" implementations, assume that we're not dealing with such
> hardware, do not implement the option as defined in C.4.2.
>
Make sense.
Why not clean it all?
There are more places that assign the controlField.
$ git grep -l 'header.control\s*='
nsm.c
pmc_common.c
port_signaling.c
tc.c
> Since the default behaviour changes, in principle this could break
>
May break when using non Linuxptp, as far as I understand, linuxptp only
sets the field, but never checks the value.
Anyhow we do not support PTP version 1 hardware,
so perhaps it is better to break faster :-)
Erez
things. It is similar to 2a2532d66121 ("Bump to IEEE 1588-2019 version")
> however, where ptp4l switches the version field to the IEEE1588-2019
> value.
>
> Signed-off-by: Andrew Zaborowski
> ---
> The original patch added a per-port v1_hw_support option that would
> force the previous controlField values but it wasn't implementing the
> rest of the C.4.2 logic so with no indication that there's a use case
> for such partial support and no mention in the specification, I dropped
> it.
>
> port.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/port.c b/port.c
> index 3453716..76f817c 100644
> --- a/port.c
> +++ b/port.c
> @@ -1544,7 +1544,6 @@ static int port_pdelay_request(struct port *p)
> msg->header.correction = -p->asymmetry;
> msg->header.sourcePortIdentity = p->portIdentity;
> msg->header.sequenceId = p->seqnum.delayreq++;
> - msg->header.control= CTL_OTHER;
> msg->header.logMessageInterval = port_is_ieee8021as(p) ?
> p->logPdelayReqInterval : 0x7f;
>
> @@ -1608,7 +1607,6 @@ int port_delay_request(struct port *p)
> msg->header.correction = -p->asymmetry;
> msg->header.sourcePortIdentity = p->portIdentity;
> msg->header.sequenceId = p->seqnum.delayreq++;
> - msg->header.control= CTL_DELAY_REQ;
> msg->header.logMessageInterval = 0x7f;
>
> if (p->hybrid_e2e) {
> @@ -1660,7 +1658,6 @@ int port_tx_announce(struct port *p, struct address
> *dst, uint16_t sequence_id)
> msg->header.domainNumber = clock_domain_number(p->clock);
> msg->header.sourcePortIdentity = p->portIdentity;
> msg->header.sequenceId = sequence_id;
> - msg->header.control= CTL_OTHER;
> msg->header.logMessageInterval = p->logAnnounceInterval;
>
> msg->header.flagField[1] = tp.flags;
> @@ -1743,7 +1740,6 @@ int port_tx_sync(struct port *p, struct address
> *dst, uint16_t sequence_id)
> msg->header.domainNumber = clock_domain_number(p->clock);
> msg->header.sourcePortIdentity = p->portIdentity;
> msg->header.sequenceId = sequence_id;
> - msg->header.control= CTL_SYNC;
> msg->header.logMessageInterval = p->logSyncInterval;
>
> if (p->timestamping != TS_ONESTEP && p->timestamping !=
> TS_P2P1STEP) {
> @@ -1779,7 +1775,6 @@ int port_tx_sync(struct port *p, struct address
> *dst, uint16_t sequence_id)
> fup->header.domainNumber = clock_domain_number(p->clock);
> fup->header.sourcePortIdentity = p->portIdentity;
> fup->header.sequenceId = sequence_id;
> - fup->header.control= CTL_FOLLOW_UP;
> fup->header.logMessageInterval = p->logSyncInterval;
>
> fup->follow_up.preciseOriginTimestamp =
> tmv_to_Timestamp(msg->hwts.ts);
> @@ -2130,7 +2125,6 @@ static int process_delay_req(struct port *p, struct
> ptp_message *m)
> msg->header.correction = m->header.correction;
> msg->header.sourcePortIdentity = p->portIdentity;
> msg->header.sequenceId = m->header.sequenceId;
> - msg->header.control= CTL_DELAY_RESP;
> msg->header.logMessageInterval = p->logMinDelayReqInterval;
>
> msg->delay_resp.receiveTimestamp = tmv_to_Timestamp(m->hwts.ts);
> @@ -2321,7 +2315,6 @@ int process_pdelay_req(struct port *p, struct
> ptp_message *m)
> rsp->header.domainNumber = m->header.domainNumber;
> rsp->header.sourcePortIdentity = p->portIdentity;
> rsp->header.sequenceId = m->header.sequenceId;
> - rsp->header.control= CTL_OTHER;
> rsp->header.logMessageInterval = 0x7f;
>
> /*
> @@ -2369,7 +2362,6 @@ int process_pdelay_req(struct port *p, struct
> ptp_message *m)
> fup->header.correction = m->header.correction;
> fup->header.sourcePortIdentity = p->portIdentity;
>
[Linuxptp-devel] [PATCH] Set controlField to zero in message headers
From: Christopher S M Hall
IEEE1588-2019 and 802.1AS-2020 both require the field to be 0 in
transmitted messages except when the "version 1 hardware option" is set
(IEEE1588-2019 C.4.2) and only with IPv4. Since ptp4l isn't padding
the UDP messages to 124 bytes as required for compatibility with the
"V.1 Hardware" implementations, assume that we're not dealing with such
hardware, do not implement the option as defined in C.4.2.
Since the default behaviour changes, in principle this could break
things. It is similar to 2a2532d66121 ("Bump to IEEE 1588-2019 version")
however, where ptp4l switches the version field to the IEEE1588-2019
value.
Signed-off-by: Andrew Zaborowski
---
The original patch added a per-port v1_hw_support option that would
force the previous controlField values but it wasn't implementing the
rest of the C.4.2 logic so with no indication that there's a use case
for such partial support and no mention in the specification, I dropped
it.
port.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/port.c b/port.c
index 3453716..76f817c 100644
--- a/port.c
+++ b/port.c
@@ -1544,7 +1544,6 @@ static int port_pdelay_request(struct port *p)
msg->header.correction = -p->asymmetry;
msg->header.sourcePortIdentity = p->portIdentity;
msg->header.sequenceId = p->seqnum.delayreq++;
- msg->header.control= CTL_OTHER;
msg->header.logMessageInterval = port_is_ieee8021as(p) ?
p->logPdelayReqInterval : 0x7f;
@@ -1608,7 +1607,6 @@ int port_delay_request(struct port *p)
msg->header.correction = -p->asymmetry;
msg->header.sourcePortIdentity = p->portIdentity;
msg->header.sequenceId = p->seqnum.delayreq++;
- msg->header.control= CTL_DELAY_REQ;
msg->header.logMessageInterval = 0x7f;
if (p->hybrid_e2e) {
@@ -1660,7 +1658,6 @@ int port_tx_announce(struct port *p, struct address *dst,
uint16_t sequence_id)
msg->header.domainNumber = clock_domain_number(p->clock);
msg->header.sourcePortIdentity = p->portIdentity;
msg->header.sequenceId = sequence_id;
- msg->header.control= CTL_OTHER;
msg->header.logMessageInterval = p->logAnnounceInterval;
msg->header.flagField[1] = tp.flags;
@@ -1743,7 +1740,6 @@ int port_tx_sync(struct port *p, struct address *dst,
uint16_t sequence_id)
msg->header.domainNumber = clock_domain_number(p->clock);
msg->header.sourcePortIdentity = p->portIdentity;
msg->header.sequenceId = sequence_id;
- msg->header.control= CTL_SYNC;
msg->header.logMessageInterval = p->logSyncInterval;
if (p->timestamping != TS_ONESTEP && p->timestamping != TS_P2P1STEP) {
@@ -1779,7 +1775,6 @@ int port_tx_sync(struct port *p, struct address *dst,
uint16_t sequence_id)
fup->header.domainNumber = clock_domain_number(p->clock);
fup->header.sourcePortIdentity = p->portIdentity;
fup->header.sequenceId = sequence_id;
- fup->header.control= CTL_FOLLOW_UP;
fup->header.logMessageInterval = p->logSyncInterval;
fup->follow_up.preciseOriginTimestamp = tmv_to_Timestamp(msg->hwts.ts);
@@ -2130,7 +2125,6 @@ static int process_delay_req(struct port *p, struct
ptp_message *m)
msg->header.correction = m->header.correction;
msg->header.sourcePortIdentity = p->portIdentity;
msg->header.sequenceId = m->header.sequenceId;
- msg->header.control= CTL_DELAY_RESP;
msg->header.logMessageInterval = p->logMinDelayReqInterval;
msg->delay_resp.receiveTimestamp = tmv_to_Timestamp(m->hwts.ts);
@@ -2321,7 +2315,6 @@ int process_pdelay_req(struct port *p, struct ptp_message
*m)
rsp->header.domainNumber = m->header.domainNumber;
rsp->header.sourcePortIdentity = p->portIdentity;
rsp->header.sequenceId = m->header.sequenceId;
- rsp->header.control= CTL_OTHER;
rsp->header.logMessageInterval = 0x7f;
/*
@@ -2369,7 +2362,6 @@ int process_pdelay_req(struct port *p, struct ptp_message
*m)
fup->header.correction = m->header.correction;
fup->header.sourcePortIdentity = p->portIdentity;
fup->header.sequenceId = m->header.sequenceId;
- fup->header.control= CTL_OTHER;
fup->header.logMessageInterval = 0x7f;
fup->pdelay_resp_fup.requestingPortIdentity =
m->header.sourcePortIdentity;
@@ -3210,7 +3202,6 @@ port_management_construct(struct PortIdentity pid, struct
port *ingress,
msg->header.domainNumber = clock_domain_number(ingress->clock);
msg->header.sourcePortIdentity = pid;
msg->header.sequenceId = sequenceId;
- msg->header.control= CTL_MANAGEMENT;
msg->header.logMessageInterval =
