netdev - Re: [PATCH] Force speed and duplex mode setting if link 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] [day] [month] [year] [list]

Message-Id: <285C9B27-0A11-4532-90B6-AF7595057F51@cumulusnetworks.com>
Date:	Tue, 3 Jun 2014 10:12:11 -0700
From:	Scott Feldman <sfeldma@...ulusnetworks.com>
To:	David Laight <David.Laight@...LAB.COM>
Cc:	Sam Tannous <stannous@...ulusnetworks.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	netdev <netdev@...r.kernel.org>,
	Shrijeet Mukherjee <shm@...ulusnetworks.com>
Subject: Re: [PATCH] Force speed and duplex mode setting if link down


On Jun 3, 2014, at 2:13 AM, David Laight <David.Laight@...LAB.COM> wrote:

> From: Of Sam Tannous
>> 
>> I probably didn't make this clear enough in the description.
>> I'm not describing a use case.   I'm simply changing the
>> speed on two interfaces that are directly connected.
>> I don't have autoneg on at all.
>> 
>> 1. I start with a working link where the speed is
>>   10G and duplex is full on both sides.
>> 
>> 2. I change the speed on one side to 1G with
>> 
>>      ethtool -s speed 1000
>> 
>>   and the command appears to work (at least there is no error message).
>>   Once I issue this command, the link is no longer usable
>>   since the speed changed on one side but not the other.  Autoneg
>>   is disabled (by default).
> 
> You really want to leave autoneg enabled and just limit the advertised
> speeds.

This patch is about the forced speed/duplex case, which is one way to set settings.  Autoneg is another.

> I suspect there are plenty of ways ethtool can be used to make
> non-working interfaces, some of them might be needed be developers
> or in unusual circumstances.
> So I don't think ethtool should be policing this specific condition.

Why not?  The patch enforces the specific condition when input from the user is ambiguous.  When link is down, and user is forcing speed only, there is not enough information to know duplex, and ethtool app is defaulting to HDX, which is usually the wrong choice for most interfaces.  The patch forces the user to be explicit on speed and duplex in this ambiguous case.

> Maybe the driver should just use FDX when HDX is invalid for the
> speed.

No, the driver should fail an attempt to set HDX when not supported.

-scott



--
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