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  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, 28 May 2020 20:37:03 +0200
From:   Andrew Lunn <>
To:     Petr Machata <>
Cc:     Amit Cohen <>, mlxsw <>,
        "" <>,
        "" <>
Subject: Re: Link down reasons

On Thu, May 28, 2020 at 06:54:24PM +0200, Petr Machata wrote:
> Andrew Lunn <> writes:
> >> Andrew, pardon my ignorance in these matters, can a PHY driver in
> >> general determine that the issue is with the cable, even without running
> >> the fairly expensive cable test?
> >
> > No. To diagnose a problem, you need the link to be idle. If the link
> > peer is sending frames, they interfere with TDR. So all the cable
> > testing i've seen first manipulates the auto-negotiation to make the
> > link peer go quiet. That takes 1 1/2 seconds. There are some
> > optimizations possible, e.g. if the cable is so broken it never
> > establishes link, you can skip this. But Ethernet tends to be robust,
> > it drops back to 100Mbps only using two pairs if one of the four pairs
> > is broken, for example.
> OK, thanks. I suspect our FW is doing this behind the scenes, because it
> can report a shorted cable.
> In another e-mail you suggested this:
>     Link detected: no (cable issue)
> But if the link just silently falls back to 100Mbps, there would never
> be an opportunity for phy to actually report a down reason. So there
> probably is no way for the phy layer to make use of this particular
> down reason.

It is called downshift. And we have support for it in the phylib core,
if the PHY has the needed vendor register.

There are also standard phylib/ethtool ways to configure it, how many
times the PHY should try to establish a 1G link before downshifting to

So in theory we could report:

Link detected: yes (downshifted)

Assuming your proposed API support a reason why it is up, not just a
reason why it is down?


Powered by blists - more mailing lists