I have a network interface on my x86 device where I want to set a static IP 169.254.103.1/24
The network setup is not the same on all devices, so it is configured dynamically from my container entrypoint like this:
ip addr add 169.254.103.1/24 scope link broadcast 169.254.103.255 dev enp0s31f6
And “ip addr” confirms everything is good:
enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:01:29:ac:b8:db brd ff:ff:ff:ff:ff:ff
inet 169.254.103.1/24 brd 169.254.103.255 scope link enp0s31f6
valid_lft forever preferred_lft forever
However, when unplugging the network cable for 10 seconds and plugging back in, the interface says:
enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:01:29:ac:b3:eb brd ff:ff:ff:ff:ff:ff
inet6 fe80::9018:78d4:5204:54ef/64 scope link noprefixroute
valid_lft forever preferred_lft forever
So my IPv4 address disappears.
I believe this is avahi interfering, at least journalctl says:
Leaving mDNS multicast group on interface enp0s31f6.IPv4 with address 169.254.103.1.
Sep 14 09:12:49 mydevice avahi-daemon[1114]: Interface enp0s31f6.IPv4 no longer relevant for mDNS.
I do not understand exactly how Avahi, NetworkManager, systemd and other components interact here.
How do I configure (dynamically) the static IP?
Hi there. BalenaOS supports setting static IP’s for interfaces through network manager - you can modify the connection profile to set a static IP for an interface I believe, here are docs: Network Setup on balenaOS - Balena Documentation
If I’ve misunderstood and this isn’t suitable, let me know!
I tried to use the DBUS approach to configure the network at runtime. It’s a bit more cumbersome, but I made it work, the problems disappeared.
But then, as a sanity check, I reverted back to the previous approach: “ip addr add…” and now that does also not fail anymore. So now I am confused…
Is there any cache in the host OS that fools me here? Something related to network that is remembered from one approach and affects another, even when I power cycle or reboot in between?
Can you clarify as to which cache are you referring and/or data to cache specifically? Also, you can try the approach Ryan suggested above via the /system-connections/ file which should be more reliable and maintainable given upfront configuration.
Feel free to provide feedback on the above and we can check to see if there is anything OS related.
No I cannot clarify which cache I am referring to.
But I was reaching out because my tests indicate that the system has some sort of memory.
At least I am not able to reproduce the original problem after having experimented with the DBUS network configuration.
As I understand the documentation I can not dynamically change the network through /system-connections files. I would need to have one image for each network setup, right? So this is not an option for me.
When you went back to ip addr add, did you disable or otherwise undo the DBUS configuration changes you made? Depending on how you implemented it, DBUS messages to NetworkManager could certainly persist reboots. If you need to configure IP addresses programmatically, the correct approach is to use DBUS to pass configurations to NetworkManager, which are expected to be persistent between reboots and disconnects.
The behaviour you observed with ip addr add initially was the correct, normal behaviour for that command - it does allow you to set a static IP address, but it is, by design, not persistent. So when you disconnected your network cable, this results in the interface going DOWN in the OS, then back UP (you should see this on any normal Linux distribution too - not just BalenaOS). When the interface comes up, it’s managed by NetworkManager connection profiles only and any manual changes made using the ip command will be lost.
For reference, I’d recommend looking over our documentation for networking on BalenaOS, and I’ll link specifically to the section on static addressing Network Setup on balenaOS - Balena Documentation
Thank you James, this sounds consistent with what I found.
Do you have any idea on how I can reset all NetworkManager settings to “factory default”?
Otherwise I am not able to confirm how exactly my dynamic network configuration (via DBUS) really affects the system.