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]
Message-ID: <CA+h21hqqO2RYv_zG3gW17c_NBJR80ag8PSVVan66douQN+MQpw@mail.gmail.com>
Date:   Thu, 30 May 2019 17:47:55 +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 3/5] net: dsa: mv88e6xxx: Let taggers specify a
 can_timestamp function

On Thu, 30 May 2019 at 17:24, Richard Cochran <richardcochran@...il.com> wrote:
>
> On Thu, May 30, 2019 at 10:42:41AM +0300, Vladimir Oltean wrote:
> > The meta frames generated by the SJA1105 do not contain any seqid.
>
> So this cannot ever work...
>
> > They contain:
> > * A globally programmable DMAC
> > * A globally programmable SMAC
>
> Don't know what these are, but doesn't sound like they uniquely
> identify the original frame.
>
> > * The 0x8 EtherType
> > * A partial (24-bit or 32-bit) RX timestamp
> > * Two bytes from the initial (pre follow-up) frame's DMAC, before the
> > switch mangled those with the source port and switch id. The driver is
> > supposed to patch these bytes from the follow-up back into the initial
> > frame before passing them up the stack.
> > * The source port that generated the meta frame
> > * The switch id that generated the meta frame
>
> None of these match to the original frame uniquely.  Looks like this
> is a dead end.
>

Yes, they don't identify the original frame.
The hardware's line of thinking seems to be "The meta frame is sent
immediately after the trapped frame that triggered the action." (quote
from https://www.nxp.com/docs/en/user-guide/UM10944.pdf).

> I recommend forgetting about these meta frames.  Instead, read out the
> time stamps over MDIO.
>

If there was any other way to retrieve RX timestamps I would have done
it already.

> Thanks,
> Richard

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ