netdev - Re: Behaviour of ETHTOOL_GLINK for an interface that's down

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]

Date:	Wed, 08 Dec 2010 23:47:07 -0600
From:	Dan Williams <dcbw@...hat.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
Cc:	netdev <netdev@...r.kernel.org>,
	sf-linux-drivers <linux-net-drivers@...arflare.com>
Subject: Re: Behaviour of ETHTOOL_GLINK for an interface that's down

On Mon, 2010-12-06 at 21:59 +0000, Ben Hutchings wrote:
> ETHTOOL_GLINK is yet another ethtool operation that has unclear
> semantics that results in differing behaviour when the interface is
> down.
> 
> The two reasonable semantics I can see are:
> 1. Report whether the host has a working link, i.e. netif_running() &&
> netif_carrier_on().
> 2. Report whether the port has a working link.  For hardware interfaces,
> poll the PHY or firmware unless the port is powered-off.  For software
> interfaces, report whether the interface could plausibly pass traffic.
> 
> The default implementation (ethtool_op_get_link) uses
> netif_carrier_ok(), implementing the rather unreasonable semantics:
> 3. Report whether the port had a working link when the interface was
> last up.
> 
> At least one driver works around this by setting carrier off in its
> ndo_stop() operation.
> 
> Here's a small sample of driver behaviours:
> 
> bnx2: (1)
> bnx2x: (1) (I think)
> cxgb3: (1) (but also (2) because PHY is powered off)
> e1000e: (2)
> gianfar: (3)
> igb: (2)
> ixgbe: (1)
> niu: (3)
> sfc: (3) (approximately)
> sky2: (3)
> tg3: (3) (but also (1) due to setting carrier off in tg3_close())
> 
> DaveM said that Network Manager may require (2), although I don't think
> this is correct.  At least the current version brings all managed
> interfaces up whether or not they have link-up already.

NM has used netlink + IFF_RUNNING (not ethtool) for a few years for
actual carrier detection.  Ethtool (and MII ioctls) are called as a
"best effort" method of determining that the device actually *has*
carrier detection at all, since if the device has gone to the trouble to
implement either MII or ethtool, it probably also has carrier detection.

But ethtool isn't actually used to determine carrier status in NM.  It's
netlink all the way down.

Dan


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html