Static IP address scripts are incompatible with Raspberry Pi OS Bookworm

[cghague]

Related #1668

Our static IP address scripts make changes directly to /etc/dhcpcd.conf, but Raspberry Pi OS Bookworm uses NetworkManager instead of dhcpcd. We should update our scripts to use nmcli and ip.

[mtlynch]

@jdeanwallace - FYI. Not a priority right now, but if we have to write new code to touch dhcpcd, we should look into whether we can use CLI tools that will work on both Bullseye and Bookworm.

[mtlynch]

@jdeanwallace - Since this is potentially blocking the remaining static IP tasks, can you take this on and see if it's possible to make changes to static IP settings in a way that works on both Bullseye and Bookworm?

[mtlynch]

Also: to clarify scope, for now we just want to research a way to write new code that doesn't depend on dhcpcd. I'd like to avoid pausing to rewrite existing dhcpcd-based code unless we have to.

[jdeanwallace]

Update 2023-11-21

Objectives

1. Write new network code that doesn't rely on dhcpcd
2. Preserve existing network code that does rely on dhcpcd

Investigations

1. If we use NetworkManager on Bullseye, can we import/reuse our dhcpcd config? No.

   • We can tell Bullseye to use NetworkManger via raspi-config -> Advanced Options -> Network Config -> NetworkManager.
   • We can tell NetworkManager to continue using dhcpcd as it's DHCP client via

     # /etc/NetworkManager/conf.d/dhcpcd.conf
     [main]
     dhcp=dhcpcd
     

     However, NetworkManager still controls all network config and /etc/dhcpcd.conf is ignored (until you switch back to using dhcpcd via raspi-config).
   • nmcli (Network Manager CLI) has an import function, but it's only for VPN settings.
   • We can write new network code that doesn't rely on dhcpcd, but it breaks all existing network code.

2. Can we go back to using dhcpcd on Bookworm? Yes.

   • We can tell Bookworm to use dhcpcd via raspi-config -> Advanced Options -> Network Config -> dhcpcd.
   • We'll just be kicking the can down the road and any new network code will still depend on dhcpcd.

3. How could we support NetworkManager in the existing set-static-ip & unset-static-ip scripts?

   • Set static IP via NetworkManager

     nmcli connection modify 'Wired connection 1' \
       ipv4.method manual \
       ipv4.addresses 192.168.0.88/24 \
       ipv4.gateway 192.168.0.1 \
       ipv4.dns '192.168.0.1,8.8.8.8,1.1.1.1'
     reboot

   • Unset static IP via NetworkManager

     nmcli connection modify 'Wired connection 1' \
       ipv4.method auto \
       ipv4.addresses '' \
       ipv4.gateway '' \
       ipv4.dns ''
     reboot

4. How much of the new upcoming static IP scripts would rely on dhcpcd? Actually not that much.

• The proposed scripts outlined in 1108, only rely on dhcpcd by means of backing up and restoring it's config file /etc/dhcpcd.conf and don't use the dhcpcd command directly.
• NetworkManager also uses config files. For example: /etc/NetworkManager/system-connections/name.nmconnection
• Converting the new code to use NetworkManager, doesn't seem that bad and should only required a file path change.

Conclusion

It seems like there isn't a way to support both dhcpcd and NetworkManager without altering/rewriting our current static IP scripts. However, seeing as the new static IP scripts probably won't directly execute dhcpcd commands, perhaps we should continue with only supporting dhcpcd and later make the minor file path changes to support NetworkManager in the new static ip scripts.

[jdeanwallace]

@mtlynch - What do you think of the above conclusion that the new static IP scripts should still be written to only support dhcpcd for now?

[mtlynch]

If we use NetworkManager on Bullseye, can we import/reuse our dhcpcd config? No.

I'm confused by this part. It sounds like we can tell NetworkManager to use dhcpcd, but it also says /etc/dhcpcd.conf is ignored. What does telling NetworkManager to use dhcpcd actually do?

Am I understanding correctly that if we rewrote our scripts and image config to use NetworkManager on Bullseye, it would break legacy users who installed before this change and still depend on dhcpcd?

It sounds like what we'll eventually need to do is have a thin wrapper over our networking scripts that's like:

if BOOKWORM:
  do it the NetworkManager way
else:
  do it the dhcpcd way

Is that right?

It seems like there isn't a way to support both dhcpcd and NetworkManager without altering/rewriting our current static IP scripts. However, seeing as the new static IP scripts probably won't directly execute dhcpcd commands, perhaps we should continue with only supporting dhcpcd and later make the minor file path changes to support NetworkManager in the new static ip scripts.

Yeah, this sounds right. I didn't want to dig ourselves deeper into dhcpcd if we could avoid it, but it sounds like we're not going that much deeper, and there's not much we can do to avoid it.

[jdeanwallace]

@mtlynch

What does telling NetworkManager to use dhcpcd actually do?

Great question! I checked the logs and it seems like NetworkManager wasn't detecting dhcpcd despite having it installed:

I found a thread that suggested that the NetworkManager package might not have been built with dhcpcd support. So I checked the package build logs and yes dhcpcd support wasn't enabled at build time:

So in theory, I guess we could technically re-use dhcpcd config via NetworkManager if we rebuild NetworkManager with dhcpcd enabled 🤔 (I haven't tested this)

---

Am I understanding correctly that if we rewrote our scripts and image config to use NetworkManager on Bullseye, it would break legacy users who installed before this change and still depend on dhcpcd?

It sounds like what we'll eventually need to do is have a thin wrapper over our networking scripts

Yes, that's right.

[mtlynch]

@jdeanwallace - Gotcha, thanks.

I'm moving this back to support eng since this is no longer blocking the static IP work.