Re: [Linuxptp-devel] [PATCH] Only forward responses to UDS port with corresponding requests on the UDS port, and always send with a unique sequence count from uds.
Thank you, Erez. I can see now how to use interactive mode. I suggest considering documenting this in the manpages and the help for pmc. Some examples in the manpages would be helpful. Eric Decker -Original Message- From: Geva, Erez Sent: Thursday, August 19, 2021 5:19 AM To: Eric Decker Cc: linuxptp-devel@lists.sourceforge.net; Richard Cochran Subject: RE: [Linuxptp-devel] [PATCH] Only forward responses to UDS port with corresponding requests on the UDS port, and always send with a unique sequence count from uds. Hi, Entering the pmc tool interactive mode is simple. Run the pmc tool without a management command. For example: Using direct mode: # pmc -u -f /etc/linuxptp/ptp4l.conf 'get VERSION_NUMBER' 'get PRIORITY1' Using interactive mode: # pmc -u -f /etc/linuxptp/ptp4l.conf Now you can enter: get VERSION_NUMBER Regarding the https://sf.net/projects/libpmc project. It is a separate project, aim to provide a pmc library with LGPL licence. Sort of filling the gap. Both the pmc tool and the libpmc uses standard IEEE 1558 management messages, and can be used with any IEEE 1558 entity that supports IEEE 1558 management messages. :-) Erez -Original Message- From: Eric Decker Sent: Thursday, 19 August 2021 04:56 To: Geva, Erez (ext) (DI PA DCP R 3) Cc: linuxptp-devel@lists.sourceforge.net; Richard Cochran Subject: RE: [Linuxptp-devel] [PATCH] Only forward responses to UDS port with corresponding requests on the UDS port, and always send with a unique sequence count from uds. Hi Erez, I thought it might be better to take this part of the conversation offline, but maybe it will benefit others. How do you run pmc in interactive mode? I do not see that in the documentation. What is libpmc? Is it a part of the standard Linux PTP distribution, or is it a supplement to it? Would others people be aware it is available? I thought I reviewed all of the documentation and I never heard of it. Thanks, Eric Decker -Original Message- From: Geva, Erez Sent: Wednesday, August 18, 2021 8:37 PM To: Eric Decker Cc: linuxptp-devel@lists.sourceforge.net; Richard Cochran Subject: RE: [Linuxptp-devel] [PATCH] Only forward responses to UDS port with corresponding requests on the UDS port, and always send with a unique sequence count from uds. Hi, Regarding: "pmc executes as a new process each time it is called". 1. No you can run the pmc tool in interactive mode. Then send new requests, line by line and with increasing the sequence ID. 2. You can use the libpmc library https://sf.net/projects/libpmc, The library allow you to set any sequence ID you wish. I do not see why is that an issue for the ptp4l project. Erez -Original Message----- From: Eric Decker Sent: Wednesday, 18 August 2021 19:26 To: Richard Cochran Cc: linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [PATCH] Only forward responses to UDS port with corresponding requests on the UDS port, and always send with a unique sequence count from uds. Response below tagged as EDecker: Eric Decker -Original Message- From: Richard Cochran Sent: Wednesday, August 18, 2021 12:23 PM To: Eric Decker Cc: linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [PATCH] Only forward responses to UDS port with corresponding requests on the UDS port, and always send with a unique sequence count from uds. On Mon, Aug 16, 2021 at 03:38:21PM +0000, Eric Decker wrote: > Subject: [PATCH] Only forward responses to UDS port with corresponding > requests on the UDS port, and always send management with a unique sequence > count from uds. The subject line should be ONE sentence, please. EDecker: It is one sentence. > > 1. Only forward responses to UDS port with a corresponding requests on > the UDS port. This is one "issue", and you have a second issue, below. That means you should make (at least) two patches that address the issues independently. > When ptp4l is configured as a boundary clock and a host on ethernet is > issuing excessive management requests (a PTP monitoring tool) then the > requests get forwarded across the boundary clock and the subsequent > responses get forwarded to the UDS port. The UDS code sends messages > to the uds address of the last process it received a message from. > The phc2sys daemon is not expecting these responses which causes its > receive buffers to get full and then the ptp4l send buffers get full > which causes ptp4l to lock until phc2sys reads the messages from its > uds port. ptp4l will lock until phc2sys reads messages from the uds > port which happens every 60sec. So the proper fix would be to ensure the ptp4l's write() is non blocking. EDecker: I wonder if that approach would have unexpected consequences. > How the proposed solution fixes the problem: > > Ptp4l will only forward ptp management response messag
Re: [Linuxptp-devel] [PATCH] Only forward responses to UDS port with corresponding requests on the UDS port, and always send with a unique sequence count from uds.
Hi Erez, I thought it might be better to take this part of the conversation offline, but maybe it will benefit others. How do you run pmc in interactive mode? I do not see that in the documentation. What is libpmc? Is it a part of the standard Linux PTP distribution, or is it a supplement to it? Would others people be aware it is available? I thought I reviewed all of the documentation and I never heard of it. Thanks, Eric Decker -Original Message- From: Geva, Erez Sent: Wednesday, August 18, 2021 8:37 PM To: Eric Decker Cc: linuxptp-devel@lists.sourceforge.net; Richard Cochran Subject: RE: [Linuxptp-devel] [PATCH] Only forward responses to UDS port with corresponding requests on the UDS port, and always send with a unique sequence count from uds. Hi, Regarding: "pmc executes as a new process each time it is called". 1. No you can run the pmc tool in interactive mode. Then send new requests, line by line and with increasing the sequence ID. 2. You can use the libpmc library https://sf.net/projects/libpmc/, The library allow you to set any sequence ID you wish. I do not see why is that an issue for the ptp4l project. Erez -Original Message----- From: Eric Decker Sent: Wednesday, 18 August 2021 19:26 To: Richard Cochran Cc: linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [PATCH] Only forward responses to UDS port with corresponding requests on the UDS port, and always send with a unique sequence count from uds. Response below tagged as EDecker: Eric Decker -Original Message- From: Richard Cochran Sent: Wednesday, August 18, 2021 12:23 PM To: Eric Decker Cc: linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [PATCH] Only forward responses to UDS port with corresponding requests on the UDS port, and always send with a unique sequence count from uds. On Mon, Aug 16, 2021 at 03:38:21PM +0000, Eric Decker wrote: > Subject: [PATCH] Only forward responses to UDS port with corresponding > requests on the UDS port, and always send management with a unique sequence > count from uds. The subject line should be ONE sentence, please. EDecker: It is one sentence. > > 1. Only forward responses to UDS port with a corresponding requests on > the UDS port. This is one "issue", and you have a second issue, below. That means you should make (at least) two patches that address the issues independently. > When ptp4l is configured as a boundary clock and a host on ethernet is > issuing excessive management requests (a PTP monitoring tool) then the > requests get forwarded across the boundary clock and the subsequent > responses get forwarded to the UDS port. The UDS code sends messages > to the uds address of the last process it received a message from. > The phc2sys daemon is not expecting these responses which causes its > receive buffers to get full and then the ptp4l send buffers get full > which causes ptp4l to lock until phc2sys reads the messages from its > uds port. ptp4l will lock until phc2sys reads messages from the uds > port which happens every 60sec. So the proper fix would be to ensure the ptp4l's write() is non blocking. EDecker: I wonder if that approach would have unexpected consequences. > How the proposed solution fixes the problem: > > Ptp4l will only forward ptp management response messages to the uds > port if it was requested by the uds port. This will prevent the uds > port buffers from getting full and causing ptp4l to hang until the > buffers are read. Actually, this is wrong. Why? Because the management scheme in 1588 is multicast on purpose. All of the clients benefit from the replies. For example, if a client wants to monitor CURRENT_DATA_SET periodically, it can set a timer. If a reply from *another* client arrives before the timer expires, the client simply uses the information in the reply and resets the timer. This scheme will reduce duplicated queries in the network. So ptp4l must not filter the replies. EDecker: If a non-blocking write fixes the problem with no side effects then perhaps that is a better solution. The use case I am using is requesting data using pmc. A host attempting to access data using PMC will not benefit from another host having previously requested the same data. How would the host requesting data using pmc know that ptp4l previously received a similar response, and how would it know how recently that response was received? > 2. PTP management messages originated from UDS (pmc) do not have the > correct source clock id, I can't agree with this statement. There is no such thing a "correct" clockId. They are arbitrary. EDecker: I would expect the source clock ID of a management message to be the clock ID of the module which sent the message. > and always have the same sequence count untrue. See line 540 of
Re: [Linuxptp-devel] [PATCH] Only forward responses to UDS port with corresponding requests on the UDS port, and always send with a unique sequence count from uds.
Response below tagged as EDecker: Eric Decker -Original Message- From: Richard Cochran Sent: Wednesday, August 18, 2021 12:23 PM To: Eric Decker Cc: linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [PATCH] Only forward responses to UDS port with corresponding requests on the UDS port, and always send with a unique sequence count from uds. On Mon, Aug 16, 2021 at 03:38:21PM +, Eric Decker wrote: > Subject: [PATCH] Only forward responses to UDS port with corresponding > requests on the UDS port, and always send management with a unique sequence > count from uds. The subject line should be ONE sentence, please. EDecker: It is one sentence. > > 1. Only forward responses to UDS port with a corresponding requests on > the UDS port. This is one "issue", and you have a second issue, below. That means you should make (at least) two patches that address the issues independently. > When ptp4l is configured as a boundary clock and a host on ethernet is > issuing excessive management requests (a PTP monitoring tool) then the > requests get forwarded across the boundary clock and the subsequent > responses get forwarded to the UDS port. The UDS code sends messages > to the uds address of the last process it received a message from. > The phc2sys daemon is not expecting these responses which causes its > receive buffers to get full and then the ptp4l send buffers get full > which causes ptp4l to lock until phc2sys reads the messages from its > uds port. ptp4l will lock until phc2sys reads messages from the uds > port which happens every 60sec. So the proper fix would be to ensure the ptp4l's write() is non blocking. EDecker: I wonder if that approach would have unexpected consequences. > How the proposed solution fixes the problem: > > Ptp4l will only forward ptp management response messages to the uds > port if it was requested by the uds port. This will prevent the uds > port buffers from getting full and causing ptp4l to hang until the > buffers are read. Actually, this is wrong. Why? Because the management scheme in 1588 is multicast on purpose. All of the clients benefit from the replies. For example, if a client wants to monitor CURRENT_DATA_SET periodically, it can set a timer. If a reply from *another* client arrives before the timer expires, the client simply uses the information in the reply and resets the timer. This scheme will reduce duplicated queries in the network. So ptp4l must not filter the replies. EDecker: If a non-blocking write fixes the problem with no side effects then perhaps that is a better solution. The use case I am using is requesting data using pmc. A host attempting to access data using PMC will not benefit from another host having previously requested the same data. How would the host requesting data using pmc know that ptp4l previously received a similar response, and how would it know how recently that response was received? > 2. PTP management messages originated from UDS (pmc) do not have the > correct source clock id, I can't agree with this statement. There is no such thing a "correct" clockId. They are arbitrary. EDecker: I would expect the source clock ID of a management message to be the clock ID of the module which sent the message. > and always have the same sequence count untrue. See line 540 of pmc_common.c: msg->header.sequenceId = pmc->sequence_id++; EDecker: The problem is pmc executes as a new process each time it is called. The sequence count sent from pmc to ptp4l is always the same (0 or 1), so ptp4l always sends management messages from pmc with the same sequence count. > which prevents end nodes on ethernet from responding. Why should that prevent nodes from responding? EDecker: Some end nodes I work with monitor the sequence count to make sure it is not a duplicate or "malformed" packet and do not process the management message unless the sequence count is unique as compared to previous management messages from the same clock/module. > Ptp4l will now maintain a static sequence count and send PTP > management messages using this sequence count so each PTP management > message will have a unique sequential sequence count. ptp4l does not generate the messages, and so it has no business "correcting" them. EDecker: Ideally pmc would produce sequential sequence counts, but since is executes as a new process each time it is called, it cannot. I don't think there is another option without significant changes to pmc. > The correct > source clock ID is also included in the management messages. The proper fix is to allow configuration of the clockId in the pmc program via the config mechanism, just like we have in ptp4l. EDecker: Why would you require the caller of pmc to specify th
[Linuxptp-devel] [PATCH] Only forward responses to UDS port with corresponding requests on the UDS port, and always send with a unique sequence count from uds.
Subject: [PATCH] Only forward responses to UDS port with corresponding requests
on the UDS port, and always send management with a unique sequence count from
uds.
1. Only forward responses to UDS port with a corresponding requests on the
UDS port.
The context of the issue/feature:
See the problem description below.
The problem that needs fixing (or missing feature):
When ptp4l is configured as a boundary clock and a host on ethernet is issuing
excessive management requests (a PTP monitoring tool) then the requests get
forwarded across the boundary clock and the subsequent responses get forwarded
to the UDS port. The UDS code sends messages to the uds address of the last
process it received a message from. The phc2sys daemon is not expecting these
responses which causes its receive buffers to get full and then the ptp4l send
buffers get full which causes ptp4l to lock until phc2sys reads the messages
from its uds port. ptp4l will lock until phc2sys reads messages from the uds
port which happens every 60sec.
How the proposed solution fixes the problem:
Ptp4l will only forward ptp management response messages to the uds port if it
was requested by the uds port. This will prevent the uds port buffers from
getting full and causing ptp4l to hang until the buffers are read.
2. PTP management messages originated from UDS (pmc) do not have the
correct source clock id, and always have the same sequence count which prevents
end nodes on ethernet from responding.
The context of the issue/feature:
See the problem description below.
The problem that needs fixing (or missing feature):
PTP management messages originated from UDS (pmc) do not have the correct
source clock id, and always have the same sequence count which prevents end
nodes on ethernet from responding.
How the proposed solution fixes the problem:
Ptp4l will now maintain a static sequence count and send PTP management
messages using this sequence count so each PTP management message will have a
unique sequential sequence count. The correct source clock ID is also included
in the management messages.
Signed-off-by: Eric Decker
---
clock.c | 86 +
1 file changed, 81 insertions(+), 5 deletions(-)
diff --git a/clock.c b/clock.c
index d428ae2..897a623 100644
--- a/clock.c
+++ b/clock.c
@@ -981,7 +981,7 @@ struct clock *clock_create(enum clock_type type, struct
config *config,
}
c->default_dataset.localPriority =
config_get_int(config, NULL, "G.8275.defaultDS.localPriority");
- c->max_steps_removed = config_get_int(config, NULL,"maxStepsRemoved");
+ c->max_steps_removed = config_get_int(config, NULL, "maxStepsRemoved");
c->clock_class_threshold = config_get_int(config, NULL,
"clock_class_threshold");
/* Harmonize the twoStepFlag with the time_stamping option. */
@@ -1381,7 +1381,9 @@ static int clock_do_forward_mgmt(struct clock *c,
return 0;
/* Don't forward any requests to the UDS-RW port
- (the UDS-RO port doesn't allow any forwarding). */
+* (the UDS-RO port doesn't allow any forwarding).
+* Do forward responses.
+*/
if (out == c->uds_rw_port) {
switch (management_action(msg)) {
case GET:
@@ -1393,7 +1395,8 @@ static int clock_do_forward_mgmt(struct clock *c,
if (!*pre_sent) {
/* delay calling msg_pre_send until
-* actually forwarding */
+* actually forwarding
+*/
msg_pre_send(msg);
*pre_sent = 1;
}
@@ -1404,17 +1407,90 @@ static void clock_forward_mgmt_msg(struct clock *c,
struct port *p, struct ptp_m
{
struct port *piter;
int pdulen = 0, msg_ready = 0;
+ static UInteger16 mgmt_seq_count;
+ UInteger16 temp_seq_count = 0;
+
+ struct uds_mgmt_req {
+ UInteger16 seqId;
+ Enumeration16 id;
+ };
+ #define MGMT_REQ_Q_SIZE 4
+ static struct uds_mgmt_req uds_req[MGMT_REQ_Q_SIZE] = {0};
+ static unsigned int uds_req_index;
+ int forward_to_uds = 0;
+ struct management_tlv *mgt =
+ (struct management_tlv *) msg->management.suffix;
if (forwarding(c, p) && msg->management.boundaryHops) {
pdulen = msg->header.messageLength;
msg->management.boundaryHops--;
+
+ if (p == c->uds_rw_port) {
+ /* Send with a unique sequence count and correct clock
identity.
+* If ingress port is uds port (pmc) increment sequence
count.
+*/
+ temp_seq_count = msg->header.sequenceId;
+ msg->header.sequenceId = mgmt_seq_count++;
+
Re: [Linuxptp-devel] [PATCH] Increase the default tx_timestamp_timeout to 5
I agree that there is not "any connection of pmc poll time-out to ptp4l waiting for TX time stamp." I was just stating that I observed pmc unconditionally waiting for a timeout when using poll() and wondered if ptp4l was also unconditionally waiting on a timeout when using poll(). Based on the feedback from the group it is not waiting on the timeout. Eric Decker -Original Message- From: Geva, Erez Sent: Friday, July 9, 2021 11:50 AM To: Eric Decker Cc: linuxptp-devel@lists.sourceforge.net; Richard Cochran ; Miroslav Lichvar Subject: RE: [Linuxptp-devel] [PATCH] Increase the default tx_timestamp_timeout to 5 I do not see any connection of pmc poll time-out to ptp4l waiting for TX time stamp. On my libpmc https://sf.net/p/libpmc I do not use any time out. The libpmc pmc tools works better this way. Erez -Original Message----- From: Eric Decker Sent: Friday, 9 July 2021 00:28 To: Richard Cochran ; Miroslav Lichvar Cc: linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [PATCH] Increase the default tx_timestamp_timeout to 5 If I recall correctly there is an unconditional 150ms delay in PMC which also uses poll(). That I why I asked the question. The delay in PMC may be related to how the firmware is structured, not poll(). I am using Linux 4.xx. Eric Decker -Original Message- From: Richard Cochran Sent: Thursday, July 8, 2021 1:42 PM To: Miroslav Lichvar Cc: Eric Decker ; linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [PATCH] Increase the default tx_timestamp_timeout to 5 On Thu, Jul 08, 2021 at 01:10:08PM +0200, Miroslav Lichvar wrote: > On Thu, Jul 08, 2021 at 01:37:38AM +, Eric Decker wrote: > > If the timestamp is available in less than the timeout (5ms) will it still > > wait for the timeout, or continue processing after the timestamp is > > received? > > The poll() call is waiting for the descriptor, so it should return as > soon as the timestamp is ready. The option sets the maximum time it > waits. But on kernels older than (mumble) (3.5?) the code will sleep the entire period, then wake to read the time stamp. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=04%7C01%7Cerez.geva.ext%40siemens.com%7C1d784133383c4cd4e2b408d9425fe84b%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637613801951566481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=9D4HZAuH9zExpzT86tfZjXtO4%2FQ%2B6ednYqty4SnbVAQ%3Dreserved=0 ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Increase the default tx_timestamp_timeout to 5
If the timestamp is available in less than the timeout (5ms) will it still wait
for the timeout, or continue processing after the timestamp is received?
Eric
-Original Message-
From: Jacob Keller
Sent: Wednesday, July 7, 2021 8:02 PM
To: linuxptp-devel@lists.sourceforge.net
Subject: [Linuxptp-devel] [PATCH] Increase the default tx_timestamp_timeout to 5
The tx_timestamp_timeout configuration defines the number of milliseconds to
wait for a Tx timestamp from the kernel stack. This delay is necessary as Tx
timestamps are captured after a packet is sent and reported back via the socket
error queue.
The current default is to poll for up to 1 millisecond. In practice, it turns
out that this is not always enough time for hardware and software to capture
the timestamp and report it back. Some hardware designs require reading
timestamps over registers or other slow mechanisms.
This extra delay results in the timestamp not being sent back to userspace
within the default 1 millisecond polling time. If that occurs the following can
be seen from ptp4l:
ptp4l[4756.840]: timed out while polling for tx timestamp
ptp4l[4756.840]: increasing tx_timestamp_timeout may correct this issue,
but it is likely caused by a driver bug
ptp4l[4756.840]: port 1 (p2p1): send sync failed
ptp4l[4756.840]: port 1 (p2p1): MASTER to FAULTY on FAULT_DETECTED
(FT_UNSPECIFIED)
This can confuse users because it implies this is a bug, when the correct
solution in many cases is to just increase the timeout to a slightly higher
value.
Since we know this is a problem for many drivers and hardware designs, lets
increase the default timeout. I chose 5 since it is a large enough increase to
avoid the issues on test systems I have. We do want to keep this timeout small
because it prevents ptp4l from doing any other processing while we wait for the
timestamp.
An alternative solution would be to refactor ptp4l so that it does not stop and
wait for a Tx timestamp, but instead handles the timestamps asynchronously.
While this could be done, it adds significant complexity to the application
with minimal or no gain. In most cases, hardware is only capable of a single
outstanding timestamp at a time, so we cannot send another packet anyways until
the first one has completed.
Signed-off-by: Jacob Keller
---
config.c| 2 +-
configs/default.cfg | 2 +-
ptp4l.8 | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/config.c b/config.c
index 4472d3d9d6f9..f33f177c696a 100644
--- a/config.c
+++ b/config.c
@@ -323,7 +323,7 @@ struct config_item config_tab[] = {
GLOB_ITEM_INT("ts2phc.pulsewidth", 5, 100, 99900),
PORT_ITEM_ENU("tsproc_mode", TSPROC_FILTER, tsproc_enu),
GLOB_ITEM_INT("twoStepFlag", 1, 0, 1),
- GLOB_ITEM_INT("tx_timestamp_timeout", 1, 1, INT_MAX),
+ GLOB_ITEM_INT("tx_timestamp_timeout", 5, 1, INT_MAX),
PORT_ITEM_INT("udp_ttl", 1, 1, 255),
PORT_ITEM_INT("udp6_scope", 0x0E, 0x00, 0x0F),
GLOB_ITEM_STR("uds_address", "/var/run/ptp4l"), diff --git
a/configs/default.cfg b/configs/default.cfg index 64ef3bd7c81d..5e9444da57ee
100644
--- a/configs/default.cfg
+++ b/configs/default.cfg
@@ -51,7 +51,7 @@ hybrid_e2e0
inhibit_multicast_service 0
net_sync_monitor 0
tc_spanning_tree 0
-tx_timestamp_timeout 1
+tx_timestamp_timeout 5
unicast_listen 0
unicast_master_table 0
unicast_req_duration 3600
diff --git a/ptp4l.8 b/ptp4l.8
index fe9e1502231c..024fad3d19b2 100644
--- a/ptp4l.8
+++ b/ptp4l.8
@@ -496,7 +496,7 @@ switches all implement this option together with the BMCA.
.B tx_timestamp_timeout
The number of milliseconds to poll waiting for the tx time stamp from the
kernel when a message has recently been sent.
-The default is 1.
+The default is 5.
.TP
.B check_fup_sync
Because of packet reordering that can occur in the network, in the
--
2.31.1.331.gb0c09ab8796f
___
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
[Linuxptp-devel] FW: [PATCH] Always send with a unique sequence count from uds. Only forward responses to UDS port with corresponding requests on the UDS port.
Eric Decker
-Original Message-
From: Eric Decker
Sent: Friday, July 2, 2021 11:40 PM
To: linuxptp-devel@lists.sourceforge.net
Cc: Eric Decker
Subject: [PATCH] Always send with a unique sequence count from uds. Only
forward responses to UDS port with corresponding requests on the UDS port.
Signed-off-by: Eric Decker
---
clock.c | 73 ++---
1 file changed, 70 insertions(+), 3 deletions(-)
diff --git a/clock.c b/clock.c
index d428ae2..3006bf9 100644
--- a/clock.c
+++ b/clock.c
@@ -1381,7 +1381,8 @@ static int clock_do_forward_mgmt(struct clock *c,
return 0;
/* Don't forward any requests to the UDS-RW port
- (the UDS-RO port doesn't allow any forwarding). */
+ (the UDS-RO port doesn't allow any forwarding).
+ Do forward responses. */
if (out == c->uds_rw_port) {
switch (management_action(msg)) {
case GET:
@@ -1404,17 +1405,83 @@ static void clock_forward_mgmt_msg(struct clock *c,
struct port *p, struct ptp_m {
struct port *piter;
int pdulen = 0, msg_ready = 0;
+ static UInteger16 mgmt_seq_count = 0;
+ UInteger16 temp_seq_count = 0;
+ struct uds_mgmt_req {
+ UInteger16 seqId;
+ Enumeration16 id;
+ };
+ #define MGMT_REQ_Q_SIZE 4
+ static struct uds_mgmt_req uds_req[MGMT_REQ_Q_SIZE] = {0};
+ static unsigned int uds_req_index = 0;
+ int forward_to_uds = 0;
+ struct management_tlv *mgt = (struct management_tlv *)
+msg->management.suffix;
+
if (forwarding(c, p) && msg->management.boundaryHops) {
pdulen = msg->header.messageLength;
msg->management.boundaryHops--;
+
+ if (p == c->uds_rw_port)
+ {
+ /* Always send with a unique sequence count and correct
clock identity.
+ If ingress port is uds port (pmc) then increment
sequence count. */
+ temp_seq_count = msg->header.sequenceId;
+ msg->header.sequenceId = mgmt_seq_count++;
+ msg->header.sourcePortIdentity.clockIdentity =
clock_identity(c);
+
+ /* Record outgoing requests from uds port.
+ We will only forward responses to those requests to
uds port. */
+ switch (management_action(msg)) {
+ case GET:
+ case SET:
+ case COMMAND:
+ if ( strstr(msg->address.sun.sun_path, "pmc")
!= NULL ||
+strstr(msg->address.sun.sun_path,
"phc2sys")) {
+ uds_req[uds_req_index].id = mgt->id;
+ uds_req[uds_req_index].seqId =
msg->header.sequenceId;
+ uds_req_index++;
+ if ( uds_req_index >= MGMT_REQ_Q_SIZE )
uds_req_index = 0;
+ }
+ break;
+ default:
+ break;
+ }
+ }
+
+ /* Only forward responses to UDS port with corresponding
requests on the UDS port. */
+ switch (management_action(msg)) {
+ case GET:
+ case SET:
+ case COMMAND:
+ break;
+ default:
+ for ( unsigned int x = 0; x < MGMT_REQ_Q_SIZE; x++)
+ {
+ /* We don't have a destination addresss yet. */
+ if( uds_req[x].id == mgt->id &&
+ uds_req[x].seqId ==
msg->header.sequenceId ) {
+ forward_to_uds = 1;
+ break;
+ }
+ }
+ break;
+ }
+
LIST_FOREACH(piter, >ports, list) {
if (clock_do_forward_mgmt(c, p, piter, msg, _ready))
pr_err("%s: management forward failed",
port_log_name(piter));
}
- if (clock_do_forward_mgmt(c, p, c->uds_rw_port, msg,
_ready))
- pr_err("uds port: management forward failed");
+
+ if ( forward_to_uds == 1 ) {
+ if (clock_do_forward_mgmt(c, p, c->uds_rw_port, msg,
_ready))
+ pr_err("uds port: management forward failed");
+ }
+
+ /* If ingress port is uds por
