linux-kernel - Re: [PATCH v1] net: phy: at803x: add cable test support

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 13 May 2020 14:50:04 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Oleksij Rempel <o.rempel@...gutronix.de>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>, kernel@...gutronix.de,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v1] net: phy: at803x: add cable test support

On Wed, May 13, 2020 at 03:32:09PM +0200, Andrew Lunn wrote:
> On Wed, May 13, 2020 at 02:06:48PM +0200, Oleksij Rempel wrote:
> > The cable test seems to be support by all of currently support Atherso
> > PHYs, so add support for all of them. This patch was tested only on
> > AR9331 PHY with following results:
> > - No cable is detected as short
> > - A 15m long cable connected only on one side is detected as 9m open.
> 
> That sounds wrong. What about a shorted 15m cable? Is it also 9m?  Do
> you have any other long cables you can test with? Is it always 1/2 the
> cable length?

I had similar inaccuracies with my recent faulty cable when testing
with a Marvell PHY as I mentioned.

"Using the VCT in the Marvell PHY points to it being pair 3, at a
distance of 0x190 or 0x50 depending on which way round the cable is
connected.  That's in cm.  The cable isn't 480cm long, it's 278cm
long, and the problem is up by one of the connectors."

0x190 = 400cm, 0x50 = 80cm.

Given that the issue was at one of the connectors on the cable, and
I tried VCT with it plugged into the same port, you can't even say
"well, if we define the start of the cable at 80cm, then that works
for the cable connected the other way around" - it gets us closer
but it's still about 30cm wrong.

It doesn't even work if you think maybe the figures have forgotten
to take into account the fact that the TDR pulse has to go out and
then return (so travel twice the distance, so maybe the figures are
doubled.)

So, it seems we have more than one PHY that produces only wildly
inaccurate guesses at the distance to the fault.

I'd say this technology is a "it would be nice if we could" but the
results can not be relied upon.  It may be grounded in hard physics,
but there's clearly something causing incorrect results.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up