[Linuxptp-devel] [PATCH] Don't try to forward messages to faulty UDS port.

[Miroslav Lichvar]

When the socket couldn't be opened (e.g. in clknetsim), the file
descriptor is invalid and shouldn't be used for sending.

Signed-off-by: Miroslav Lichvar <***@redhat.com>
---
clock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/clock.c b/clock.c
index 4cde567..cf65fff 100644
--- a/clock.c
+++ b/clock.c
@@ -553,7 +553,7 @@ static int forwarding(struct clock *c, struct port *p)
default:
break;
}
- if (p == c->port[c->nports]) { /*uds*/
+ if (p == c->port[c->nports] && ps != PS_FAULTY) { /*uds*/
return 1;
}
return 0;

[Richard Cochran]

Post by Miroslav Lichvar
When the socket couldn't be opened (e.g. in clknetsim), the file
descriptor is invalid and shouldn't be used for sending.

So, the problem is really having multiple ptp4l instances running on
the same host, right? If so, Hansjoerg @ mobatime had the same issue,
since he wants to run multiple grand masters on different ports with
individual settings.

Maybe the better solution is to add ptp4l's PID into the UDS path.

Thoughts?

Thanks,
Richard

[Miroslav Lichvar]

Post by Richard Cochran

Post by Miroslav Lichvar
When the socket couldn't be opened (e.g. in clknetsim), the file
descriptor is invalid and shouldn't be used for sending.

So, the problem is really having multiple ptp4l instances running on
since he wants to run multiple grand masters on different ports with
individual settings.

I think it's a slightly different problem. I'm running multiple ptp4l
instances on one system, but I want them to behave as if they were
running on separate systems. Communication over UDS sockets is not
allowed, socket(AF_LOCAL) returns with EINVAL. There are asserts in
the clknetsim code to check only valid sockets are used and they are
triggered with ptp4l when the pmc messages are forwarded. I can
workaround it, but I think ptp4l shouldn't be using invalid sockets.

Post by Richard Cochran
Maybe the better solution is to add ptp4l's PID into the UDS path.

How would pmc find the socket? How about making the UDS path
configurable and let the user change it as needed?

[Richard Cochran]

Post by Miroslav Lichvar
I think it's a slightly different problem. I'm running multiple ptp4l
instances on one system, but I want them to behave as if they were
running on separate systems. Communication over UDS sockets is not
allowed, socket(AF_LOCAL) returns with EINVAL. There are asserts in
the clknetsim code to check only valid sockets are used and they are
triggered with ptp4l when the pmc messages are forwarded. I can
workaround it, but I think ptp4l shouldn't be using invalid sockets.

Okay, I'll take the patch, then.

Post by Miroslav Lichvar

Post by Richard Cochran
Maybe the better solution is to add ptp4l's PID into the UDS path.

How would pmc find the socket? How about making the UDS path
configurable and let the user change it as needed?

I was thinking that pmc would have the option, with the pmc default to
open the first socket found.

Thanks,
Richard

[Miroslav Lichvar]

Post by Richard Cochran

Post by Miroslav Lichvar

Post by Richard Cochran
Maybe the better solution is to add ptp4l's PID into the UDS path.

How would pmc find the socket? How about making the UDS path
configurable and let the user change it as needed?

I was thinking that pmc would have the option, with the pmc default to
open the first socket found.

I don't know, setting the path in the config seems like a cleaner and
easier solution to me. If pmc had to find the socket, it would need to
also ping ptp4l to be sure it's not a dead socket. (and ptp4l would
need to unlink the socket on exit to avoid mess in /var/run)

[Keller, Jacob E]

-----Original Message-----
Sent: Tuesday, September 24, 2013 1:00 AM
To: Richard Cochran
Subject: Re: [Linuxptp-devel] [PATCH] Don't try to forward messages to
faulty UDS port.

Post by Richard Cochran

Post by Miroslav Lichvar

Post by Richard Cochran
Maybe the better solution is to add ptp4l's PID into the UDS path.

How would pmc find the socket? How about making the UDS path
configurable and let the user change it as needed?

I was thinking that pmc would have the option, with the pmc default to
open the first socket found.

I don't know, setting the path in the config seems like a cleaner and
easier solution to me. If pmc had to find the socket, it would need to
also ping ptp4l to be sure it's not a dead socket. (and ptp4l would
need to unlink the socket on exit to avoid mess in /var/run)
--
Miroslav Lichvar

I agree with Miroslav, I think config setting seems easiser...

Thanks,
Jake