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

NetworkManager (from /var/log/syslog)

lshw

Wireshark: DHCP packets

[Screenshot of Wireshark]

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

Best Answer

  • 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

    A few additional troubleshooting steps:

    • 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 ]
            Supported link modes:   10baseT/Half 10baseT/Full
                                    100baseT/Half 100baseT/Full
                                    1000baseT/Half 1000baseT/Full
            Supported pause frame use: No
            Supports auto-negotiation: Yes
            Advertised link modes:  10baseT/Half 10baseT/Full
                                    100baseT/Half 100baseT/Full
                                    1000baseT/Half 1000baseT/Full
            Advertised pause frame use: Symmetric Receive-only
            Advertised auto-negotiation: Yes
            Link partner advertised link modes:  10baseT/Half
            Link partner advertised pause frame use: No
            Link partner advertised auto-negotiation: No
            Speed: 10Mb/s
            Duplex: Half
            Port: MII
            PHYAD: 0
            Transceiver: internal
            Auto-negotiation: on
            Supports Wake-on: pumbg
            Wake-on: g
            Current message level: 0x00000033 (51)
                                   drv probe ifdown ifup
            Link detected: yes
    

    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 ]
            Supported link modes:   10baseT/Half 10baseT/Full
                                    100baseT/Half 100baseT/Full
                                    1000baseT/Half 1000baseT/Full
            Supported pause frame use: No
            Supports auto-negotiation: Yes
            Advertised link modes:  10baseT/Half 10baseT/Full
                                    100baseT/Half 100baseT/Full
                                    1000baseT/Half 1000baseT/Full
            Advertised pause frame use: Symmetric Receive-only
            Advertised auto-negotiation: Yes
            Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                                 100baseT/Half 100baseT/Full
                                                 1000baseT/Full
            Link partner advertised pause frame use: Symmetric
            Link partner advertised auto-negotiation: Yes
            Speed: 1000Mb/s
            Duplex: Full
            Port: MII
            PHYAD: 0
            Transceiver: internal
            Auto-negotiation: on
            Supports Wake-on: pumbg
            Wake-on: g
            Current message level: 0x00000033 (51)
                                   drv probe ifdown ifup
            Link detected: yes
    

    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
    Link Failure Count: 3
    Permanent HW addr: 00:1f:3a:55:dc:0d
    Slave queue ID: 0
    
    Slave Interface: eth0
    MII Status: up
    Speed: 100 Mbps
    Duplex: full
    Link Failure Count: 3
    Permanent HW addr: 00:1e:68:32:4a:b5
    Slave queue ID: 0