bug: blueos-core mangles host network settings on startup

[rotu]

Bug description

When starting blueos-core container, it makes a bunch of destructive changes to the host network settings.

Steps to reproduce

1. Start with a debian system that uses NetworkManager as the network manager. I believe a stock 64-bit Raspberry Pi Bookworm release will do.
2. Install blueos with the install script. If blueos is running, stop it with docker container stop ...
3. Bring up your network interface with sudo nmcli d up enxb827eb81b20a (your interface name will be different). Note this saves the network settings in a persistent file in /etc/NetworkManager/system-connections/.
4. In one window run sudo nmcli monitor to view network changes. Keep this running for the next step.
5. Start the blueos docker container and observe something like the below. Note too that the file created in /etc/NetworkManager/system-connections/ has been deleted!

$ NetworkManager is running
wifi0: connection profile changed
wifi0: connection profile changed
wifi0: connection profile changed
wifi0: connection profile changed
wifi0: connection profile changed
enxb827eb81b20a: connection profile removed
enxb827eb81b20a: deactivating
Networkmanager is now in the 'connected (local only)' state
Connectivity is now 'none'
enxb827eb81b20a: disconnected
Networkmanager is now in the 'connected (site only)' state
'wifi0' is now the primary connection
enxb827eb81b20a: connection profile created
enxb827eb81b20a: using connection 'enxb827eb81b20a'
enxb827eb81b20a: connecting (externally)
enxb827eb81b20a: connecting (externally)
enxb827eb81b20a: connecting (externally)
enxb827eb81b20a: connecting (externally)
enxb827eb81b20a: connecting (externally)
enxb827eb81b20a: connected (externally)
Networkmanager is now in the 'connected' state
Connectivity is now 'full'

Primary pain point(s)

No response

Additional context

No response

Prerequisites

• I have checked to make sure that a similar request has not already been filed or fixed.

[joaoantoniocardoso]

Hi,

If I understood it, I believe the same kind of conflict would happen on a gnome or kde system: there is a manager running that manages the network, so to use nmcli, that manager needs to be disabled.

If that solves your issue, we probably can came up with a way for disabling (parts or entirely) the service.

If there are missing features, we can also add them to the service.

@Williangalvani what do you think?

[rotu]

I believe the same kind of conflict would happen on a gnome or kde system

I bet it would! The difference here is that NetworkManager is the documented tool for setting up networking on Bookworm on Raspberry Pi.

there is a manager running that manages the network

I'm not sure if you're talking about cable-guy, wifi-manager, beacon, or something else. Here are the problems I think I can see:

1. BlueOS is running DHCP inside the container. If something goes wrong with the container or Docker engine, you completely lose connectivity to the host machine. It should probably not take over connections that are already managed.
2. BlueOS is making destructive changes to persistent configuration in /etc/NetworkManager/system-connections. If you've set up network settings manually (through nmcli, network-manager-gnome, editing the files, etc.), there's no prompt that it's about to delete that connection profile with no backups made.
3. These changes are apparently causing the wifi connection to become the "primary connection". I believe (but am not totally sure) that is the reason why WiFi appears preferred over Ethernet when connecting to BlueOS over its MDNS name (e.g. blueos-avahi.local).
4. BlueOS is reconfiguring the wifi connection on a regular basis, something which causes log noise (those above wifi0: connection profile changed keep showing up long after BlueOS starts!) and does not usually happen without BlueOS. fixed in Wifi: use fetch_secrets=False on get_saved_wifi_networks #3188

I think I'll probably have to use $BLUEOS_DISABLE_SERVICES at least for now to disable some of the networking stuff.

[rotu]

I think (2) and (3) might be partially caused by having managed=false in the [ifupdown] section of NetworkManager.conf.