0

On a Raspberry Pi 2 running Jessie, I just installed tcpdump. It worked when installing, but after rebooting, IPv4 is unavailable on the eth0 interface. It is normally headless and reached by SSH, but now I can only access with the HDMI screen and USB keyboard.

Using this article I set up a Fallback Profile by editing /etc/dhcpcd.conf. Still eth0 is not available on ipv4.

After boot, it reports eth0 is down, but I can bring it up with ifconfig eth0 up, but neither DHCP nor the Fallback Profile are used.

Is this related to tcpdump, or another random failure?

Edit: It was difficult to share any information with only the HDMI screen. I was able to connect with SSH using the ipv6 global unicast address, so now I can share more details:

Whenever the Pi boots it starts with eth0 down.

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether b8:27:eb:9c:03:bf brd ff:ff:ff:ff:ff:ff

$ ifconfig lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 10 bytes 1582 (1.5 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 10 bytes 1582 (1.5 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

I have to use sudo ifconfig eth0 up to enable it.

Then I see this:

 $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:9c:03:bf brd ff:ff:ff:ff:ff:ff
    inet6 26**:a**1:a**8:300:ba27:ebff:fe9c:3bf/64 scope global dynamic mngtmpaddr
       valid_lft 86400sec preferred_lft 14400sec
    inet6 fe80::ba27:ebff:fe9c:3bf/64 scope link
       valid_lft forever preferred_lft forever

I am then able to connect SSH via the ipv6 global unicast address.

Here is the dhcpcd.conf file:

 $ cat /etc/dhcpcd.conf
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.

Allow users of this group to interact with dhcpcd via the control socket.

#controlgroup wheel

Inform the DHCP server of our hostname for DDNS.

hostname

Use the hardware address of the interface for the Client ID.

clientid

or

Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.

Some non-RFC compliant DHCP servers do not reply with this set.

In this case, comment out duid and enable clientid above.

#duid

Persist interface configuration when dhcpcd exits.

persistent

Rapid commit support.

Safe to enable by default because it requires the equivalent option set

on the server to actually work.

option rapid_commit

A list of options to request from the DHCP server.

option domain_name_servers, domain_name, domain_search, host_name option classless_static_routes

Respect the network MTU. This is applied to DHCP routes.

option interface_mtu

Most distributions have NTP support.

#option ntp_servers

A ServerID is required by RFC2131.

require dhcp_server_identifier

Generate SLAAC address using the Hardware Address of the interface

#slaac hwaddr

OR generate Stable Private IPv6 Addresses based from the DUID

slaac private

Example static IP configuration:

#interface eth0 #static ip_address=192.168.0.10/24 #static ip6_address=fd51:42f8:caae:d92e::ff/64 #static routers=192.168.0.1 #static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1

It is possible to fall back to a static IP if DHCP fails:

define static profile

profile static_eth0 static ip_address=192.168.1.177/24 static routers=192.168.1.1 static domain_name_servers=192.168.1.1

fallback to static profile on eth0

interface eth0 fallback static_eth0

This is a strange situation, because the system had been working fine. The only changes made were installing tcpdump, and uncommenting the hdmi_force_hotplug=1 in /boot/config.txt so the monitor would always be active. As part of debugging I also enabled the fallback to static profile in dhcpcd.conf, which had no effect, likely indicating the failure is other than the DHCP server.

Edit2:

I used journelctl --unit=dhcpcd and found this:

-- Boot 9abf20c43bdd4929b2c8b2175e4505bd --
Apr 16 15:30:24 Pi2-TG11 systemd[1]: Starting DHCP Client Daemon...
Apr 16 15:30:24 Pi2-TG11 dhcpcd[347]: dev: loaded udev
Apr 16 15:30:25 Pi2-TG11 dhcpcd[347]: no valid interfaces found
Apr 16 15:30:25 Pi2-TG11 dhcpcd[347]: no valid interfaces found
Apr 16 15:30:25 Pi2-TG11 dhcpcd[347]: forked to background, child pid 421
Apr 16 15:30:25 Pi2-TG11 systemd[1]: Started DHCP Client Daemon.
Apr 16 15:40:26 Pi2-TG11 dhcpcd[421]: received SIGTERM, stopping
Apr 16 15:40:26 Pi2-TG11 dhcpcd[421]: dhcpcd exited
Apr 16 15:40:26 Pi2-TG11 systemd[1]: Stopping DHCP Client Daemon...
Apr 16 15:40:26 Pi2-TG11 systemd[1]: dhcpcd.service: Succeeded.
Apr 16 15:40:26 Pi2-TG11 systemd[1]: Stopped DHCP Client Daemon.

for a prior boot, it looked like this:

-- Boot 5d7aad0b1a6846c88d6f261b97d00bb0 --
Feb 22 18:42:36 Pi2-TG11 dhcpcd[333]: eth0: waiting for carrier
Feb 22 18:42:38 Pi2-TG11 dhcpcd[333]: eth0: carrier acquired
Feb 22 18:42:38 Pi2-TG11 dhcpcd[333]: DUID 00:01:00:01:29:86:02:09:b8:27:eb:9c:03:bf
Feb 22 18:42:38 Pi2-TG11 dhcpcd[333]: eth0: IAID eb:9c:03:bf
Feb 22 18:42:38 Pi2-TG11 dhcpcd[333]: eth0: adding address fe80::1fae:fbde:b8f8:504
Feb 22 18:42:39 Pi2-TG11 dhcpcd[333]: eth0: soliciting an IPv6 router
Feb 22 18:42:39 Pi2-TG11 dhcpcd[333]: eth0: rebinding lease of 192.168.1.177

So why would dhcpcd start to see "no valid interfaces"?

Seamus
  • 23,558
  • 5
  • 42
  • 83
tim11g
  • 301
  • 3
  • 13

1 Answers1

0

WRT dhcpcd, I don't have a direct solution, but you could try stopping the service and seeing if you can set eth up using the somewhat simpler dhclient:

sudo systemctl stop dhcpcd
sudo ip link set eth0 up
sudo dhclient -v eth0

The auto configuration that's happening with the two IPv6 addresses, the mngtmpaddr one and the link local one (fe80::) probably won't interfere with this, but if so you can remove them with ip addr.

If dhclient isn't installed, the package is isc-dhcp-client. It's configuration should work out of the box. It provides a bit of initial feedback when started and forks into the background when a lease is acquired. It logs directly to syslog once backgrounded.

If that works, unfortunately there is no ready made systemd service but arranging something should be simple enough:

[Unit]
Description=DHCP on eth0
Requires=local-fs.target

[Service] Type=forking GuessMainPID=no StandardInput=null ExecStart=/sbin/dhclient -v eth0

[Install] WantedBy=default.target

I've used pretty much that to automate dhclient before. Name that what you like with a .service suffix, put it in /etc/systemd/system/ and sudo systemd enable whatyoulike.service. It will then start automatically at boot and via systemctl start whatyoulike. You will be able to get feedback about the current state via systemctl status whatyoulike and a record of the output (the lease negotiation stuff dhclient prints before it forks into the background) for previous runs (depending how journalling is configured) with sudo journalctl -xeu whatyoulike).

Also make sure you add:

denyinterfaces eth0

To /etc/dhcpcd.conf (and if you have no purpose for it, sudo systemd disable dhcpcd).

goldilocks
  • 60,325
  • 17
  • 117
  • 234