Installing tcpdump breaks IPv4 networking?

Question

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"?

It's certainly not normal. You might as well approach the problem as if it could have been anything, because I don't see how considering tcpdump will provide any concrete starting place. "ip a shows two ipv6 addresses" -> Presumably this don't mean anything to you, but you might as well post them explicitly as they might provide a clue. "it reports eth0 is down" -> Again, you should include information verbatim as well as your interpretation -- eg. there are several places that may say up or down in ip command output. — goldilocks, Apr 16 '23 at 12:59
See edits with more information I was able to obtain by connecting SSH over ipv6 — tim11g, Apr 16 '23 at 15:40
Additional edit with findings from journelctl - apparently eth0 is no longer valid for dhcpcd? — tim11g, Apr 16 '23 at 17:15
jessie is quite old now (2015), and IIRC it was the first version to come with dhcpcd (aka dhcpcd5). I wonder if you might not be better off trying to install a more up-to-date version of dhcpcd? — Seamus, Apr 18 '23 at 00:40
Another thought is to try setting up a static configuration in dhcpcd.conf - i.e. no fallback configuration; just make a normal static config. At least that should keep dhcpcd out of it. Obviously that will require the static config be set up correctly. Make sure this works before enabling tcpdump. IOW - try to eliminate as many variables as possible. — Seamus, Apr 18 '23 at 01:11
Also recall that setting a static IP may require you to make some config changes in your gateway/dhcp server/whatever. — Seamus, Apr 18 '23 at 01:20
BTW, if you are hoping to use tcpdump to sniff WLAN traffic on a router you are connected to via ethernet cable, it probably will not work; none of the WLAN packets will be directed your way unless they are intended for your address. — goldilocks, Apr 18 '23 at 12:51

goldilocks · Accepted Answer · 2023-04-22T15:22:09.653

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).

Thank you! That does work. The eth0 interface acquired the IPv4 address from DHCP after the sudo dhclient -v eth0 command. Apparently dhclient is still installed since it worked correctly. Now how can I restore the original behavior where the DCHP client ran automatically during boot? This is supposed to be a headless system, so connecting a USB keyboard and HDMI monitor whenever it boots is not ideal. I still don't understand what changed to cause this failure? — tim11g, Apr 22 '23 at 14:18
If dhclient works you might as well stick with it, I've added a means above. — goldilocks, Apr 22 '23 at 15:23

Installing tcpdump breaks IPv4 networking?

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

Inform the DHCP server of our hostname for DDNS.

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

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.

Persist interface configuration when dhcpcd exits.

Rapid commit support.

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

on the server to actually work.

A list of options to request from the DHCP server.

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

Most distributions have NTP support.

A ServerID is required by RFC2131.

Generate SLAAC address using the Hardware Address of the interface

OR generate Stable Private IPv6 Addresses based from the DUID

Example static IP configuration:

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

define static profile

fallback to static profile on eth0

1 Answers1