On Thu, 30 May 2019 at 06:45, Richard Cochran [off-list ref] wrote:

On Wed, May 29, 2019 at 11:41:22PM +0300, Vladimir Oltean wrote:

quoted

I'm sorry, then what does this code from raw.c do?

It is a fallback for HW that doesn't support multicast filtering.

Care to look a few lines above?  If you did, you would have seen this:

        memset(&mreq, 0, sizeof(mreq));
        mreq.mr_ifindex = index;
        mreq.mr_type = PACKET_MR_MULTICAST;
        mreq.mr_alen = MAC_LEN;
        memcpy(mreq.mr_address, addr1, MAC_LEN);

        err1 = setsockopt(fd, SOL_PACKET, option, &mreq, sizeof(mreq));

You're right.
In fact that's why it doesn't work: because linuxptp adds ptp_dst_mac
(01-1B-19-00-00-00) and (01-80-C2-00-00-0E) to the MAC's multicast
filter, but the switch in its great wisdom mangles bytes
01-1B-19-xx-xx-00 of the DMAC to place the switch id and source port
there (a rudimentary tagging mechanism). So the frames are no longer
accepted by this multicast MAC filter on the DSA master port unless
it's put in ALLMULTI or PROMISC.

quoted

quoted

No.  The root cause is the time stamps delivered by the hardware or
your driver.  That needs to be addressed before going forward.

How can I check that the timestamps are valid?

Well, you can see that there is something wrong.  Perhaps you are not
matching the meta frames to the received packets.  That is one
possible explanation, but you'll have to figure out what is happening.

If the meta frames weren't associated with the correct link-local
frame, then the whole expect_meta -> SJA1105_STATE_META_ARRIVED
mechanism would go haywire, but it doesn't.
I was actually thinking it has something to do with the fact that I
shouldn't apply frequency corrections on timestamps of PTP delay
messages. Does that make any sense?

Regards,
-Vladimir

Thanks,
Richard