mii-tool assumes NIC names of the form eth* when given no interface(s) as argument

Bug #962616 reported by Jared Dominguez
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
net-tools (Ubuntu)
Fix Released
High
Unassigned
Trusty
Won't Fix
Undecided
Unassigned
Xenial
Won't Fix
Undecided
Unassigned

Bug Description

On a system with biosdevname enabled, which names NICs in the forms em* and p*p*, mii-tool will return the message "no MII interfaces found" if mii-tool is called without specifying an interface. The correct behavior would be to iterate through em* and p*p*. (More information on biosdevname can be found at http://linux.dell.com/files/whitepapers/consistent_network_device_naming_in_linux.pdf.)

Revision history for this message
Jiri Popelka (jpopelka) wrote :
Colin Watson (cjwatson)
tags: added: biosdevname
Revision history for this message
Ben Humpert (an3k) wrote :

Nearly five years later this bug still exists (biosdevname enabled / em1 & em2 / Ubuntu Server 14.04.3).

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in net-tools (Ubuntu):
status: New → Confirmed
Revision history for this message
Nathan Stratton Treadway (nathanst) wrote :

Since Xenial now uses "predictable" interface naming schemes, mii-tool's limit will affect most systems.

===== first example =====
# mii-tool
no MII interfaces found
# mii-tool $(cd /sys/class/net/; ls -d en*)
enp4s0: negotiated 100baseTx-FD, link ok
enp6s0: negotiated 1000baseT-FD flow-control, link ok
enp8s0: negotiated 1000baseT-FD flow-control, link ok
enp9s0: no link

===== second example =====
# mii-tool
no MII interfaces found
# mii-tool $(cd /sys/class/net/; ls -d en*)
eno1: negotiated 1000baseT-FD flow-control, link ok
SIOCGMIIPHY on 'eno2' failed: Resource temporarily unavailable

tags: added: xenial
Revision history for this message
Nathan Stratton Treadway (nathanst) wrote :

> Upstream fix http://net-tools.git.sourceforge.net/git/gitweb.cgi?p=net-tools/net-tools;a=commitdiff;h=9dc3a20511a409e1de1a41d715a10028d3bc1b56

This commit can be found at this updated URL:
https://sourceforge.net/p/net-tools/code/ci/9dc3a20511a409e1de1a41d715a10028d3bc1b56/

Not that the approach taken by this commit is to change the mii-tools command to require interface names to be specified on the command line, rather than updating the program to do a more robust search for defined interfaces.

Changed in net-tools (Ubuntu):
importance: Undecided → High
Revision history for this message
Nathan Stratton Treadway (nathanst) wrote :

I'm not at all familiar with the net-tools source, but here's a quick proof-of-concept patch to pull the list of interface names out of /proc/net/dev (silently skipping any that don't support the SIOCGMIIPHY ioctl [lo, lxcbr0, etc.]).

===== first example =====
./mii-tool_lp962616
enp4s0: negotiated 100baseTx-FD, link ok
enp9s0: no link
enp8s0: negotiated 1000baseT-FD flow-control, link ok
enp6s0: negotiated 1000baseT-FD flow-control, link ok

===== second example =====
./mii-tool_lp962616
eno1: negotiated 1000baseT-FD flow-control, link ok
SIOCGMIIPHY on 'eno2' failed: Resource temporarily unavailable

(Obviously one downside of /proc/net/dev is that it isn't always in alphabetical order...)

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "mii-tool interface-name searching" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

While parsing through older bugs I found that this is fixed since 16.10.
Marking correctly ...

Changed in net-tools (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Given that the impact is "only" a message about not finding any of the eth? devices but not a breakage for most use cases I don't think it qualifies for an SRU - also the low activity over time suggests it is not needed badly due to a hard problem with it.

Changed in net-tools (Ubuntu Trusty):
status: New → Won't Fix
Changed in net-tools (Ubuntu Xenial):
status: New → Won't Fix
Revision history for this message
Besmir Zanaj (besmirzanaj-gmail) wrote :

do we still need it in 2017?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.