How To Diagnose Faulty (onboard) Network Adapter

47,276

I always suspect the cables long before I suspect the actual Ethernet NICs. They almost never fail! To methodically debug the issue I'd first eliminate the following things:

  1. Ethernet Cable
  2. Ethernet female connectors on NIC and switch
  3. Another device on the network using the same IP

Once the above have been eliminated as potential problems then move up to the NIC itself and it's software/drivers/configurations.

To debug the NIC you can do the following:

  1. check the dmesg log for messages about the NIC
  2. confirm the configuration information on ifconfig for the NIC
  3. use ethtool eth0 to confirm NIC's healthy and functioning normally

ethtool

Here's a sample of ethtool output:

$ sudo -i ethtool eth0
Settings for eth0:
    Supported ports: [ TP ]
    Supported link modes:   10baseT/Half 10baseT/Full 
                            100baseT/Half 100baseT/Full 
                            1000baseT/Half 1000baseT/Full 
    Supports auto-negotiation: Yes
    Advertised link modes:  10baseT/Half 10baseT/Full 
                            100baseT/Half 100baseT/Full 
                            1000baseT/Half 1000baseT/Full 
    Advertised auto-negotiation: Yes
    Speed: 1000Mb/s
    Duplex: Full
    Port: Twisted Pair
    PHYAD: 0
    Transceiver: internal
    Auto-negotiation: on
    Supports Wake-on: pg
    Wake-on: d
    Current message level: 0x000000ff (255)
    Link detected: yes

You can also use ethtool -S <dev> to get more information as to the nature of the types of failures the NIC has been encountering:

$ sudo -i ethtool -S eth0
NIC statistics:
     tx_bytes: 28770995867
     rx_bytes: 48077578307
     tx_broadcast: 126301
     rx_broadcast: 556519
     tx_multicast: 23471
     rx_multicast: 208434
     tx_unicast: 56635512
     rx_unicast: 62288584
     tx_mac_pause: 0
     rx_mac_pause: 2
     collisions: 0
     late_collision: 0
     aborted: 0
     single_collisions: 0
     multi_collisions: 0
     rx_short: 0
     rx_runt: 0
     rx_64_byte_packets: 949129
     rx_65_to_127_byte_packets: 9301705
     rx_128_to_255_byte_packets: 22481955
     rx_256_to_511_byte_packets: 433087
     rx_512_to_1023_byte_packets: 1755854
     rx_1024_to_1518_byte_packets: 28131809
     rx_1518_to_max_byte_packets: 0
     rx_too_long: 0
     rx_fifo_overflow: 0
     rx_jabber: 0
     rx_fcs_error: 0
     tx_64_byte_packets: 806109
     tx_65_to_127_byte_packets: 16397830
     tx_128_to_255_byte_packets: 20935587
     tx_256_to_511_byte_packets: 2783712
     tx_512_to_1023_byte_packets: 1635233
     tx_1024_to_1518_byte_packets: 14226813
     tx_1519_to_max_byte_packets: 0
     tx_fifo_underrun: 0

References

Share:
47,276

Related videos on Youtube

Mark
Author by

Mark

Updated on September 18, 2022

Comments

  • Mark
    Mark over 1 year

    I'm looking for advice on diagnosing ethernet connectivity issues under Linux. I suspect it's a hardware issue, though I am not entirely sure. It's an nVidia chipset and ethernet adapter.

    The device shows up when I run lspci and the forcedeth driver has been loaded.

    I have assigned a static IP address and specified the gateway (router) IP address. However, -when I ping the router, I get no response. Using the same setup but with a USB->ethernet adapter, everything works as it should. This is why I think it's a problem with the port.

    Do I just have to assume it's a hardware problem or are there some more diagnostics I can perform? I am particularly interested in tools which give more detailed information about the state of the hardware, if such things exist.

    • Admin
      Admin almost 11 years
      The nature of failing hardware is that they become unstable or unpredictable. Try a different card.
    • Admin
      Admin almost 11 years
      You can check link with mii-tool to confirm proper negotiation with your switch/hub, are you able to ping to self address, how about traceroute results?