Understanding MII vs TP Port Configuration in ethtool: Why eth0 Shows MII While Using Twisted Pair

html

When running ethtool eth0, you might encounter a confusing output where both MII (Media Independent Interface) and TP (Twisted Pair) appear as supported ports, while the active port is listed as MII - even though you're physically using an RJ45 twisted pair connection. This apparent contradiction stems from how network interfaces abstract physical layer details.

Modern NICs typically support multiple connection types through PHY (Physical Layer) chips. The MII interface is the internal connection between the MAC (Media Access Control) and PHY components. The key points:

MII: The internal interface standard, not the external connector
TP: The actual physical medium (twisted pair cable)
The PHY chip handles conversion between MII signals and TP voltages

To better understand your interface's capabilities, try these commands:

# Show detailed capabilities
ethtool --show-priv-flags eth0

# Display PHY statistics
ethtool --phy-statistics eth0

# Check supported link modes
ethtool eth0 | grep -A10 "Supported link modes"

Here's a simplified example of how a Linux network driver might handle this in code:

static const struct ethtool_ops my_driver_ethtool_ops = {
    .get_settings       = my_get_settings,
    .set_settings       = my_set_settings,
    .get_drvinfo        = my_get_drvinfo,
    .get_link           = ethtool_op_get_link,
    .get_sset_count     = my_get_sset_count,
    .get_strings       = my_get_strings,
    .get_ethtool_stats  = my_get_ethtool_stats,
    .get_priv_flags    = my_get_priv_flags,
};

While this MII/TP display is usually normal, watch for these warning signs:

Consistent "No link" errors despite proper cable connection
PHY register read failures in dmesg
Mismatched duplex/speed settings between endpoints

For deeper investigation, you can access PHY registers (replace XX with your PHY address):

# Read PHY register 0 (basic control)
ethtool --phy-regs eth0 0xXX:0x00

# Monitor link status changes
ethtool --monitor eth0

When examining network interface configurations with ethtool, you might encounter a puzzling situation where the output shows both TP (Twisted Pair) and MII (Media Independent Interface) as supported ports, while physically using an RJ-45 twisted pair connection. Let's dissect what's actually happening at the hardware and driver level.

Modern network interfaces implement multiple abstraction layers:

Physical Layer (PHY) → MAC Layer → Driver Interface

The MII specification (including variants like GMII, RGMII) defines the standard interface between MAC and PHY components, while TP refers to the physical cabling medium.

Network drivers often report MII as the port type because that's the electrical interface they communicate with at the chip level. Here's a simplified example from a Linux driver:

static const struct ethtool_ops example_ethtool_ops = {
    .get_drvinfo        = example_get_drvinfo,
    .get_link           = ethtool_op_get_link,
    .get_ts_info        = ethtool_op_get_ts_info,
    .supported_ports    = (SUPPORTED_TP | SUPPORTED_MII),
    // ...
};

The driver enumerates all supported connection types at different abstraction layers.

To confirm the actual physical connection type:

Check the physical port (RJ-45 for TP)
Examine detailed PHY information: ethtool -m eth0
Review kernel messages: dmesg | grep -i eth0

This discrepancy only becomes problematic if:

You're developing low-level network drivers
Debugging physical layer issues
Implementing custom PHY configurations

For most users and developers, this is simply a matter of driver reporting convention rather than an actual configuration issue.

For developers needing precise interface capabilities, use:

#include <linux/ethtool.h>
#include <linux/sockios.h>

struct ethtool_cmd cmd = {
    .cmd = ETHTOOL_GSET
};
if (ioctl(sockfd, SIOCETHTOOL, &cmd) == 0) {
    printf("Supported: %#x\n", cmd.supported);
    printf("Advertising: %#x\n", cmd.advertising);
}