Inspect a Linux Network Interface Safely with ethtool

You will use ethtool to answer four useful questions about a network interface: is the link up, which driver is serving it, which hardware features are active, and what counters report. You will also make one reversible offload change and verify it.

This guide matches the installed ethtool 6.7 package and its January 2024 manual page. Allow about 10 minutes. You need a shell and the name of an interface. Read-only queries normally work as an ordinary user, but changing device settings usually requires root privileges and may affect live traffic.

Checkpoint: choose the interface

1. List interface names, then select the physical or virtual device you mean to inspect.

ip -br link

On a typical host, names might include enp0s31f6, ens3 or eth0. Do not casually choose lo, a Docker bridge or a veth device when diagnosing the host's physical link. Set a shell variable only after checking the name:

IFACE=enp0s31f6
printf '%s\n' "$IFACE"

Expected output is the interface name you selected. The variable lasts only in the current shell.

Checkpoint: read the link summary

2. Query the interface without changing it.

ethtool "$IFACE"

Look for Speed, Duplex, Auto-negotiation and Link detected. A useful healthy result ends with something like this:

Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
Link detected: yes

Supported and advertised link modes are different. Supported modes describe what the device can do; advertised modes describe what it offers to its link partner. A link can be up while running at a lower speed than its maximum. A netlink error: Operation not permitted line can appear before otherwise useful output on a restricted system. Treat that as a permissions or kernel-interface clue, not as proof that the link is down.

Checkpoint: identify the driver and firmware

3. Read the driver information before blaming the interface, kernel or firmware.

ethtool -i "$IFACE"

The output includes fields such as driver, version, firmware-version, bus-info and support flags. For example, an Intel device may report driver e1000e; that is a property of the device in use, not a value to copy into a command. An empty firmware field is not automatically an error because some drivers do not report one.

Record this output when comparing a working and failing host. Driver and firmware details are more useful than a vague statement such as "the network is slow", especially when a kernel update changed the device behaviour.

Checkpoint: inspect offload features

4. List features without attempting to enable or disable them.

ethtool -k "$IFACE"

Entries normally show a requested state and, where relevant, an active state. A line ending in [fixed] cannot be changed by this interface. Features such as checksum offload, TCP segmentation offload and generic receive offload move work between the network card and the kernel. Their names and availability vary by driver.

For scripts or ticket attachments, the JSON form is easier to parse:

ethtool --json --show-features "$IFACE" > ethtool-features.json
python3 -m json.tool ethtool-features.json > /dev/null && echo "valid JSON"

The JSON output is a report, not a stable promise that every driver exposes the same keys. Keep the interface name and the ethtool --version result with it.

Checkpoint: read counters before changing anything

5. Capture driver statistics and look for errors or drops.

ethtool -S "$IFACE" | tee ethtool-stats-before.txt

Names are driver-specific, but counters such as rx_errors, tx_errors, rx_crc_errors and tx_dropped are common. Counters are cumulative since the driver or device reset, so a non-zero value does not say when the fault happened. Take a second sample after a known test and compare the difference:

sleep 10
ethtool -S "$IFACE" > ethtool-stats-after.txt
diff -u ethtool-stats-before.txt ethtool-stats-after.txt

Do not infer a cable fault from one counter alone. Correlate it with link state, kernel logs, switch-port data and the workload.

Make one controlled, reversible change

6. Disable one software-selectable feature only for a test, after saving its current state.

Changing features can alter throughput, CPU use and packet handling immediately. It can also interrupt traffic. Run this as root, preferably during a maintenance window, and never paste a feature name without checking that it exists in your earlier output.

ethtool -k "$IFACE" | tee ethtool-features-before.txt
sudo ethtool -K "$IFACE" gro off
ethtool -k "$IFACE" | rg '^generic-receive-offload:'

Expected verification is a line like generic-receive-offload: off. If the driver rejects the change, it may be fixed, unsupported or controlled by another layer. Do not work around that error by changing several features at once.

Restore the setting when the test ends. If it was on before, run:

sudo ethtool -K "$IFACE" gro on
ethtool -k "$IFACE" | rg '^generic-receive-offload:'

If it was already off, leave it off. This change is commonly not persistent across reboot or device reinitialisation; a network manager or system configuration may reapply its own settings. Check the active state rather than assuming persistence.

Common traps and safety boundaries

• Changing speed is disruptive. ethtool -s can set speed, duplex, port and auto-negotiation. It can drop the link and a bad combination can strand a remote host. Prefer fixing the switch, cable or auto-negotiation first. Save the original ethtool "$IFACE" output and have console access before testing.
• EEPROM and firmware commands are not diagnostics. -E changes EEPROM contents and -f writes firmware to non-volatile memory. They are device-specific and can make hardware unusable. Do not run them from this workflow.
• Tests may disturb traffic. -t asks the driver to run a self-test, and cable tests are hardware-dependent. Use them only with an outage plan and read the driver's documented support first.
• Not every option is supported. The manual explicitly warns that some commands are unsupported in part or whole by network drivers. An error from one option does not invalidate the read-only results.