# Linux – NetworkManager timeout and “ip-config-unavailable” on Ethernet

ethernethome-networkinglinuxnetworkingnetworkmanager

I cannot get this laptop, Craptop, to connect to the Internet using the eth0 interface, but it can connect using the wlan0 interface. NetworkManager, managing eth0, times out when trying to find a DHCP server (present as my home router, 192.168.0.1).

A different laptop, Deltique, can connect and negotiate DHCP just fine using the same Ethernet cable.

After asking Wireshark to monitor eth0 on both machines, I found that Deltique negotiated an IP address with 192.168.0.1 after sending a broadcast on 255.255.255.255, but Craptop sent four DHCP broadcasts without receiving any reply.

It seems that the Ethernet port on Craptop is functional, since it can detect when I plug in the wire, but why can't Craptop receive any packets?

Is Craptop missing a driver? How can I troubleshoot this further?

I've included details on my setup below:

# Logs and Command Outputs

## Wireshark: DHCP packets

Note that this Super User question is unrelated, since it talks about being unable to connect to wlan0.

• The probable cause was a defective Ethernet port on the router. I didn't find the evidence to support this until 30 April 2015, and I didn't make the connection until 10 August 2015.

## What I Should Have Done

• I should have run sudo ethtool -S eth0 to see if there were any errors in the network interface controller (NIC) statistics.

Since I was able to send but not receive over Ethernet, I might have seen something like the rx_crc_errors statistic increment on each receive attempt.

• I should have tried plugging in the router end of the Ethernet cable into a different router port.

Sure, I plugged in the computer end of the Ethernet cable into two different computers, but that led me to believe that a computer (Craptop) was faulty because the other (Deltique) was able to connect to the router.

• On the working computer, Deltique, I should have run sudo ethtool eth0 to see if a good link was established.

Deltique has a 1Gbps capacity, and so does the router, so ethtool should have shown Speed: 1000Mb/s and Duplex: Full. I would later discover on 30 April 2015 that the defective port would have caused ethtool to return different, more concerning values.

• I should have run a speed benchmark to test the Ethernet link to make sure that I was getting the full performance expected between Deltique and the router.

Had I done a speed test, I likely would have seen a 1MiB/s transfer speed, indicating a link problem, even on Deltique.

• To rule out a cable problem, I should have tried using a different Gigabit Ethernet cable.

It turns out that the cable was fine, but this is a good troubleshooting step anyway.

## Evidence and Explanation

On 30 April 2015, I noticed that my trusty rsync -avzHXShPs command was maxing out at about 1MiB/s. I ruled out other traffic by monitoring iftop and by attempting an Internet download on a different computer, which transferred data ten times faster.

I checked the network link with ethtool:

root@node51 [~]# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Speed: 10Mb/s
Duplex: Half
Port: MII
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
drv probe ifdown ifup


Aha! 10Mbps at half duplex. That's not normal and is very slow. For reference, this was the expected (good) output, captured by switching Ethernet ports on the router:

root@node51 [~]# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Speed: 1000Mb/s
Duplex: Full
Port: MII
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
drv probe ifdown ifup


The computer and the router tried to negotiate slower and slower speeds until a reliable one could be established. The slowest one, 10BASE-T half duplex, was picked.

Forcing the full 1000BASE-T full duplex (ethtool -s eth0 speed 1000 duplex full) expected performance caused the affected computer to drop from the network, strongly suggesting that the router didn't want to talk on a faster link.

Craptop, which is limited to 100Mbps full duplex in the first place, probably didn't have a chance to negotiate 10Mbps half duplex.

Now that I have identified the bad Ethernet port, all I need to do is not use that port or get a new router.

On 27 July 2015, I returned the defective router after installing a new router.

Today, Craptop is running on a fault-tolerant network bond with a 100Mbps full duplex Ethernet connection:

root@node52 [~]# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: eth0 (primary_reselect always)
Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: wlan0
MII Status: up
Speed: Unknown
Duplex: Unknown