mjhjmtu

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 192.168.2.155/24 broadcast 192.168.2.255 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.

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

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:

Look into the connector socket: are all the contacts in the socket in good shape, and there is nothing 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.