netdev - Re: [RFC PATCH net-next 1/3] net: rtnetlink: Add link-down reason to RTNL messages

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: <20190318133323.GG30224@lunn.ch>
Date:   Mon, 18 Mar 2019 14:33:23 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Petr Machata <petrm@...lanox.com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jiri Pirko <jiri@...lanox.com>,
        Ido Schimmel <idosch@...lanox.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        Tariq Toukan <tariqt@...lanox.com>,
        "jakub.kicinski@...ronome.com" <jakub.kicinski@...ronome.com>,
        "stephen@...workplumber.org" <stephen@...workplumber.org>
Subject: Re: [RFC PATCH net-next 1/3] net: rtnetlink: Add link-down reason to
 RTNL messages

On Mon, Mar 18, 2019 at 01:15:41PM +0000, Petr Machata wrote:
> 
> Andrew Lunn <andrew@...n.ch> writes:
> 
> >> +enum rtnl_link_down_reason_major {
> >> +	RTNL_LDR_OTHER,
> >
> > Does 'other' make any sense? Seem better to just not report anything
> > at all, or add a comment that more reasons should be added at the end
> > to reflect whatever the hardware or software can determine.
> 
> You still have the minor code to give you some information.
> 
> >> +	RTNL_LDR_NO_CABLE,
> >> +	RTNL_LDR_UNSUPPORTED_CABLE,
> >> +	RTNL_LDR_AUTONEG_FAILURE,
> >> +	RTNL_LDR_NO_LINK_PARTNER,
> >> +	RTNL_LDR_LINK_TRAINING_FAILURE,
> >> +	RTNL_LDR_LOGICAL_MISMATCH,
> >> +	RTNL_LDR_REMOTE_FAULT,
> >> +	RTNL_LDR_BAD_SIGNAL_INTEGRITY,
> >> +	RTNL_LDR_CALIBRATION_FAILURE,
> >> +	RTNL_LDR_POWER_BUDGET_EXCEEDED,
> >> +};
> >
> > What about SFP cage empty?, i.e. no SFP, SFP+ module in the cage?  An
> 
> No cable? Maybe the name needs to change...

An SFP module, and the cable plugged into it via LC connectors, are
physically different things. And you can also have an SFP with an RJ45
for 1G copper. I know at higher speeds they can be inseparable, but
this needs to be a generic API and also work with them being two
separate things. 

> 
> > SFP can also report LOS. That does not appear to be any of the above.
> > Or that the core SFP code has been unable to read the EEPROM? We have
> 
> My assumption was that cable with unreadable EEPROM is simply a bad
> cable. Does the admin actually care which particular part of the cable
> is at fault?

Yes. I throw away the SFP module, because its EEPROM is broke, but
don't need to replace the 1KM of fibre cable, or 100m of Cat 6a copper
cable. Classic example would be fibre to the home. Do you really think
they are going to dig up the road again, to replace the cable, when
all they need to do is replace the SFP module?

	Andrew