Bug 338881

Summary:	Ethernet: please add ability to specify capabilities to advertise.
Product:	[Applications] systemsettings	Reporter:	jmranger
Component:	kcm_networkmanagement	Assignee:	Lamarque V. Souza <lamarque>
Status:	RESOLVED UPSTREAM
Severity:	wishlist	CC:	jgrulich, lamarque
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Debian stable
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	Current interface 1/2 - just to illustrate the bug description. Current interface 2/2 - just to illustrate the bug description.

Description jmranger 2014-09-07 16:55:45 UTC

When configuring a wired ethernet connection, networkmanagement already offers to specify whether autonegotiation should be performed, and if not, the specific configuration (speed, duplex) to use.

It is currently possible (at least with ethtool [0] - see "advertise") to keep autonegotiation on, but to limit to specific speed. This capability isn't available through the GUI.

Use-case: in a home setup with a single computer and a single handheld device that never talk to each other, gigabit ethernet doesn't provide any performance gain, but has a real (even if marginal) energy cost.

My ideal scenario (that I currently achieve through modifications to the ifup script) is to have autonegotiation ON and advertise capability 0x00F (i.e. all variants of 10 and 100 mbps).

Thanks!

[0] http://manpages.ubuntu.com/manpages/saucy/en/man8/ethtool.8.html

Reproducible: Always

Comment 1 Lamarque V. Souza 2014-09-12 15:56:21 UTC

As far as I know NetworkManager does not support setting speed for wired connections (or any other connection type for the matter). I see little use for this setting anyway, so most of the time users will see it as something that just clutters the connection editing dialog.

Comment 2 jmranger 2014-09-12 23:35:37 UTC

Thanks for assigning it to the correct module.

As I wrote, NetworkManager offers a way to force a specific speed and duplex, disabling autonegotiation (I'll attach picture soon). It may not offer the API to limit the negotiation to a subset of what the hardware supports - I don't know - but since ethtool can do it, I don't see why NetworkManager couldn't.

Regarding the usefulness, I beg to disagree.
1) It would be added on the same tab that is already used to specify whether autonegotiation is allowed or not - a tab that pretty much no one goes to, unless looking for those specific settings.
2) There is "real-estate available to add it - since the same space is used in non-autonegotiate mode for the speed and duplex comboboxes
3) In 2014, given that (in my understanding) it's strongly discouraged to force specific speed/duplex settings on a GigE interface, it makes more sense to add this new option than to keep the existing "manual speed/duplex" one.

Best regards,

Jean-Marc

Comment 3 jmranger 2014-09-12 23:37:05 UTC

Created attachment 88685 [details]
Current interface 1/2 - just to illustrate the bug description.

Comment 4 jmranger 2014-09-12 23:38:25 UTC

Created attachment 88686 [details]
Current interface 2/2 - just to illustrate the bug description.

Comment 5 Jan Grulich 2014-09-18 09:44:11 UTC

The problem is that it doesn't make sense to add something what is not supported by NetworkManager. If we allow to specify speed even if the auto-negotiation is enabled, the speed would be probably ignored by NetworkManager anyway. You will have to report a bug for NetworkManager first, then we can do something about it.

Comment 6 jmranger 2014-09-18 13:59:13 UTC

Thanks for your feedback.

I wasn't comfortable reporting the bug at the NM level since I've been unable to understand NM's source code enough to confirm whether or not the feature was present there.

Now that you've confirmed that it isn't, I can report it. I'll post a link to the bug once done.

Comment 7 jmranger 2014-09-18 14:12:11 UTC

Upstream bug report: https://bugzilla.gnome.org/show_bug.cgi?id=736909

Comment 8 Jan Grulich 2014-11-04 10:56:58 UTC

Re-open the bug once the upstream bug is resolved and we can do something about it.