What is the correct way to set DHCP + static IP on a wired connection?

Platform
1

Since the mailing list is gone, I’m not sure if this is the right place, but thought I would try it anyway

We have an embedded system with a wired network. We want to have a fixed IP, but also run DHCP client so that if there is a DHCP server running it will use both.

I have this section in my .nmconnection, and that mostly works: If there’s a DHCP connection it will happily use both addresses.
[ipv4]
address1=10.20.30.40/24
method=auto

BUT: if there is no response from the DHCP requests, the connection goes in DISCONNECTED state and will also drop the static IP. While the connection is yellow in “nmcli conn show” the Static IP is still there, but once the max retries have been reached it will just stay DISCONNECTED.
autoconnect-retries=0 works in the sense that it will stay in this loop forever, but it means that I drop the connection every “dhcp-timeout” seconds. File transfers that are ongoing during that reconnect phase are dropped, so it’s not really an option.

# journalctl -b | grep NetworkManager.*CONN
Feb 20 16:32:32 imx8 NetworkManager[568]: <info>  [1676910752.6570] manager: NetworkManager state is now CONNECTING
Feb 20 16:33:17 imx8 NetworkManager[568]: <info>  [1676910797.5604] manager: NetworkManager state is now DISCONNECTED
Feb 20 16:33:17 imx8 NetworkManager[568]: <info>  [1676910797.6425] manager: NetworkManager state is now CONNECTING
Feb 20 16:34:02 imx8 NetworkManager[568]: <info>  [1676910842.5618] manager: NetworkManager state is now DISCONNECTED
Feb 20 16:34:02 imx8 NetworkManager[568]: <info>  [1676910842.6426] manager: NetworkManager state is now CONNECTING
Feb 20 16:34:47 imx8 NetworkManager[568]: <info>  [1676910887.5589] manager: NetworkManager state is now DISCONNECTED

Cloning the connection and giving it a lower priority and method=static seems like it could work, but that’s kind of silly - and I have 2 sets of values to keep in sync.

Is there a sensible solution that “just works” in the sense that:

  • If there is a DHCP server on the network, my connection stays like
user@imx8:~$ ip -4 a show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    inet 10.20.30.40/24 brd 10.20.30.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet 192.168.0.10/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0
       valid_lft 86389sec preferred_lft 86389sec
  • if there is no DHCP server on the network, my connection stays like:
user@imx8:~$ ip -4 a show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    inet 10.20.30.40/24 brd 10.20.30.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
2

This is a good place to ask. See also Community for the new mailing list.

If you set ipv4.dhcp-timeout=2147483647, then NetworkManager will keep the profile/device up indefinitely, while also trying to get a lease. But in that case, you will get both the DHCP and the static address. I think this is what you should do.

The “silly” method is, when you have two profiles, one with DHCP enabled and a higher autoconnect-priority, then you can let the DHCP profile autoconnect first, then after timeout (and autoconnect-retries), the other profile with only static addresses will activate. The problem with that is, that once the second profile autoconnects, it will never go back to do DHCP (automatically). Also, during the initial phase there is some up and down of the interface where no address is configured for a short time.

It would seem that if you know that the static address works, then the first solution is just fine. If you don’t know that it’s gonna work, then I don’t see how you can meaningfully configure the static address on that interface and have it work in general.

Finally, you can write whatever script/tool you like, and activate the profiles according to your own policy. The automatism in NetworkManager may not be suitable, but NetworkManager provides and API so that a user tool can control this.

1 Like
3

I thought of that, but doesn’t this mean a single DCHP request at the start and then no retries for the next 68 years? If the server doens’t respond the first time I’m without a connection until the next reboot.

Would it make sense to have
autoconnect-retries=0
and
dhcp-timeout=X
so I have this dance once every 10/60 minutes or once a day?

4

I thought of that, but doesn’t this mean a single DCHP request at the start and then no retries for the next 68 years? If the server doens’t respond the first time I’m without a connection until the next reboot.

No. NetworkManager is supposed to retry getting a DHCP lease as long as the interface is up. With ipv4.dhcp-timeout=infinity, it merely means that DHCP cannot fail the profile/device and the profile/device cannot go down due to DHCP… NM is supposed to trying indefinitely. The timeout also controls how long NM will keep the device in activating state before declaring it as activated (this you could still configure via ipv4.required-timeout, but it’s not necessary).

1 Like
5

Sounds good. Tcpdump shows DHCP requests every 65 seconds or so, which is fine.
Googling for ipv4.dhcp-timeout=infinity I found a second source saying the same.

6

This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.