Keep DISCOVER after falling back to static IP address

[LeoRuan]

My embedded Linux system device uses dhcpcd-10.0.6 to get IPv4 address for only interface 'eth0' from a router, and switches may be used in between device and router. The dynamical IPv4 address is always expected but if router is not available in the networking, dhcpcd fallback into the specific static IPv4 address. The conf looks like as below:

noipv4ll
reboot 30

profile static_eth0
static ip_address=169.254.1.1/24

interface eth0
fallback static_eth0

We have use case that router may join the networking very later after device startup (e.g. 10 minutes later). So at first the device is falling back into the static IP address. When router joins, we expect the dhcpcd can automatically request an old lease or discover a new lease from router. But it does not. Instead the device uses the static IP address for ever. See following debug logs:

Jul 01 11:24:52 [420]: dhcpcd-10.0.6 starting
Jul 01 11:24:52 [420]: chrooting as dhcpcd to /var/lib/dhcpcd
Jul 01 11:24:52 [420]: sandbox: seccomp
Jul 01 11:24:52 [422]: spawned manager process on PID 422
Jul 01 11:24:52 [423]: udev: starting
Jul 01 11:24:52 [423]: dev: loaded udev
Jul 01 11:24:52 [422]: spawned privileged proxy on PID 423
Jul 01 11:24:52 [422]: spawned network proxy on PID 424
Jul 01 11:24:52 [422]: spawned controller proxy on PID 425
Jul 01 11:24:52 [422]: DUID 00:01:00:01:28:d6:06:3d:c6:08:f1:60:37:c2
Jul 01 11:24:53 [420]: forked to background
Jul 01 11:24:53 [422]: eth0: executing: /usr/libexec/dhcpcd-run-hooks PREINIT
Jul 01 11:24:53 [422]: eth0: executing: /usr/libexec/dhcpcd-run-hooks NOCARRIER
Jul 01 11:24:53 [422]: eth0: waiting for carrier
Jul 01 11:24:55 [422]: eth0: carrier acquired
Jul 01 11:24:55 [422]: eth0: executing: /usr/libexec/dhcpcd-run-hooks CARRIER
Jul 01 11:24:56 [422]: eth0: IAID 61:ac:40:66
Jul 01 11:24:56 [422]: eth0: delaying IPv4 for 0.2 seconds
Jul 01 11:24:56 [422]: eth0: reading lease: /var/lib/dhcpcd/eth0.lease
Jul 01 11:24:56 [422]: eth0: soliciting a DHCP lease
Jul 01 11:24:56 [422]: eth0: sending DISCOVER (xid 0xf4f60519), next in 3.5 seconds
Jul 01 11:24:56 [423]: eth0: spawned BPF BOOTP on PID 479
Jul 01 11:24:56 [423]: usb0: libudev: add
Jul 01 11:24:59 [422]: eth0: sending DISCOVER (xid 0xf4f60519), next in 8.1 seconds
Jul 01 11:24:59 [423]: eth0: process BPF BOOTP already started on pid 479
Jul 01 11:25:07 [422]: eth0: sending DISCOVER (xid 0xf4f60519), next in 16.5 seconds
Jul 01 11:25:07 [423]: eth0: process BPF BOOTP already started on pid 479
Jul 01 11:25:23 [422]: eth0: sending DISCOVER (xid 0xf4f60519), next in 31.2 seconds
Jul 01 11:25:23 [423]: eth0: process BPF BOOTP already started on pid 479
Jul 01 11:25:25 [422]: eth0: selected profile static_eth0
Jul 01 11:25:25 [422]: eth0: IAID 61:ac:40:66
Jul 01 11:25:25 [423]: eth0: spawned BPF ARP 169.254.1.1 on PID 733
Jul 01 11:25:25 [422]: eth0: probing address 169.254.1.1/24
Jul 01 11:25:25 [422]: eth0: probing for 169.254.1.1
Jul 01 11:25:25 [422]: eth0: ARP probing 169.254.1.1 (1 of 3), next in 1.9 seconds
Jul 01 11:25:27 [422]: eth0: ARP probing 169.254.1.1 (2 of 3), next in 1.0 seconds
Jul 01 11:25:28 [422]: eth0: ARP probing 169.254.1.1 (3 of 3), next in 2.0 seconds
Jul 01 11:25:30 [422]: eth0: DAD completed for 169.254.1.1
Jul 01 11:25:30 [422]: eth0: using static address 169.254.1.1/24
Jul 01 11:25:30 [422]: eth0: adding IP address 169.254.1.1/24 broadcast 169.254.1.255
Jul 01 11:25:30 [422]: eth0: adding route to 169.254.1.0/24
Jul 01 11:25:30 [422]: eth0: ARP announcing 169.254.1.1 (1 of 2), next in 2.0 seconds
Jul 01 11:25:30 [422]: eth0: executing: /usr/libexec/dhcpcd-run-hooks STATIC
Jul 01 11:25:31 [423]: eth0: BPF BOOTP exited from PID 479
Jul 01 11:25:32 [422]: eth0: ARP announcing 169.254.1.1 (2 of 2)

Is it possible to keep DISCOVER when the device is in fallback status?

[LeoRuan]

I try to add a hook script (/usr/libexec/dhcpcd-hooks/40-fallback) to solve the problem. See below that sends 'renew' to dhcpcd manager.

if [ "$reason" = "STATIC" ] && [ "$profile" = "static_eth0" ]; then
        dhcpcd --renew
fi

---

I realize the '--renew' is designed to retain the old lease (the static IP is also considered as lease with infinite lease-time). It is not for restarting DISCOVER phase. So this is not solution.

[perkelix]

The noipv4ll option prevents the fallback, while waitip 4 will make dhcpcd not give up.

[LeoRuan]

@perkelix we intend no ipv4 link local address but a specific static IP. I tested with adding the waitip 4 to /etc/dhcpcd.conf. The dhcpcd still fall into the static IP for ever. And `waitip' has side-effect: "Wait for an address to be assigned before forking to the background.". We start the dhcpcd with option '-b'.

[rsmarples]

The static options are meant to override any DHCP reply as well as providing a fixed IP to fall back to.

That being said, we could allow this behavior in a fallback profile. To turn it off and have pure static the user could add the nodhcp keyword. Won't be an easy fix to do this though, my initial attempt didn't work too well.

[LeoRuan]

@rsmarples thanks! As a compromise, the ipv4ll is working with DISCOVER in parallel. Maybe an option could be added to specify the link local address with a range for ipv4ll. For example: ipv4ll_addr 169.254.1.1 16 - the option disables the random address and try 169.254.1.1 ~ 169.254.1.16.

[rsmarples]

@LeoRuan just curious - why do you want a dynamic address but want a static IPv4LL allocation to fallback to?

[LeoRuan]

@rsmarples Good question :) For historical reason, installers does configuration on the device via Ethernet interface in early phase - when no router available (even no wall-power) and device is supplied by a battery. Yes, this is very specific requirement for my production.

[rsmarples]

That doesn't really answer the question though? I mean if you're swapping between DHCP and IPv4LL then you're likely doing DNS lookups and provided you have mDNS in play (it's 2024 - all my OS's I support which is a lot use mDNS in my homelab) it really doesn't matter what the IP address is, whether on the client or on the server.

[LeoRuan]

We have a very old remote-program running in Windows PC. The remote program requests IP address of device for connection. In device initial setup, a static IP address is requested so that installer can program the device. After configuration, the device run with DHCP server, DNS server and connect to others e.g. Cloud. The device (DHCP client) is originally implemented by own code and prefer to run with a DHCP server. Only when the DHCP server is not available in network, device fallback to a static IP. I don't know all use-cases that may auto-swap between dynamic and static IP addresses. I am not clear whether the swapping make sense or not. Recently we use dhcpcd with the fallback mechanism instead of the own code. But due to history reason, we are not going to change the mechanism right now.
Anyhow, we want the device can auto-recover from falling back to a static IP address. The IPv4LL is a compromise because DISCOVER is kept running in parallel for recovery. If static IPv4LL is no sense at all, we will find other solution for device.
Thanks!

[rsmarples]

I think I'm happy to add the ipv4ll_addr 169.254.1.1 option to accept a seed address where it increments by 1 upon failure.
This would be acceptable?