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 +, 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
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 +, 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
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 the source clock ID? As I said earlier I would expect the source clock ID to be the clock ID of the clock that sends the message. Perhaps there are
Re: [Linuxptp-devel] process ID size in the pmc tool
On Tue, Aug 17, 2021 at 05:42:41PM +, Geva, Erez wrote:
> In pmc_create(...)
>
> if (transport_type == TRANS_UDS) {
> pmc->port_identity.portNumber = getpid();
>
> When portNumber is UInteger16
>
> However in new Linux systems, I notice that the process ID can be larger than
> 16 bits.
>
> Do you think we need to bitwise here with 0x?
No, because the assignment already truncates the value to 16 bits.
Thanks,
Richard
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
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. > > 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. > 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. > 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. > and always have the same sequence count untrue. See line 540 of pmc_common.c: msg->header.sequenceId = pmc->sequence_id++; > which prevents end nodes on ethernet from responding. Why should that prevent nodes from responding? > 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. > 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. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH 1/2] [Bug Fix]: gmPresent and gmIdentity is not updated in slaveOnly mode when GM is not reachable.
This patch addresses the bug observed in ptp4l in slaveOnly mode. When the
upstream master is no longer available (not reachable), the slave moves to
LISTENING state. However, the gmIdentity is not updated in ptp4l. This causes
gmPresent reported as true despite GM being non-reachable in pmc commands.
Signed-off-by: Karthikkumar V
Signed-off-by: Ramana Reddy
Reviewed-by: Miroslav Lichvar
---
clock.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/clock.c b/clock.c
index ec70f91..3759b0f 100644
--- a/clock.c
+++ b/clock.c
@@ -1970,6 +1970,12 @@ static void handle_state_decision_event(struct clock *c)
ps = bmc_state_decision(c, piter, c->dscmp);
switch (ps) {
case PS_LISTENING:
+ if (!cid_eq(_id, >dad.pds.grandmasterIdentity))
{
+ clock_update_grandmaster(c);
+ pr_notice("%s: Updated grandmasterIdentity: %s
",
+ port_log_name(piter),
+
cid2str(>dad.pds.grandmasterIdentity));
+ }
event = EV_NONE;
break;
case PS_GRAND_MASTER:
--
1.8.3.1
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH 2/2] Delay Response Timeout Feature addition for PTP4L
This code changes brings in the ability to program delay response timeout
within which, if the upstream master does not send a valid delay response
within the configurable delay response timeout duration, device will move
out of lock state.Default delay_response_timeout is 0 (disabled).
Signed-off-by: Karthikkumar V
Signed-off-by: Ramana Reddy
Reviewed-by: Miroslav Lichvar
---
clock.c | 3 +++
config.c| 1 +
configs/default.cfg | 1 +
fsm.c | 6 ++
fsm.h | 1 +
port.c | 25 -
port_private.h | 2 ++
ptp4l.8 | 6 ++
util.c | 1 +
9 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/clock.c b/clock.c
index 3759b0f..9f3c4d6 100644
--- a/clock.c
+++ b/clock.c
@@ -1631,6 +1631,9 @@ int clock_poll(struct clock *c)
if (EV_ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ==
event) {
c->sde = 1;
}
+ if (EV_DELAY_RESPONSE_TIMEOUT_EXPIRES == event)
{
+ c->sde = 1;
+ }
port_dispatch(p, event, 0);
/* Clear any fault after a little while. */
if (PS_FAULTY == port_state(p)) {
diff --git a/config.c b/config.c
index eb8b988..55d9752 100644
--- a/config.c
+++ b/config.c
@@ -239,6 +239,7 @@ struct config_item config_tab[] = {
PORT_ITEM_ENU("delay_filter", FILTER_MOVING_MEDIAN, delay_filter_enu),
PORT_ITEM_INT("delay_filter_length", 10, 1, INT_MAX),
PORT_ITEM_ENU("delay_mechanism", DM_E2E, delay_mech_enu),
+ PORT_ITEM_INT("delay_response_timeout",0,0,UINT8_MAX),
GLOB_ITEM_INT("dscp_event", 0, 0, 63),
GLOB_ITEM_INT("dscp_general", 0, 0, 63),
GLOB_ITEM_INT("domainNumber", 0, 0, 127),
diff --git a/configs/default.cfg b/configs/default.cfg
index d615610..cd383b5 100644
--- a/configs/default.cfg
+++ b/configs/default.cfg
@@ -30,6 +30,7 @@ logMinPdelayReqInterval 0
operLogPdelayReqInterval 0
announceReceiptTimeout 3
syncReceiptTimeout 0
+delay_response_timeout 0
delayAsymmetry 0
fault_reset_interval 4
neighborPropDelayThresh2000
diff --git a/fsm.c b/fsm.c
index ce6efad..3720d96 100644
--- a/fsm.c
+++ b/fsm.c
@@ -210,6 +210,9 @@ enum port_state ptp_fsm(enum port_state state, enum
fsm_event event, int mdiff)
case EV_RS_PASSIVE:
next = PS_PASSIVE;
break;
+ case EV_DELAY_RESPONSE_TIMEOUT_EXPIRES:
+ next = PS_LISTENING;
+ break;
default:
break;
}
@@ -271,6 +274,7 @@ enum port_state ptp_slave_fsm(enum port_state state, enum
fsm_event event,
case EV_RS_MASTER:
case EV_RS_GRAND_MASTER:
case EV_RS_PASSIVE:
+ case EV_DELAY_RESPONSE_TIMEOUT_EXPIRES:
next = PS_LISTENING;
break;
case EV_RS_SLAVE:
@@ -293,6 +297,7 @@ enum port_state ptp_slave_fsm(enum port_state state, enum
fsm_event event,
case EV_RS_MASTER:
case EV_RS_GRAND_MASTER:
case EV_RS_PASSIVE:
+ case EV_DELAY_RESPONSE_TIMEOUT_EXPIRES:
next = PS_LISTENING;
break;
case EV_MASTER_CLOCK_SELECTED:
@@ -315,6 +320,7 @@ enum port_state ptp_slave_fsm(enum port_state state, enum
fsm_event event,
case EV_RS_MASTER:
case EV_RS_GRAND_MASTER:
case EV_RS_PASSIVE:
+ case EV_DELAY_RESPONSE_TIMEOUT_EXPIRES:
next = PS_LISTENING;
break;
case EV_SYNCHRONIZATION_FAULT:
diff --git a/fsm.h b/fsm.h
index 857af05..236ec60 100644
--- a/fsm.h
+++ b/fsm.h
@@ -53,6 +53,7 @@ enum fsm_event {
EV_RS_GRAND_MASTER,
EV_RS_SLAVE,
EV_RS_PASSIVE,
+ EV_DELAY_RESPONSE_TIMEOUT_EXPIRES,
};
enum bmca_select {
diff --git a/port.c b/port.c
index c82bdaf..3529070 100644
--- a/port.c
+++ b/port.c
@@ -1732,6 +1732,7 @@ int port_initialize(struct port *p)
p->operLogPdelayReqInterval = config_get_int(cfg, p->name,
"operLogPdelayReqInterval");
p->neighborPropDelayThresh = config_get_int(cfg, p->name,
"neighborPropDelayThresh");
p->min_neighbor_prop_delay = config_get_int(cfg, p->name,
"min_neighbor_prop_delay");
+ p->delay_response_timeout = config_get_int(cfg, p->name,
"delay_response_timeout");
if (config_get_int(cfg, p->name, "asCapable") == AS_CAPABLE_TRUE) {
p->asCapable = ALWAYS_CAPABLE;
@@ -1997,6 +1998,9 @@ void process_delay_resp(struct port *p, struct
ptp_message *m)
[Linuxptp-devel] [PATCH] [Bug Fix]: gmPresent and gmIdentity is not updated in slaveOnly mode when GM is not reachable.
This patch addresses the bug observed in ptp4l in slaveOnly mode. When the
upstream master is no longer available (not reachable), the slave moves to
LISTENING state. However, the gmIdentity is not updated in ptp4l. This causes
gmPresent reported as true despite GM being non-reachable in pmc commands.
Signed-off-by: Karthikkumar V
Signed-off-by: Ramana Reddy
Signed-off-by: Miroslav Lichvar
---
clock.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/clock.c b/clock.c
index ec70f91..3759b0f 100644
--- a/clock.c
+++ b/clock.c
@@ -1970,6 +1970,12 @@ static void handle_state_decision_event(struct clock *c)
ps = bmc_state_decision(c, piter, c->dscmp);
switch (ps) {
case PS_LISTENING:
+ if (!cid_eq(_id, >dad.pds.grandmasterIdentity))
{
+ clock_update_grandmaster(c);
+ pr_notice("%s: Updated grandmasterIdentity: %s
",
+ port_log_name(piter),
+
cid2str(>dad.pds.grandmasterIdentity));
+ }
event = EV_NONE;
break;
case PS_GRAND_MASTER:
--
1.8.3.1
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH 2/2] Delay Response Timeout Feature addition for PTP4L
This code changes brings in the ability to program delay response timeout
within which, if the upstream master does not send a valid delay response
within the configurable delay response timeout duration, device will move
out of lock state..Default delay_response_timeout is 0 (disabled).
Signed-off-by: Karthikkumar V
Signed-off-by: Ramana Reddy
Signed-off-by: Miroslav Lichvar
---
clock.c | 3 +++
config.c| 1 +
configs/default.cfg | 1 +
fsm.c | 6 ++
fsm.h | 1 +
port.c | 25 -
port_private.h | 2 ++
ptp4l.8 | 6 ++
util.c | 1 +
9 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/clock.c b/clock.c
index 3759b0f..9f3c4d6 100644
--- a/clock.c
+++ b/clock.c
@@ -1631,6 +1631,9 @@ int clock_poll(struct clock *c)
if (EV_ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ==
event) {
c->sde = 1;
}
+ if (EV_DELAY_RESPONSE_TIMEOUT_EXPIRES == event)
{
+ c->sde = 1;
+ }
port_dispatch(p, event, 0);
/* Clear any fault after a little while. */
if (PS_FAULTY == port_state(p)) {
diff --git a/config.c b/config.c
index eb8b988..55d9752 100644
--- a/config.c
+++ b/config.c
@@ -239,6 +239,7 @@ struct config_item config_tab[] = {
PORT_ITEM_ENU("delay_filter", FILTER_MOVING_MEDIAN, delay_filter_enu),
PORT_ITEM_INT("delay_filter_length", 10, 1, INT_MAX),
PORT_ITEM_ENU("delay_mechanism", DM_E2E, delay_mech_enu),
+ PORT_ITEM_INT("delay_response_timeout",0,0,UINT8_MAX),
GLOB_ITEM_INT("dscp_event", 0, 0, 63),
GLOB_ITEM_INT("dscp_general", 0, 0, 63),
GLOB_ITEM_INT("domainNumber", 0, 0, 127),
diff --git a/configs/default.cfg b/configs/default.cfg
index d615610..cd383b5 100644
--- a/configs/default.cfg
+++ b/configs/default.cfg
@@ -30,6 +30,7 @@ logMinPdelayReqInterval 0
operLogPdelayReqInterval 0
announceReceiptTimeout 3
syncReceiptTimeout 0
+delay_response_timeout 0
delayAsymmetry 0
fault_reset_interval 4
neighborPropDelayThresh2000
diff --git a/fsm.c b/fsm.c
index ce6efad..3720d96 100644
--- a/fsm.c
+++ b/fsm.c
@@ -210,6 +210,9 @@ enum port_state ptp_fsm(enum port_state state, enum
fsm_event event, int mdiff)
case EV_RS_PASSIVE:
next = PS_PASSIVE;
break;
+ case EV_DELAY_RESPONSE_TIMEOUT_EXPIRES:
+ next = PS_LISTENING;
+ break;
default:
break;
}
@@ -271,6 +274,7 @@ enum port_state ptp_slave_fsm(enum port_state state, enum
fsm_event event,
case EV_RS_MASTER:
case EV_RS_GRAND_MASTER:
case EV_RS_PASSIVE:
+ case EV_DELAY_RESPONSE_TIMEOUT_EXPIRES:
next = PS_LISTENING;
break;
case EV_RS_SLAVE:
@@ -293,6 +297,7 @@ enum port_state ptp_slave_fsm(enum port_state state, enum
fsm_event event,
case EV_RS_MASTER:
case EV_RS_GRAND_MASTER:
case EV_RS_PASSIVE:
+ case EV_DELAY_RESPONSE_TIMEOUT_EXPIRES:
next = PS_LISTENING;
break;
case EV_MASTER_CLOCK_SELECTED:
@@ -315,6 +320,7 @@ enum port_state ptp_slave_fsm(enum port_state state, enum
fsm_event event,
case EV_RS_MASTER:
case EV_RS_GRAND_MASTER:
case EV_RS_PASSIVE:
+ case EV_DELAY_RESPONSE_TIMEOUT_EXPIRES:
next = PS_LISTENING;
break;
case EV_SYNCHRONIZATION_FAULT:
diff --git a/fsm.h b/fsm.h
index 857af05..236ec60 100644
--- a/fsm.h
+++ b/fsm.h
@@ -53,6 +53,7 @@ enum fsm_event {
EV_RS_GRAND_MASTER,
EV_RS_SLAVE,
EV_RS_PASSIVE,
+ EV_DELAY_RESPONSE_TIMEOUT_EXPIRES,
};
enum bmca_select {
diff --git a/port.c b/port.c
index c82bdaf..3529070 100644
--- a/port.c
+++ b/port.c
@@ -1732,6 +1732,7 @@ int port_initialize(struct port *p)
p->operLogPdelayReqInterval = config_get_int(cfg, p->name,
"operLogPdelayReqInterval");
p->neighborPropDelayThresh = config_get_int(cfg, p->name,
"neighborPropDelayThresh");
p->min_neighbor_prop_delay = config_get_int(cfg, p->name,
"min_neighbor_prop_delay");
+ p->delay_response_timeout = config_get_int(cfg, p->name,
"delay_response_timeout");
if (config_get_int(cfg, p->name, "asCapable") == AS_CAPABLE_TRUE) {
p->asCapable = ALWAYS_CAPABLE;
@@ -1997,6 +1998,9 @@ void process_delay_resp(struct port *p, struct
ptp_message
