Re: [Linuxptp-devel] [PATCH] ptp4l: version preparation for IEEE 1588-2019
On Thu, Feb 25, 2021 at 12:31:51AM +, Rodney Cummings wrote: > Yangbo asked: > > It seems IEEE 1588-2019 specified minorVersionNumber in portDS, > > but not in PORT_DATA_SET management TLV data field. It's confusing. Oh, now I see what yo meant. Both PORT_DATA_SET and VERSION_NUMBER include only the major version. The upper nibble is still reversed in 1588 v2.1. > That was an oversight. I'll submit a maintenance request to add it. > It'll happen at the blazing fast speeds of IEEE SA process (sarcasm), but > it'll happen eventually. Right, and so the first legitimate non-zero value for the upper nibble will be "2" starting with 1588 v2.2. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] ptp4l: version preparation for IEEE 1588-2019
Thank you all. That's clear about the version:) I sent out a simpler v2 patch with macros used for version. https://sourceforge.net/p/linuxptp/mailman/linuxptp-devel/thread/20210225072041.23458-1-yangbo.lu%40nxp.com/#msg37227104 Best regards, Yangbo Lu > -Original Message- > From: Rodney Cummings > Sent: Thursday, February 25, 2021 8:32 AM > To: Richard Cochran ; Y.b. Lu > > Cc: Linuxptp-devel@lists.sourceforge.net > Subject: RE: Re: [Linuxptp-devel] [PATCH] ptp4l: version preparation for IEEE > 1588-2019 > > Hi folks, > > I'll chime in with some unofficial opinion. > > I agree with everything that Richard says below. 1588 v2.1 is compatible. 1588 > v2.0 implementations ignore the received minorVersionNumber, and will > interoperate just fine if it is received as 1. It is simpler to use macros > for the > versions, and that's conformant. > > Richard asked: > > What is the use case for making the version configurable? > > My educated guess as to why minorVersionNumber is configurable in portDS > is: > In 1588-2008, versionNumber (major version 2) was configurable in > portDS. > For v2.1, when the 1588 group added minorVersionNumber, we probably just > added it to the same location as versionNumber. > Why was it that way in 1588-2008 (v2.0)? > I don't see a strong argument for it personally, but I suppose the 1588 > working group just wanted to allow for maximum flexibility. > In any event, there's nothing that mandates configurability at the port > level. I > think most PTP implementations will use macros at the instance level. > > Yangbo asked: > > It seems IEEE 1588-2019 specified minorVersionNumber in portDS, > > but not in PORT_DATA_SET management TLV data field. It's confusing. > > That was an oversight. I'll submit a maintenance request to add it. > It'll happen at the blazing fast speeds of IEEE SA process (sarcasm), but > it'll > happen eventually. > In the meantime, I think most PTP implementations will report the versions as > read-only from management, so adding minorVersionNumber to > PORT_DATA_SET is a small nice-to-have feature, and there's no problem > skipping it for this patch. > > As an aside, if folks in this list find other bugs in 1588-2019 in the > future, the > 1588 working group recently opened up the maintenance process to folks who > don't attend the meetings: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsa > groups.ieee.org%2F1588%2Fcontact%2Fdata=04%7C01%7Cyangbo.lu% > 40nxp.com%7C7ece806f63404cb9788608d8d924c58b%7C686ea1d3bc2b4c6f > a92cd99c5c301635%7C0%7C0%7C637498099250283906%7CUnknown%7CT > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ > XVCI6Mn0%3D%7C1000sdata=yKWBOzRAu%2BuWhkBcWgQre4L%2B9 > XvHFvFsNMuVhy6P44o%3Dreserved=0 > > Rodney Cummings > IEEE 1588 Vice Chair > > > -----Original Message- > > From: Richard Cochran > > Sent: Wednesday, February 24, 2021 9:18 AM > > To: Y.b. Lu > > Cc: Linuxptp-devel@lists.sourceforge.net > > Subject: [EXTERNAL] Re: [Linuxptp-devel] [PATCH] ptp4l: version > > preparation for IEEE 1588-2019 > > > > On Tue, Feb 23, 2021 at 03:40:38AM +, Y.b. Lu wrote: > > > Considering only 1588, v2.1 is backward compatible. > > > > Yes. > > > > > Regarding to many profiles, I only know 802.1AS... One thing I'm > > > unsure is, if a profile is based on a specific 1588 version, does the > > > message must use the corresponding version in header? > > > > I think that if you implement an optional v2.1 feature (like the security > > extension) then you can and should advertise v2.1 in the header. We > > already have some v2.1 optional stuff, and so we can bump up the version > > number. (I've just been too lazy to do that myself, and so I'm glad you > > are doing it!) > > > > > Should the message header use version v2 for AS-2011 profile, and use > > v2.1 for AS-2020 profile? > > > > No, I don't think the minor version (the X in 2.X) conveys any actionable > > information to the PTP network at run time. There are no practical > > standardized constraints on the use of profiles. Sadly, It is up to the > > administrator to get the settings right. > > > > > Another thing I'm unsure is, whether new version of a profile is also > > backward compatible. I hope yes. > > > > Yes. All 2.x versions are compatible, according to 1588. > > > > > So, may I have your suggestion on how to move ptp4l to v2.1? Do we need > > to implement something like deciding 1588 version per profile in program? > > > > Please, ju
Re: [Linuxptp-devel] [PATCH] ptp4l: version preparation for IEEE 1588-2019
Hi folks, I'll chime in with some unofficial opinion. I agree with everything that Richard says below. 1588 v2.1 is compatible. 1588 v2.0 implementations ignore the received minorVersionNumber, and will interoperate just fine if it is received as 1. It is simpler to use macros for the versions, and that's conformant. Richard asked: > What is the use case for making the version configurable? My educated guess as to why minorVersionNumber is configurable in portDS is: In 1588-2008, versionNumber (major version 2) was configurable in portDS. For v2.1, when the 1588 group added minorVersionNumber, we probably just added it to the same location as versionNumber. Why was it that way in 1588-2008 (v2.0)? I don't see a strong argument for it personally, but I suppose the 1588 working group just wanted to allow for maximum flexibility. In any event, there's nothing that mandates configurability at the port level. I think most PTP implementations will use macros at the instance level. Yangbo asked: > It seems IEEE 1588-2019 specified minorVersionNumber in portDS, > but not in PORT_DATA_SET management TLV data field. It's confusing. That was an oversight. I'll submit a maintenance request to add it. It'll happen at the blazing fast speeds of IEEE SA process (sarcasm), but it'll happen eventually. In the meantime, I think most PTP implementations will report the versions as read-only from management, so adding minorVersionNumber to PORT_DATA_SET is a small nice-to-have feature, and there's no problem skipping it for this patch. As an aside, if folks in this list find other bugs in 1588-2019 in the future, the 1588 working group recently opened up the maintenance process to folks who don't attend the meetings: https://sagroups.ieee.org/1588/contact/ Rodney Cummings IEEE 1588 Vice Chair > -Original Message- > From: Richard Cochran > Sent: Wednesday, February 24, 2021 9:18 AM > To: Y.b. Lu > Cc: Linuxptp-devel@lists.sourceforge.net > Subject: [EXTERNAL] Re: [Linuxptp-devel] [PATCH] ptp4l: version > preparation for IEEE 1588-2019 > > On Tue, Feb 23, 2021 at 03:40:38AM +, Y.b. Lu wrote: > > Considering only 1588, v2.1 is backward compatible. > > Yes. > > > Regarding to many profiles, I only know 802.1AS... One thing I'm > > unsure is, if a profile is based on a specific 1588 version, does the > > message must use the corresponding version in header? > > I think that if you implement an optional v2.1 feature (like the security > extension) then you can and should advertise v2.1 in the header. We > already have some v2.1 optional stuff, and so we can bump up the version > number. (I've just been too lazy to do that myself, and so I'm glad you > are doing it!) > > > Should the message header use version v2 for AS-2011 profile, and use > v2.1 for AS-2020 profile? > > No, I don't think the minor version (the X in 2.X) conveys any actionable > information to the PTP network at run time. There are no practical > standardized constraints on the use of profiles. Sadly, It is up to the > administrator to get the settings right. > > > Another thing I'm unsure is, whether new version of a profile is also > backward compatible. I hope yes. > > Yes. All 2.x versions are compatible, according to 1588. > > > So, may I have your suggestion on how to move ptp4l to v2.1? Do we need > to implement something like deciding 1588 version per profile in program? > > Please, just make the v2.1 as macros, fill out the minor field in the > frames, and forget about dynamic version changes at run time. > > Thanks, > Richard > > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/l > inuxptp-devel__;!!FbZ0ZwI3Qg!6JmeTb- > Ug48qhqib23EZaM53rJjawM92zHIQEYgIOVFFghe8tHHtE2uc7whaVX5tGA$ ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] ptp4l: version preparation for IEEE 1588-2019
On Tue, Feb 23, 2021 at 03:40:38AM +, Y.b. Lu wrote: > Considering only 1588, v2.1 is backward compatible. Yes. > Regarding to many profiles, I only know 802.1AS... One thing I'm > unsure is, if a profile is based on a specific 1588 version, does > the message must use the corresponding version in header? I think that if you implement an optional v2.1 feature (like the security extension) then you can and should advertise v2.1 in the header. We already have some v2.1 optional stuff, and so we can bump up the version number. (I've just been too lazy to do that myself, and so I'm glad you are doing it!) > Should the message header use version v2 for AS-2011 profile, and use v2.1 > for AS-2020 profile? No, I don't think the minor version (the X in 2.X) conveys any actionable information to the PTP network at run time. There are no practical standardized constraints on the use of profiles. Sadly, It is up to the administrator to get the settings right. > Another thing I'm unsure is, whether new version of a profile is also > backward compatible. I hope yes. Yes. All 2.x versions are compatible, according to 1588. > So, may I have your suggestion on how to move ptp4l to v2.1? Do we need to > implement something like deciding 1588 version per profile in program? Please, just make the v2.1 as macros, fill out the minor field in the frames, and forget about dynamic version changes at run time. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] ptp4l: version preparation for IEEE 1588-2019
> -Original Message- > From: Richard Cochran > Sent: Tuesday, February 23, 2021 5:29 AM > To: Luigi 'Comio' Mantellini > Cc: Y.b. Lu ; Linuxptp-devel@lists.sourceforge.net > Subject: Re: [Linuxptp-devel] [PATCH] ptp4l: version preparation for IEEE > 1588-2019 > > On Sun, Feb 21, 2021 at 08:22:59PM +0100, Luigi 'Comio' Mantellini wrote: > > Correct. This is good observation. The 2.1 is backward compatible and I > > don't see any other issue. > > BTW I will give a check to the standard and I will ask to standard experts > > in my company. > > I re-read the v2.1 standard, and AFAICT it says that all current and > future version 2.x implementations are compatible, provided that you > don't use optional features. > > Since the minor version does not tell you _anything_ about which > optional features are in use, then I think we can safely ignore the > minor version field. I think my patch may provide a bad idea making version configurable, after seeing all your comments:) Sorry for that. Considering only 1588, v2.1 is backward compatible. Regarding to many profiles, I only know 802.1AS... One thing I'm unsure is, if a profile is based on a specific 1588 version, does the message must use the corresponding version in header? For example, 802.1AS-2011 is a profile of 1588-2008, and 802.1AS-2020 is a profile of 1588-2019. Should the message header use version v2 for AS-2011 profile, and use v2.1 for AS-2020 profile? Another thing I'm unsure is, whether new version of a profile is also backward compatible. I hope yes. So, may I have your suggestion on how to move ptp4l to v2.1? Do we need to implement something like deciding 1588 version per profile in program? Thank you very much. > > Thanks, > Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] ptp4l: version preparation for IEEE 1588-2019
On Sun, Feb 21, 2021 at 08:22:59PM +0100, Luigi 'Comio' Mantellini wrote: > Correct. This is good observation. The 2.1 is backward compatible and I > don't see any other issue. > BTW I will give a check to the standard and I will ask to standard experts > in my company. I re-read the v2.1 standard, and AFAICT it says that all current and future version 2.x implementations are compatible, provided that you don't use optional features. Since the minor version does not tell you _anything_ about which optional features are in use, then I think we can safely ignore the minor version field. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] ptp4l: version preparation for IEEE 1588-2019
Correct. This is good observation. The 2.1 is backward compatible and I don't see any other issue. BTW I will give a check to the standard and I will ask to standard experts in my company. Luigi Il dom 21 feb 2021, 20:18 Richard Cochran ha scritto: > On Sun, Feb 21, 2021 at 08:10:48PM +0100, Luigi 'Comio' Mantellini wrote: > > The only use case that I can suppose is an old device into the network > that > > doesn't handle the new protocol version and we need to accommodate. For > > this reason I was asking to handle at port level. > > But older devices cannot reject frames with minor version .1 because > that field did not exist in version v2.0, right? > > Thanks, > Richard > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] ptp4l: version preparation for IEEE 1588-2019
On Sun, Feb 21, 2021 at 08:10:48PM +0100, Luigi 'Comio' Mantellini wrote: > The only use case that I can suppose is an old device into the network that > doesn't handle the new protocol version and we need to accommodate. For > this reason I was asking to handle at port level. But older devices cannot reject frames with minor version .1 because that field did not exist in version v2.0, right? Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] ptp4l: version preparation for IEEE 1588-2019
The only use case that I can suppose is an old device into the network that doesn't handle the new protocol version and we need to accommodate. For this reason I was asking to handle at port level. Luigi Il dom 21 feb 2021, 19:56 Richard Cochran ha scritto: > On Sun, Feb 21, 2021 at 07:05:26PM +0100, Luigi 'Comio' Mantellini wrote: > > I will suggest to offer two enums to handle 2 or 2.1. > > If a justification can be found for "downgrading" the advertised > version, then yes, it would be better to enumerate the actual released > and supported versions. > > > I have a question: is it insane to offer different version on port basis? > > Yes, possibly - but again, what is the use case for not always saying v2.1? > > Thanks, > Richard > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] ptp4l: version preparation for IEEE 1588-2019
On Sun, Feb 21, 2021 at 07:05:26PM +0100, Luigi 'Comio' Mantellini wrote: > I will suggest to offer two enums to handle 2 or 2.1. If a justification can be found for "downgrading" the advertised version, then yes, it would be better to enumerate the actual released and supported versions. > I have a question: is it insane to offer different version on port basis? Yes, possibly - but again, what is the use case for not always saying v2.1? Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] ptp4l: version preparation for IEEE 1588-2019
HI, I will suggest to offer two enums to handle 2 or 2.1. I have a question: is it insane to offer different version on port basis? Ciao Luigi Il dom 21 feb 2021, 16:34 Richard Cochran ha scritto: > On Sat, Feb 20, 2021 at 02:26:44PM +0800, Yangbo Lu wrote: > > IEEE 1588-2019 specified new UInteger4 type minorVersionPTP field in > header, > > and minorVersionNumber data in portDS. It has the value 1 for IEEE > 1588-2019, > > and has the value 0 for IEEE 1588-2008. > > I'd like to let the stack advertise the verion upgrade, since it does, > in fact, comply. > > > This patch is to make versionNumber and minorVersionNumber configurable, > rather > > than using hard-coded IEEE 1588-2008 version, for PTP packets. > > However I don't understand why this must be configurable. The user > should not be free to claim, for example, version 2.5 compliance. > > What is the use case for making the version configurable? > > Thanks, > Richard > > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] ptp4l: version preparation for IEEE 1588-2019
On Sat, Feb 20, 2021 at 02:26:44PM +0800, Yangbo Lu wrote: > IEEE 1588-2019 specified new UInteger4 type minorVersionPTP field in header, > and minorVersionNumber data in portDS. It has the value 1 for IEEE 1588-2019, > and has the value 0 for IEEE 1588-2008. I'd like to let the stack advertise the verion upgrade, since it does, in fact, comply. > This patch is to make versionNumber and minorVersionNumber configurable, > rather > than using hard-coded IEEE 1588-2008 version, for PTP packets. However I don't understand why this must be configurable. The user should not be free to claim, for example, version 2.5 compliance. What is the use case for making the version configurable? Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] ptp4l: version preparation for IEEE 1588-2019
Am 2021-02-20 07:26, schrieb Yangbo Lu: IEEE 1588-2019 specified new UInteger4 type minorVersionPTP field in header, and minorVersionNumber data in portDS. It has the value 1 for IEEE 1588-2019, and has the value 0 for IEEE 1588-2008. This patch is to make versionNumber and minorVersionNumber configurable, rather than using hard-coded IEEE 1588-2008 version, for PTP packets. This is just preparation for future features support and profiles support based on IEEE 1588-2019. It seems IEEE 1588-2019 specified minorVersionNumber in portDS, but not in PORT_DATA_SET management TLV data field. It's confusing. So this patch hasn't added the minorVersionNumber in portDS making this as a TODO thing. If there will be support for the new profile, wouldn't the user choose this profile and ptp4l will change the version automatically? -michael ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] ptp4l: version preparation for IEEE 1588-2019
Wow. Didn't realize there was an update to 1588. Is there a draft anywhere I can get instead of the $280 published spec? Is there a summary of the changes anywhere? I found this: https://blog.meinbergglobal.com/2019/11/14/whats-coming-in-the-new-edition-of-ieee-1588-performance-monitoring/ Thanks! -Dale ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH] ptp4l: version preparation for IEEE 1588-2019
IEEE 1588-2019 specified new UInteger4 type minorVersionPTP field in header,
and minorVersionNumber data in portDS. It has the value 1 for IEEE 1588-2019,
and has the value 0 for IEEE 1588-2008.
This patch is to make versionNumber and minorVersionNumber configurable, rather
than using hard-coded IEEE 1588-2008 version, for PTP packets.
This is just preparation for future features support and profiles support based
on IEEE 1588-2019.
It seems IEEE 1588-2019 specified minorVersionNumber in portDS, but not in
PORT_DATA_SET management TLV data field. It's confusing. So this patch hasn't
added the minorVersionNumber in portDS making this as a TODO thing.
Signed-off-by: Yangbo Lu
---
config.c| 2 ++
configs/default.cfg | 2 ++
msg.c | 5 +
msg.h | 5 +++--
port.c | 23 +--
port_private.h | 3 ++-
port_signaling.c| 2 +-
ptp4l.8 | 8
8 files changed, 32 insertions(+), 18 deletions(-)
diff --git a/config.c b/config.c
index 341f887..69cfb10 100644
--- a/config.c
+++ b/config.c
@@ -273,6 +273,7 @@ struct config_item config_tab[] = {
GLOB_ITEM_STR("manufacturerIdentity", "00:00:00"),
GLOB_ITEM_INT("max_frequency", 9, 0, INT_MAX),
PORT_ITEM_INT("min_neighbor_prop_delay", -2000, INT_MIN, -1),
+ PORT_ITEM_INT("minorVersionNumber", 0, 0, 1),
PORT_ITEM_INT("msg_interval_request", 0, 0, 1),
PORT_ITEM_INT("neighborPropDelayThresh", 2000, 0, INT_MAX),
PORT_ITEM_INT("net_sync_monitor", 0, 0, 1),
@@ -332,6 +333,7 @@ struct config_item config_tab[] = {
GLOB_ITEM_STR("userDescription", ""),
GLOB_ITEM_INT("utc_offset", CURRENT_UTC_OFFSET, 0, INT_MAX),
GLOB_ITEM_INT("verbose", 0, 0, 1),
+ PORT_ITEM_INT("versionNumber", 2, 2, 2),
GLOB_ITEM_INT("write_phase_mode", 0, 0, 1),
};
diff --git a/configs/default.cfg b/configs/default.cfg
index 9604219..139ace0 100644
--- a/configs/default.cfg
+++ b/configs/default.cfg
@@ -40,6 +40,8 @@ BMCAptp
inhibit_announce0
inhibit_delay_req 0
ignore_source_id0
+versionNumber 2
+minorVersionNumber 0
#
# Run time options
#
diff --git a/msg.c b/msg.c
index d1619d4..a2f0567 100644
--- a/msg.c
+++ b/msg.c
@@ -27,9 +27,6 @@
#include "print.h"
#include "tlv.h"
-#define VERSION_MASK 0x0f
-#define VERSION 0x02
-
int assume_two_step = 0;
/*
@@ -80,7 +77,7 @@ static void announce_post_recv(struct announce_msg *m)
static int hdr_post_recv(struct ptp_header *m)
{
- if ((m->ver & VERSION_MASK) != VERSION)
+ if ((m->ver & VERSION_MASK) != PTP_VERSION)
return -EPROTO;
m->messageLength = ntohs(m->messageLength);
m->correction = net2host64(m->correction);
diff --git a/msg.h b/msg.h
index a71df16..469f2ac 100644
--- a/msg.h
+++ b/msg.h
@@ -30,7 +30,8 @@
#include "tlv.h"
#include "tmv.h"
-#define PTP_VERSION 2
+#define PTP_VERSION2 /* This is major revision */
+#define VERSION_MASK 0x0f
/* Values for the messageType field */
#define SYNC 0x0
@@ -89,7 +90,7 @@ enum controlField {
struct ptp_header {
uint8_t tsmt; /* transportSpecific | messageType */
- uint8_t ver; /* reserved | versionPTP */
+ uint8_t ver; /* minorVersionPTP | versionPTP */
UInteger16 messageLength;
UInteger8 domainNumber;
Octet reserved1;
diff --git a/port.c b/port.c
index 2bb974c..6423484 100644
--- a/port.c
+++ b/port.c
@@ -1353,7 +1353,7 @@ static int port_pdelay_request(struct port *p)
msg->hwts.type = p->timestamping;
msg->header.tsmt = PDELAY_REQ | p->transportSpecific;
- msg->header.ver= PTP_VERSION;
+ msg->header.ver= p->minorVersionNumber << 4 |
p->versionNumber;
msg->header.messageLength = sizeof(struct pdelay_req_msg);
msg->header.domainNumber = clock_domain_number(p->clock);
msg->header.correction = -p->asymmetry;
@@ -1417,7 +1417,7 @@ int port_delay_request(struct port *p)
msg->hwts.type = p->timestamping;
msg->header.tsmt = DELAY_REQ | p->transportSpecific;
- msg->header.ver= PTP_VERSION;
+ msg->header.ver= p->minorVersionNumber << 4 |
p->versionNumber;
msg->header.messageLength = sizeof(struct delay_req_msg);
msg->header.domainNumber = clock_domain_number(p->clock);
msg->header.correction = -p->asymmetry;
@@ -1470,7 +1470,7 @@ int port_tx_announce(struct port *p, struct address *dst)
msg->hwts.type = p->timestamping;
msg->header.tsmt = ANNOUNCE | p->transportSpecific;
- msg->header.ver= PTP_VERSION;
+ msg->header.ver=
