netdev - Re: [PATCH net-next 2/2] net: phy: Add ability to debug RGMII connections

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: <20191018135411.GJ25745@shell.armlinux.org.uk>
Date:   Fri, 18 Oct 2019 14:54:11 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        netdev <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        open list <linux-kernel@...r.kernel.org>,
        Heiner Kallweit <hkallweit1@...il.com>,
        bcm-kernel-feedback-list@...adcom.com, cphealy@...il.com,
        Jose Abreu <joabreu@...opsys.com>
Subject: Re: [PATCH net-next 2/2] net: phy: Add ability to debug RGMII
 connections

On Fri, Oct 18, 2019 at 04:37:55PM +0300, Vladimir Oltean wrote:
> On Fri, 18 Oct 2019 at 16:23, Russell King - ARM Linux admin
> <linux@...linux.org.uk> wrote:
> >
> > On Fri, Oct 18, 2019 at 04:09:30PM +0300, Vladimir Oltean wrote:
> > > Hi Andrew,
> > >
> > > On Fri, 18 Oct 2019 at 16:01, Andrew Lunn <andrew@...n.ch> wrote:
> > > >
> > > > > Well, that's the tricky part. You're sending a frame out, with no
> > > > > guarantee you'll get the same frame back in. So I'm not sure that any
> > > > > identifiers put inside the frame will survive.
> > > > > How do the tests pan out for you? Do you actually get to trigger this
> > > > > check? As I mentioned, my NIC drops the frames with bad FCS.
> > > >
> > > > My experience is, the NIC drops the frame and increments some the
> > > > counter about bad FCS. I do very occasionally see a frame delivered,
> > > > but i guess that is 1/65536 where the FCS just happens to be good by
> > > > accident. So i think some other algorithm should be used which is
> > > > unlikely to be good when the FCS is accidentally good, or just check
> > > > the contents of the packet, you know what is should contain.
> > > >
> > > > Are there any NICs which don't do hardware FCS? Is that something we
> > > > realistically need to consider?
> > > >
> > > > > Yes, but remember, nobody guarantees that a frame with DMAC
> > > > > ff:ff:ff:ff:ff:ff on egress will still have it on its way back. Again,
> > > > > this all depends on how you plan to manage the rx-all ethtool feature.
> > > >
> > > > Humm. Never heard that before. Are you saying some NICs rewrite the
> > > > DMAN?
> > > >
> > >
> > > I'm just trying to understand the circumstances under which this
> > > kernel thread makes sense.
> > > Checking for FCS validity means that the intention was to enable the
> > > reception of frames with bad FCS.
> > > Bad FCS after bad RGMII setup/hold times doesn't mean there's a small
> > > guy in there who rewrites the checksum. It means that frame octets get
> > > garbled. All octets are just as likely to get garbled, including the
> > > SFD, preamble, DMAC, etc.
> > > All I'm saying is that, if the intention of the patch is to actually
> > > process the FCS of frames before and after, then it should actually
> > > put the interface in promiscuous mode, so that frames with a
> > > non-garbled SFD and preamble can still be received, even though their
> > > DMAC was the one that got garbled.
> >
> > Isn't the point of this to see which RGMII setting results in a working
> > setup?
> >
> > So, is it not true that what we're after is receiving a _correct_ frame
> > that corresponds to the frame that was sent out?
> >
> 
> Only true if the MAC does not drop bad frames by itself. Then the FCS
> check in the kernel thread is superfluous.

If a MAC driver doesn't drop bad frames, then surely it's buggy, since
there isn't (afaik) a way of marking a received skb with a FCS error.
Therefore, forwarding frames with bad FCS into the Linux networking
stack will allow the reception of bad frames as if they were good.

All the network drivers I've looked at (and written), when encountering
a packet with an error, update the statistic counters and drop the
errored packet.

Do you know of any that don't?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up