linux-kernel - Re: [PATCH net-next 0/5] PTP support for the SJA1105 DSA driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 30 May 2019 12:01:23 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Richard Cochran <richardcochran@...il.com>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        "David S. Miller" <davem@...emloft.net>,
        John Stultz <john.stultz@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Stephen Boyd <sboyd@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 0/5] PTP support for the SJA1105 DSA driver

On Thu, 30 May 2019 at 06:45, Richard Cochran <richardcochran@...il.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