[Linuxptp-devel] [PATCH 1/1] msg: append TLV onto all PTP event messages
According to IEEE Std 1588-2019 Chapter 6.4 PTP message classes,
all PTP messages can be extended by means of a standard
Type, Length, Value (TLV) extension mechanism.
Signed-off-by: Tan Tee Min
---
msg.c | 6 +++---
msg.h | 3 +++
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/msg.c b/msg.c
index c2d358b..ab841f0 100644
--- a/msg.c
+++ b/msg.c
@@ -100,13 +100,13 @@ static uint8_t *msg_suffix(struct ptp_message *m)
{
switch (msg_type(m)) {
case SYNC:
- return NULL;
+ return m->sync.suffix;
case DELAY_REQ:
return m->delay_req.suffix;
case PDELAY_REQ:
- return NULL;
+ return m->pdelay_req.suffix;
case PDELAY_RESP:
- return NULL;
+ return m->pdelay_resp.suffix;
case FOLLOW_UP:
return m->follow_up.suffix;
case DELAY_RESP:
diff --git a/msg.h b/msg.h
index b7423ee..e3744dc 100644
--- a/msg.h
+++ b/msg.h
@@ -124,6 +124,7 @@ struct announce_msg {
struct sync_msg {
struct ptp_header hdr;
struct TimestamporiginTimestamp;
+ uint8_t suffix[0];
} PACKED;
struct delay_req_msg {
@@ -149,12 +150,14 @@ struct pdelay_req_msg {
struct ptp_header hdr;
struct TimestamporiginTimestamp;
struct PortIdentity reserved;
+ uint8_t suffix[0];
} PACKED;
struct pdelay_resp_msg {
struct ptp_header hdr;
struct TimestamprequestReceiptTimestamp;
struct PortIdentity requestingPortIdentity;
+ uint8_t suffix[0];
} PACKED;
struct pdelay_resp_fup_msg {
--
1.9.1
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 1/1] port: add ptpTimescale to the flag field for 802.1AS-2011
On Fri, Feb 24, 2023 at 07:37:35AM -0800, Richard Cochran wrote: > On Fri, Feb 24, 2023 at 02:25:03PM +, Woojung.Huh--- via Linuxptp-devel > wrote: > > > Agree that 802.1AS-2011 and 802.1AS-2021-Cor1 are marked as All for > > ptpTimescale. > > However, this is updated (fixed) in 802.1AS-2020 to message type "Announce" > > which aligns to 1588-2008 and 1588-2019. > > May need second eye to confirm which direction is right way to do. > > This is clearly a bug in 802.1AS-2011. There are a bunch of other > obvious mistakes in that publication. > > Thanks, > Richard Thanks alot Woojung and Richard for the comments! I agree with your statement. Kindly discard this patch. Thanks, Tee Min ___ 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 v6 00/10] Dynamic sync direction for ts2phc
On Tue, Feb 28, 2023 at 12:03:15PM +0100, Maciek Machnikowski wrote: > Can we add it to the configs/ts2phc*.cfg for the 4.0 release? That is not a critical bug, IMO. 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, 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 v6 00/10] Dynamic sync direction for ts2phc
On 31/08/2022 01:12, Vladimir Oltean wrote > In text, it would be described as this: > > cat ts2phc.cfg > [global] > first_step_threshold0.2 > step_threshold 0.2 > ts2phc.pulsewidth 5 > ts2phc.perout_phase 0 > > # Felix > [/dev/ptp1] > ts2phc.master 1 > > # SJA1105 switch 1 > [/dev/ptp2] > ts2phc.channel 0 > ts2phc.extts_polarity both > > # SJA1105 switch 2 > [/dev/ptp3] > ts2phc.channel 0 > ts2phc.extts_polarity both > > # SJA1105 switch 3 > [/dev/ptp4] > ts2phc.channel 0 > ts2phc.extts_polarity both > > cat gPTP.cfg > [global] > gmCapable 1 > priority1 248 > priority2 248 > logAnnounceInterval 0 > logSyncInterval -3 > syncReceiptTimeout 3 > neighborPropDelayThresh 5 > min_neighbor_prop_delay -2000 > assume_two_step 1 > path_trace_enabled 1 > follow_up_info 1 > transportSpecific 0x1 > ptp_dst_mac 01:80:C2:00:00:0E > network_transport L2 > delay_mechanism P2P > step_threshold 0.2 > tx_timestamp_timeout20 > boundary_clock_jbod 1 > > [sw1p0] > [sw1p1] > [sw1p2] > [sw1p3] > [sw2p0] > [sw2p1] > [sw2p2] > [sw2p3] > [sw3p0] > [sw3p1] > [sw3p2] > [sw3p3] I just got back to this patch series and realized that this config file didn't make it to the example configs. Can we add it to the configs/ts2phc*.cfg for the 4.0 release? Thanks, Maciek ___ 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;
>
