HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Showing results for 
Search instead for 
Did you mean: 

Command output verify

Mahamudul Hassan
Frequent Advisor

Command output verify

In one of our linux server (HP Blade c7000 enclosure) we have found the following two command outputs which are contradictory.

[root@bldhkvpms ~]# ethtool eth0
Settings for eth0:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 1000baseT/Full
Advertised auto-negotiation: No
Speed: 1000Mb/s
Duplex: Full
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: g
Wake-on: g
Link detected: yes

[root@bldhkvpms ~]# mii-tool
eth0: negotiated 10baseT-HD, link ok

Can any one please verify which tool we should rely?


Honored Contributor

Re: Command output verify

The API used by "mii-tool" was designed for 100 Mbit NICs and cannot really handle gigabit NICs. With gigabit NICs, "mii-tool" is obsolete and does not always return accurate information.

The "ethtool" command uses a newer API that is independent of hardware types.

You should always prefer ethtool over mii-tool. Mii-tool should be used *only* if ethtool does not work with your NIC *and* your NIC has a maximum speed of 100 Mbit or slower.

The "mii-tool" is included in current Linux distributions only because there are still some 100 Mbit NIC drivers which haven't been upgraded to provide the newer ethtool API.

Drivers with ethtool API usually will provide link state notification with the legacy mii-tool API too, but it should be regarded as link up/down notification only, because the old mii-tool API cannot correctly express all possible link speeds.

Michal Kapalka (mikap)
Honored Contributor

Re: Command output verify