[Linuxptp-devel] more than 1 pmc in network -> mixed output

[Rohrer Hansjoerg]

Dear all

If pmc is used in a network on multiple devices, at the same time, one will get mixed outputs.
E.g. one asks for PARENT_DATA_SET, the other for PORT_DATA_SET leads to the following output:

***@DTS4138: pmc -4 -i eth0 "GET PARENT_DATA_SET"
sending: GET PARENT_DATA_SET
000cc6.fffe.76f46f-1 seq 0 RESPONSE MANAGMENT PARENT_DATA_SET
parentPortIdentity 000cc6.fffe.76f46f-0
parentStats 0
observedParentOffsetScaledLogVariance 0xffff
observedParentClockPhaseChangeRate 0x7fffffff
grandmasterPriority1 128
gm.ClockClass 6
gm.ClockAccuracy 0x25
gm.OffsetScaledLogVariance 0xbeef
grandmasterPriority2 128
grandmasterIdentity 000cc6.fffe.76f46f
000cc6.fffe.76f46e-1 seq 0 RESPONSE MANAGMENT PARENT_DATA_SET
parentPortIdentity 000cc6.fffe.76f46e-0
parentStats 0
observedParentOffsetScaledLogVariance 0xffff
observedParentClockPhaseChangeRate 0x7fffffff
grandmasterPriority1 128
gm.ClockClass 6
gm.ClockAccuracy 0x25
gm.OffsetScaledLogVariance 0xbeef
grandmasterPriority2 128
grandmasterIdentity 000cc6.fffe.76f46e
000cc6.fffe.76f46e-1 seq 0 GET MANAGMENT empty-tlv
000cc6.fffe.76f46f-1 seq 0 RESPONSE MANAGMENT PORT_DATA_SET
portIdentity 000cc6.fffe.76f46f-1
portState PASSIVE
logMinDelayReqInterval 0
peerMeanPathDelay 0
logAnnounceInterval 1
announceReceiptTimeout 3
logSyncInterval 0
delayMechanism 1
logMinPdelayReqInterval 0
versionNumber 2
000cc6.fffe.76f46e-1 seq 0 GET MANAGMENT empty-tlv
000cc6.fffe.76f46f-1 seq 0 RESPONSE MANAGMENT PORT_DATA_SET
portIdentity 000cc6.fffe.76f46f-1
portState PASSIVE
logMinDelayReqInterval 0
peerMeanPathDelay 0
logAnnounceInterval 1
announceReceiptTimeout 3
logSyncInterval 0
delayMechanism 1
logMinPdelayReqInterval 0
versionNumber 2

In one case I had a segmetation fault.

I think, there should be some filtering of the received packets for the targetPortIdentity?

Best regards
Hansjörg

__________________________________________________


Hansjoerg Rohrer
Deputy CTO
Engineering & Design
***@mobatime.com
Phone direct: [phone]

Moser-Baer AG
Spitalstrasse 7
3454 Sumiswald
Switzerland

Phone: [phone]
Fax: [phone]

www.mobatime.com <http://www.mobatime.com>
www.mobatec.ch <http://www.mobatec.ch>
[cid:moser-baer_75years982e35]

__________________________________________________

Confidentiality:
The information contained in this e-mail and in any attached files is confidential and/or legally privileged. If you are not the intended recipient, please contact the sender and delete this e-mail. Any unauthorised copying or distribution of the information contained in this e-mail and/or in any attached file is prohibited. The sender and/or the sending company do not accept liability for the incorrect and/or incomplete transmission of the information, nor for any delay or interruption of the transmission, nor for the damages arising from the use of or reliance on the information unless mandatory law provides otherwise. E-mails may be interfered with, may contain computer viruses or other defects. The sender and/or the sending company give no warranties and do not accept liability in relation to these matters, unless mandatory law provides otherwise. Thank you for your cooperation.

[Richard Cochran]

Post by Rohrer Hansjoerg
In one case I had a segmetation fault.

That is not good. If you can find a way to reproduce this, please let
us know.

Post by Rohrer Hansjoerg
I think, there should be some filtering of the received packets for the targetPortIdentity?

The messages are all multicast. I don't think it is a problem to show
all received messages. After all, normally you would want to poll in
order to monitor the nodes in your network. The requests from the other
nodes will generate responses that provide useful information, with
no additional cost (in terms of traffic generation).

The pmc tool is really meant to be just a low level tool, like
tcpdump. I think it would be okay to add filtering options (or better
yet, a tcltk gui as a user friendly front end), but for now, showing
all received messages makes the most sense to me.

Thanks,
Richard

[Keller, Jacob E]

Post by Richard Cochran

Post by Rohrer Hansjoerg
In one case I had a segmetation fault.

That is not good. If you can find a way to reproduce this, please let
us know.

Post by Rohrer Hansjoerg
I think, there should be some filtering of the received packets for the targetPortIdentity?

The messages are all multicast. I don't think it is a problem to show
all received messages. After all, normally you would want to poll in
order to monitor the nodes in your network. The requests from the other
nodes will generate responses that provide useful information, with
no additional cost (in terms of traffic generation).
The pmc tool is really meant to be just a low level tool, like
tcpdump. I think it would be okay to add filtering options (or better
yet, a tcltk gui as a user friendly front end), but for now, showing
all received messages makes the most sense to me.
Thanks,
Richard

Agreed. I would rather see all messages. However, if possible we should
fix the segmentation fault, and indicate where the message originated
from (ie: show which ones "belong" to this client?)

Not really sure how easy that would be, and we could really use a
reproduction of the segmentat

[Richard Cochran]

Post by Keller, Jacob E
Agreed. I would rather see all messages. However, if possible we should
fix the segmentation fault, and indicate where the message originated
from (ie: show which ones "belong" to this client?)

We have the request origin in the targetPortIdentity field, but we
just don't print it out (yet).

Thanks,
Richard

[Richard Cochran]

Post by Richard Cochran

Post by Rohrer Hansjoerg
In one case I had a segmetation fault.

That is not good. If you can find a way to reproduce this, please let
us know.

Just for the record, the segfault was caused by out of tree
modifications (hacks) meant to let the OnTime browser's malformed
messages be accepted by ptp4l/pmc.

So this was a false alarm.

Thanks,
Richard