2018-03-05 18:51 GMT+01:00 Richard Cochran <richardcoch...@gmail.com>:
>
> The pmc is really a simple tool. You can call it or script it for
> simple use cases, but for more complex use cases, probably writing a
> proper client is the way to go.
>
We might have a different perspective on "complex use case". I would have
expected that this (getting the status of a local ptp instance) is a quite
common and also simple use-case.
My initial plan was to fork a permanent running pmc and regularly send the
GET CURRENT_DATA_SET/GET PORT_DATA_SET message and read the answer, but I
did not expect this tool to print ANY incoming message to stdout :(
Even if all "my" devices use -b 0 to pmc from outputting unexpected
information, I would still be exposed to other devices on the network
sending ptp management messages.
On a big network, this can easily congest the socket make parsing behave
unexpected.
So what follows now may be more suited for the devel list, but maybe just
comment on my thoughts
I've taken a look into the standard and found 15.4.1.3 regarding
the targetPortIdentity of management messages.
The standard states (and I hope I'm allowed to reference here):
"In the case of a management message transmitted by a clock to a manager,
the targetPortIdentity field shall be set to the sourcePortIdentity of the
management message to which it is a response."
If I use pmc with -u, the ClockIdentity field is NOT populated and
therefore the responses don't populate the targetPortIdentity (It's all 0,
which feels incorrect looking at 13.3.2.8). But if I use pmc directly on
the network (without -u), it populates the field and also the responses
have a correct targetPortIdentity.
My idea is to introduce a "response" filter option to pmc: If that flag is
set, throw away all message responses that do not have targetPortIdentity ==
pmc.ClockIdentity.
The only reason I'm currently not doing this: If I use pmc without -u, the
local ptp4l instance does not answer (because IP_MULTICAST_LOOP is set to
off for udp ipv4).
So a) whats the opinion on the filter option and b) is there a reason not
to use IP_MULTICAST_LOOP on the IPv4 port for pmc?
Best regards, Oliver Westermann
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
