On Thu, 30 May 2019 at 06:45, Richard Cochran <richardcoch...@gmail.com> wrote: > > On Wed, May 29, 2019 at 11:41:22PM +0300, Vladimir Oltean wrote: > > 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. > > > 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
