Hello,
The manpage for recvmsg states
"""
These calls return the number of bytes received, or -1 if an error
occurred. In the event of an error, errno is set to indicate the
error. The return value will be 0 when the peer has performed an
orderly shutdown.
"""
Now, I'm not sure what an "orde
Hi Richard,
On Sun, 17 Mar 2019 at 11:16, Richard Cochran
wrote:
> > Unfortunately there are networks (GMs?) in the wild which appear to do
> > this, and in not all cases do ptp client users have control over the
> > master. The first time we saw this an iptables rule to drop unusually
> > tiny
The manpage for recvmsg says -1 will be returned on error, Zero indicates an
"orderly shutdown", presumably only in case of stream sockets.
Further, UNIX Network Programming, Vol 1 says ".. a return value of 0 from
recvfrom is acceptable for a datagram protocol"
Such packets have been observed in
In addition to the existing blacklist preventing some management
requests from being forwarded to the UDS, we should also not
forward those responses we've simply overheard on the network if
weren't addressed to the local clockIdentiry.
This way users of the UDS will still get responses to any req
In-Reply-To:
Hello,
Following somewhat from the previous thread "Forwarding management messages to
UDS port"
https://sourceforge.net/p/linuxptp/mailman/message/36148604/
I understand that the UDS is for "local control only" and so not treated the
same
as other ports managed by ptp4l. An examp
Hi Miroslav,
Sure. Say we're running as a single-port ordinary clock: `ptp4l -i eth0`
and the system also has at least one other interface (eth1, ...) although
ptp4l is not configured to do anything with, or care about them.
When eth0 goes into a FAULTY state, a 16 second (by default) timeout is
