Another followup with shower-thoughts:
2018-03-06 18:53 GMT+01:00 Richard Cochran <>:
> Using UDS is not part of 1588.  The UDS client has no 1588 port ID at
> all.  Therefore, we set the source port ID to zero.
Set the clockIdentity as usual (so like for ethernet use), but set the
portNumber to Zero (Standard V2, allows this: "The all-zero
portNumber may also be used to represent [...] an uninitialized or invalid
portNumber value."

This will create answers with properly set TargetIdentitys and allow the
easy filtering.

Thanks, Olli

2018-03-07 9:00 GMT+01:00 Oliver Westermann <>:

> First: Thanks for the extensive responses, not exactly common on some
> mailing lists :)
> 2018-03-06 18:53 GMT+01:00 Richard Cochran <>:
> > It really isn't rocket science.  Here is an (untested) awk script that
> > accepts responses from exactly one port:
> My issue is a bit different from the script solution (and I'm not 100%
> sure the script is robust to my issue):
> I currently fork and execv pmc once, creating pipes for stdin, out and
> err. On a regular interval, I send 'GET WHATEVER_DATA_SET' to stdin and
> wait for stdout
> to respond (wait for '{Identity} RESPONSE MANAGEMENT WHATEVER_DATA_SET').
> But if the single device only querys every 5 seconds and another pmc on
> the net sends GET requests with boundary hops > 0, the stdout will deliver
> a lot of messages that might not contain what I want.
> If I always take the first correct response - Identity pair, I will soon
> only read outdated data.
> Considering what mess we created here in the network by just having 5-10
> devices missusing pmc, stdout was a constant stream of unwanted data.
> > Using UDS is not part of 1588.  The UDS client has no 1588 port ID at
> > all.  Therefore, we set the source port ID to zero.
> Understood, expected something like this.
> > I don't really see the need, as you can filter the pmc output fairly
> > easily.
> See above, I have to disagree on the "easy" part.
> > A fully featured PTP network monitoring program is really a
> > new feature for future development.
> More of a "local only" option for pmc.
> > I don't think your network setup is very common.  Normally, you would
> > have just one PC sending monitoring requests into the network, not
> > dozens.
> Normally -> You know these "Users", don't you? ;)
> > > b) is there a reason not
> > > to use IP_MULTICAST_LOOP on the IPv4 port for pmc?
> > Actually, that won't work the way that you would want it to.  The
> > transmitted frames from pmc will be looped back, but the multicast
> > responses from ptp4l will not.
> True :/
> Best regards, Olli
Check out the vibrant tech community on one of the world's most
engaging tech sites,!
Linuxptp-users mailing list

Reply via email to