How the "lastleaseextend" or "lastlease" should work? Does not working here on 9.4.1

[forca84]

We have to hande a usecase on our setup: system boots up, but dhcp-server is not running, the last lease-file is here and valid and should be used (to repro, just remove the uplink cable on the switch)

As a result: the iface(eth0 here, just one iface on system) stays unconfigured.

/etc/dhcpcd.conf has the options for it set:
default + some new:
debug
background
noipv4ll
ipv4only
lastlease / lastleaseextend (each of these 2 was tried)
logfile /var/log/dh.log

What do we wrong? Or is a howto here, to make it properly?
With the old dhcp-client, it has been working as desired.

dhcpcd --version
dhcpcd 9.4.1
Copyright (c) 2006-2021 Roy Marples
Compiled in features: INET ARP ARPing IPv4LL INET6 DHCPv6 AUTH

The logfile says(ClientId painted over):
cat /var/log/dh.log
May 17 09:46:44 [3133]: dhcpcd not running
May 17 09:46:44 [3155]: dhcpcd-9.4.1 starting
May 17 09:46:44 [3157]: spawned manager process on PID 3157
May 17 09:46:44 [3157]: eth0: executing: /usr/libexec/dhcpcd-run-hooks PREINIT
May 17 09:46:44 [3157]: eth0: executing: /usr/libexec/dhcpcd-run-hooks NOCARRIER
May 17 09:46:45 [3157]: eth0: waiting for carrier
May 17 09:46:46 [3157]: eth0: carrier acquired
May 17 09:46:46 [3157]: eth0: executing: /usr/libexec/dhcpcd-run-hooks CARRIER
May 17 09:46:46 [3157]: eth0: delaying IPv4 for 1.2 seconds
May 17 09:46:48 [3157]: eth0: using ClientID 01:02:03:04:05:06:07
May 17 09:46:48 [3157]: eth0: reading lease: /var/lib/dhcpcd/eth0.lease
May 17 09:46:48 [3157]: eth0: rebinding lease of 192.168.2.249
May 17 09:46:48 [3157]: eth0: sending REQUEST (xid 0xb2042fe1), next in 4.0 seconds
May 17 09:46:52 [3157]: eth0: sending REQUEST (xid 0xb2042fe1), next in 8.9 seconds
May 17 09:46:53 [3157]: eth0: timed out contacting a DHCP server, using last lease
May 17 09:46:53 [3157]: eth0: probing address 192.168.2.249/24
May 17 09:46:53 [3157]: eth0: probing for 192.168.2.249
May 17 09:46:53 [3157]: eth0: ARP probing 192.168.2.249 (1 of 3), next in 1.1 seconds
May 17 09:46:53 [3157]: eth0: soliciting a DHCP lease
May 17 09:46:53 [3157]: eth0: sending DISCOVER (xid 0x1f05c95), next in 4.1 seconds
May 17 09:46:54 [3157]: eth0: ARP probing 192.168.2.249 (2 of 3), next in 1.2 seconds
May 17 09:46:55 [3157]: eth0: ARP probing 192.168.2.249 (3 of 3), next in 2.0 seconds
May 17 09:46:57 [3157]: eth0: sending DISCOVER (xid 0x1f05c95), next in 7.3 seconds
May 17 09:47:04 [3157]: eth0: sending DISCOVER (xid 0x1f05c95), next in 15.6 seconds
May 17 09:47:20 [3157]: eth0: sending DISCOVER (xid 0x1f05c95), next in 32.1 seconds
May 17 09:47:52 [3157]: eth0: sending DISCOVER (xid 0x1f05c95), next in 65.0 seconds
May 17 09:48:57 [3157]: eth0: sending DISCOVER (xid 0x1f05c95), next in 63.1 seconds
May 17 09:50:00 [3157]: eth0: sending DISCOVER (xid 0x1f05c95), next in 64.6 seconds
May 17 09:51:05 [3157]: eth0: sending DISCOVER (xid 0x1f05c95), next in 64.7 seconds
May 17 09:52:09 [3157]: eth0: sending DISCOVER (xid 0x1f05c95), next in 63.1 seconds
May 17 09:53:12 [3157]: eth0: sending DISCOVER (xid 0x1f05c95), next in 63.4 seconds
May 17 09:54:16 [3157]: eth0: sending DISCOVER (xid 0x1f05c95), next in 63.2 seconds
May 17 09:55:19 [3157]: eth0: sending DISCOVER (xid 0x1f05c95), next in 64.5 seconds
May 17 09:56:24 [3157]: eth0: sending DISCOVER (xid 0x1f05c95), next in 63.4 seconds
May 17 09:57:27 [3157]: eth0: sending DISCOVER (xid 0x1f05c95), next in 64.4 seconds

[seamusdemora]

Is the currently-defined persistent option relevant to your needs?

[forca84]

yes (I suppose, caus, we need always a valid ip on iface, regardless what dhcp-server does)

[rsmarples]

This is fixed in ec87730

[seamusdemora]

bravo! :)

[forca84]

This is fixed in ec87730

thx!!!