eth0 not added to bridge br0

Question

I followed the official guide and it works perfectly for an rPi3 running on buster but fails on an rPi4 running on buster-lite and I can't see why/I can't see the difference.

The problem: In contrast to the rPi3/buster the eth0 is not added to the bridge br0. eth0 receives an ip-address from the DHCP-server instead of the bridge br0. Somehow the denyinterface for eth0 in dhcpcd.conf is ignored. According to journalctl -u dhcpcd br0 aquires a weird ip-address.

... dhcpcd[712]: br0: probing for an IPv4LL address
... dhcpcd[712]: br0: using IPv4LL address 169.254.30.63

According to dmesg eth0 is not added to the bridge br0 on port 1. In contrast, on the rPi3 eth0 is added to the brigde on port 1 and wlan0 on port 2.

Q What am I missing?

Note On buster-lite I had to manually install dhcpcd5.

Update 1 rPi4

$ cat /etc/os-release 
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
$ apt search dhcpcd
...
dhcpcd5/testing,now 1:8.1.2-1+rpt1 armhf [installed]
  DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support
...

The rPi3 had dhcpcd5 installed out of the box

$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
$ sudo apt search dhcpcd
...
dhcpcd5/testing,now 1:8.1.2-1+rpt1 armhf [installed]
DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support
...

Update 2 This hit me hard and unexpected: On top of raspbian-buster I installed openmediavault (OMV).

The OMV installation injects

$ cat /run/systemd/network/10-netplan-eth0.network
[Match]
MACAddress=cc:aa:33:dd:00:bb
[Network]
DHCP=yes
LinkLocalAddressing=ipv6
IPv6AcceptRA=yes
[DHCP]
RouteMetric=100
UseMTU=true

and this file is breaking my bridge.

The rule-file is generated by /etc/netplan/20-openmediavault-eth0.yaml

Q1 How can this be fixed properly?

The 192.164.x.x shows you have not got an IP address for that network interface. Nothing 'weird' about it - see https://en.wikipedia.org/wiki/Link-local_address — , Dec 20 '20 at 23:56
You may try to use systemd-networkd with Setting up a Raspberry Pi as an access point - the easy way. — Ingo, Dec 21 '20 at 10:04
@Milliways To the point, I (re)installed dhcpcd5 because I couldn't find a /etc/dhcpcd.conf. — participant, Dec 21 '20 at 11:22

Seamus · Answer 1 · 2020-12-24T16:35:53.090

First: calling it dhcpcd5 may create confusion (esp for me :) because of the history of dhcpcd. Yes - the executable file is named dhcpcd5, but it's generally referred to as dhcpcd. man dhcpcd is the same file as man dhcpcd5, and (as @Milliways pointed out in a comment) dhcpcd is a link to dhcpcd5. If you have dhcpcd5 - you have dhcpcd. Here's where I first learned of this.

Second: RPi OS Lite comes with dhcpcd (aka dhcpcd5) already installed - and even a /etc/dhcpcd.conf that works on almost all networks immediately and without editing.

If you don't have dhcpcd installed, then something odd may have happened to your system. You may have un-installed it with a systemd-networkd installation? If you didn't uninstall it (and that doesn't appear to be the case), then I'd suggest you start over - do a fresh install of buster lite on your SD card.

EDIT

You've edited your question, and it seems that you do have dhcpcd/dhcpcd5 installed as it should be. Unless you've edited the default /etc/dhcpcd-conf, I think this is as it should be.

I've not tried the procedure you referenced, and I'm not in a position to try that now. The possibilities that present themselves immediately are 1) the procedure is flawed, 2) you've made a mis-step in executing it on the RPi4, or 3) there is a hardware or firmware diff between the RPi3 & RPi4 that is responsible.

I'll need to come back to this as I've run out of time for the present. The only other thought would be to look further into the possibility of a firmware-induced cause... for that, I'd post an "issue" (a question actually) to the rpi-eeprom github repo.

@Milliways: Whoops! :) Thanks - I'll fix this shortly. – Seamus Dec 22 '20 at 01:30 — Seamus, Dec 22 '20 at 01:30

score 0 · Answer 2 · answered Dec 23 '20 at 06:11

0

Q1 How can this be fixed properly?

If you actually read the documentation for the software you installed (preferably BEFORE installing) it would have told you it uses systemd-networkd for networking.

The logs would have shown that OMV DELETES dhcpcd.

Then set networking to use systemd-networkd rather than a different system (dhcpcd)

answered Dec 23 '20 at 06:11

Milliways

59,890
31
101
209

Which log shows the deletion of dhcpcd? – participant Dec 23 '20 at 11:02

score 0 · Accepted Answer · answered Dec 25 '20 at 21:16

As @Milliways pointed out, openmediavault (OMV) disables dhcpcd. Therefore, I doctored a netplan-yaml-file which I found on the net and it seems to do the trick:

$ cat 30-bridge.yaml 
network:
  ethernets:
    eth0:
      match:
        macaddress: dd:aa:33:dd:00:aa
      #accept-ra: true
      dhcp4: false
      dhcp6: false
bridges:
    br0:
      interfaces: [eth0]
      #addresses: [192.168.1.222/24]
      gateway4: 192.168.x.x
      mtu: 1500
      nameservers:
        addresses: [192.168.x.x]
      parameters:
        stp: true
        forward-delay: 4
      dhcp4: true
      dhcp6: true
      accept-ra: true

Any improvements to the netplan-yaml-file are highly appreciated.

eth0 not added to bridge br0

3 Answers3