I haven't used my NIC for some time, and now it doesn't work anymore, at all. I can assign IP addresses to it manually (sudo ip addr add broadcast dev eth0, for example), but I cannot even ping hosts in the same network.

Very suspicious in my eyes is that ethtool (ethtool -S eth0) displays some transmitted packets, but always exactly zero received bytes & packets. Something is clearly wrong.

Here is a list of the things I tried

  • rebooting
  • tried other cable
  • tried other port (this laptop has one port on it's docking station and one on the laptop itself ; they're internally connected to the same NIC)
  • tried other switch (switch A: 8 port GbE, switch B: 5 port 100 MbE)
  • Downgraded kernel and linux-firmware to older versions (3.13 and mid-2013 respectively)
  • booted latest arch linux live medium ; didn't work, same symptoms
  • booted Ubuntu 14.04.1 live medium ; didn't work, same symptoms

  • In every setup mentioned above I tried accessing the network by manually assigning an IP address, by using wicd. In the start I also tried NetworkManager, same results

  • At this point I suspect the NIC may be broken, if so, how could I validate this or rule it out?

This is the NIC in question (Thinkpad X200):

    00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
            Subsystem: Lenovo Device 20ee
            Flags: bus master, fast devsel, latency 0, IRQ 44
            Memory at f2600000 (32-bit, non-prefetchable) [size=128K]
            Memory at f2625000 (32-bit, non-prefetchable) [size=4K]
            I/O ports at 1840 [size=32]
            Capabilities: [c8] Power Management version 2
            Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
            Capabilities: [e0] PCI Advanced Features
            Kernel driver in use: e1000e
            Kernel modules: e1000e

ethtool -S eth0:

 NIC statistics:
      rx_packets: 0
      tx_packets: 90
      rx_bytes: 0
      tx_bytes: 8113
      rx_broadcast: 0
      tx_broadcast: 70
      rx_multicast: 0
      tx_multicast: 20
      rx_errors: 0
      tx_errors: 0
      tx_dropped: 0
      multicast: 0
      collisions: 0
      rx_length_errors: 0
      rx_over_errors: 0
      rx_crc_errors: 0
      rx_frame_errors: 0
      rx_no_buffer_count: 0
      rx_missed_errors: 0
      tx_aborted_errors: 0
      tx_carrier_errors: 0
      tx_fifo_errors: 0
      tx_heartbeat_errors: 0
      tx_window_errors: 0
      tx_abort_late_coll: 0
      tx_deferred_ok: 0
      tx_single_coll_ok: 0
      tx_multi_coll_ok: 0
      tx_timeout_count: 0
      tx_restart_queue: 0
      rx_long_length_errors: 0
      rx_short_length_errors: 0
      rx_align_errors: 0
      tx_tcp_seg_good: 0
      tx_tcp_seg_failed: 0
      rx_flow_control_xon: 0
      rx_flow_control_xoff: 0
      tx_flow_control_xon: 0
      tx_flow_control_xoff: 0
      rx_csum_offload_good: 0
      rx_csum_offload_errors: 0
      rx_header_split: 0
      alloc_rx_buff_failed: 0
      tx_smbus: 0
      rx_smbus: 0
      dropped_smbus: 0
      rx_dma_failed: 0
      tx_dma_failed: 0
      rx_hwtstamp_cleared: 0
      uncorr_ecc_errors: 0
      corr_ecc_errors: 0

Using tcpdump -i eth0 I don't see any traffic at all.


It seems to me that your tests so far have already pretty conclusively proved that at least the receive side of your problem NIC is not working correctly. But if you want to test more, here are some suggestions:

Check the dock connector of the laptop: since the same NIC is used both with and without the dock, that means the network socket of the laptop is wired through the dock connector. If the dock connector is damaged or short-circuited by something conductive, it might cause the NIC receive circuit to be shorted out even when the dock is not in use.

Look into the network sockets (both the laptop and the dock): are all the contacts in the socket in good shape? Is there anything that might cause a short circuit?

Connect the network adapter with a known good cable to something you can get connection status information out of: a managed switch or another computer with an auto-MDIX capable network interface (i.e. most modern gigabit NICs) should be good. Assign an IP address manually.

Use ethtool eth0 to see if your network interface thinks the link is up. Does the other end agree with it? If the test partner sees no link, the NIC has definitely failed.

Try transmitting data out of the problem NIC: does the other end receive anything? (In a managed switch, traffic counters for that port should be increasing; with another host, you can also monitor the statistics or just use tcpdump, wireshark or similar to monitor all incoming traffic.) If the test partner sees no traffic or its receive error counters are increasing, the transmit side of your problem NIC has (also) failed.


Connect to a network wired or wireless. dhcpcd is automatically loaded on boot. dhcpcd.service is started by default for all interfaces. Stop it if manually configuring wired network.

systemctl stop dhcpcd.service

for connecting to a wireless network

wifi-menu wlo1

with wlo1 being the wireless interface.
ip link to see interfaces, or to bind dhcpcd to ethernet use

systemctl start dhcpcd@eth0.service

If dhcpd fails on startup, start dhcpcd manually.

dhcpcd eth0

Archlinux wiki network configuration

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.