Endless loop with ISC DHCPv6 client

[FelixJacobi]

Hello Henri,

I am looking forward to hear from you, since we've worked together on your project in the past and usually works very well in my environments. Thanks so far :) .

I have some new trouble the first time since a couple of years:

Since the Bookworm upgrade on client, it seems that ISC DHCPv6 client seems to do not work very well with dhcpy6d (no clue exactly why):

This is the log in the time frame on the server side:

jacobi-bs.de ~ # tail -f /var/log/dhcpy6d.log
2025-10-05 12:51:32,502 dhcpy6d INFO REQUEST | transaction: cfc11a | addresses: 2003:000a:0838:8f00:0000:0000:0000:0002 fd59:3f01:6a1e:2000:0000:0000:0000:0002 2003:000a:0838:8f00:0000:c0ff:fea8:0002 fd59:3f01:6a1e:2000:0000:c0ff:fea8:0002 | answer: normal | client_llip: fe80:0000:0000:0000:0000:c0ff:fea8:0002 | counter: 4 | duid: 000100012d87ccf30200c0a80002 | ia_options: [3] | iaid: c0a80002 | interface: enp3s0 | last_message_received_type: 3 | mac: 02:00:c0:a8:00:02 | options_request: [23, 24, 39, 31]
2025-10-05 12:51:32,502 dhcpy6d INFO REPLY | transaction: cfc11a | options: [3, 7, 23, 24, 31, 39]  | addresses: 2003:000a:0838:8f00:0000:0000:0000:0002 fd59:3f01:6a1e:2000:0000:0000:0000:0002 2003:000a:0838:8f00:0000:c0ff:fea8:0002 fd59:3f01:6a1e:2000:0000:c0ff:fea8:0002 2003:000a:0838:8f00:0000:c0ff:fea8:0002 fd59:3f01:6a1e:2000:0000:c0ff:fea8:0002 2003:000a:0838:8f00:44ab:6404:1024:09d3 fd59:3f01:6a1e:2000:c606:ba37:4bd5:0a58 | client_class: default_enp3s0 | hostname: paperless
2025-10-05 12:51:35,851 dhcpy6d INFO SOLICIT | transaction: a1f15c | answer: normal | client_llip: fe80:0000:0000:0000:0000:c0ff:fea8:0002 | counter: 1 | duid: 0001000130750a150200c0a80002 | ia_options: [3] | iaid: c0a80002 | interface: enp3s0 | last_message_received_type: 1 | mac: 02:00:c0:a8:00:02 | options_request: [23, 24, 39, 31]
2025-10-05 12:51:35,851 dhcpy6d INFO ADVERTISE | transaction: a1f15c | options: [3, 7, 23, 24, 31, 39]  | addresses: 2003:000a:0838:8f00:0000:0000:0000:0002 fd59:3f01:6a1e:2000:0000:0000:0000:0002 2003:000a:0838:8f00:0000:c0ff:fea8:0002 fd59:3f01:6a1e:2000:0000:c0ff:fea8:0002 2003:000a:0838:8f00:0000:c0ff:fea8:0002 fd59:3f01:6a1e:2000:0000:c0ff:fea8:0002 2003:000a:0838:8f00:49aa:d2ac:7c5e:0e41 fd59:3f01:6a1e:2000:2946:f3cb:b212:0bc4 | client_class: default_enp3s0 | hostname: paperless
2025-10-05 12:51:51,417 dhcpy6d INFO SOLICIT | transaction: a1f15c | answer: normal | client_llip: fe80:0000:0000:0000:0000:c0ff:fea8:0002 | counter: 2 | duid: 0001000130750a150200c0a80002 | ia_options: [3] | iaid: c0a80002 | interface: enp3s0 | last_message_received_type: 1 | mac: 02:00:c0:a8:00:02 | options_request: [23, 24, 39, 31]
2025-10-05 12:51:51,417 dhcpy6d INFO ADVERTISE | transaction: a1f15c | options: [3, 7, 23, 24, 31, 39]  | addresses: 2003:000a:0838:8f00:0000:0000:0000:0002 fd59:3f01:6a1e:2000:0000:0000:0000:0002 2003:000a:0838:8f00:0000:c0ff:fea8:0002 fd59:3f01:6a1e:2000:0000:c0ff:fea8:0002 2003:000a:0838:8f00:0000:c0ff:fea8:0002 fd59:3f01:6a1e:2000:0000:c0ff:fea8:0002 2003:000a:0838:8f00:49aa:d2ac:7c5e:0e41 fd59:3f01:6a1e:2000:2946:f3cb:b212:0bc4 | client_class: default_enp3s0 | hostname: paperless
2025-10-05 12:52:03,773 dhcpy6d INFO SOLICIT | transaction: a1f15c | answer: normal | client_llip: fe80:0000:0000:0000:0000:c0ff:fea8:0002 | counter: 3 | duid: 0001000130750a150200c0a80002 | ia_options: [3] | iaid: c0a80002 | interface: enp3s0 | last_message_received_type: 1 | mac: 02:00:c0:a8:00:02 | options_request: [23, 24, 39, 31]
2025-10-05 12:52:03,774 dhcpy6d INFO ADVERTISE | transaction: a1f15c | options: [3, 7, 23, 24, 31, 39]  | addresses: 2003:000a:0838:8f00:0000:0000:0000:0002 fd59:3f01:6a1e:2000:0000:0000:0000:0002 2003:000a:0838:8f00:0000:c0ff:fea8:0002 fd59:3f01:6a1e:2000:0000:c0ff:fea8:0002 2003:000a:0838:8f00:0000:c0ff:fea8:0002 fd59:3f01:6a1e:2000:0000:c0ff:fea8:0002 2003:000a:0838:8f00:49aa:d2ac:7c5e:0e41 fd59:3f01:6a1e:2000:2946:f3cb:b212:0bc4 | client_class: default_enp3s0 | hostname: paperless
2025-10-05 12:52:05,548 dhcpy6d INFO SOLICIT | transaction: a1f15c | answer: normal | client_llip: fe80:0000:0000:0000:0000:c0ff:fea8:0002 | counter: 4 | duid: 0001000130750a150200c0a80002 | ia_options: [3] | iaid: c0a80002 | interface: enp3s0 | last_message_received_type: 1 | mac: 02:00:c0:a8:00:02 | options_request: [23, 24, 39, 31]
2025-10-05 12:52:05,548 dhcpy6d INFO ADVERTISE | transaction: a1f15c | options: [3, 7, 23, 24, 31, 39]  | addresses: 2003:000a:0838:8f00:0000:0000:0000:0002 fd59:3f01:6a1e:2000:0000:0000:0000:0002 2003:000a:0838:8f00:0000:c0ff:fea8:0002 fd59:3f01:6a1e:2000:0000:c0ff:fea8:0002 2003:000a:0838:8f00:0000:c0ff:fea8:0002 fd59:3f01:6a1e:2000:0000:c0ff:fea8:0002 2003:000a:0838:8f00:49aa:d2ac:7c5e:0e41 fd59:3f01:6a1e:2000:2946:f3cb:b212:0bc4 | client_class: default_enp3s0 | hostname: paperless
2025-10-05 12:52:18,350 dhcpy6d INFO SOLICIT | transaction: a1f15c | answer: normal | client_llip: fe80:0000:0000:0000:0000:c0ff:fea8:0002 | counter: 5 | duid: 0001000130750a150200c0a80002 | ia_options: [3] | iaid: c0a80002 | interface: enp3s0 | last_message_received_type: 1 | mac: 02:00:c0:a8:00:02 | options_request: [23, 24, 39, 31]
2025-10-05 12:52:18,350 dhcpy6d INFO ADVERTISE | transaction: a1f15c | options: [3, 7, 23, 24, 31, 39]  | addresses: 2003:000a:0838:8f00:0000:0000:0000:0002 fd59:3f01:6a1e:2000:0000:0000:0000:0002 2003:000a:0838:8f00:0000:c0ff:fea8:0002 fd59:3f01:6a1e:2000:0000:c0ff:fea8:0002 2003:000a:0838:8f00:0000:c0ff:fea8:0002 fd59:3f01:6a1e:2000:0000:c0ff:fea8:0002 2003:000a:0838:8f00:49aa:d2ac:7c5e:0e41 fd59:3f01:6a1e:2000:2946:f3cb:b212:0bc4 | client_class: default_enp3s0 | hostname: paperless
2025-10-05 12:52:22,393 dhcpy6d INFO SOLICIT | transaction: a1f15c | answer: normal | client_llip: fe80:0000:0000:0000:0000:c0ff:fea8:0002 | counter: 6 | duid: 0001000130750a150200c0a80002 | ia_options: [3] | iaid: c0a80002 | interface: enp3s0 | last_message_received_type: 1 | mac: 02:00:c0:a8:00:02 | options_request: [23, 24, 39, 31]
2025-10-05 12:52:22,393 dhcpy6d INFO ADVERTISE | transaction: a1f15c | options: [3, 7, 23, 24, 31, 39]  | addresses: 2003:000a:0838:8f00:0000:0000:0000:0002 fd59:3f01:6a1e:2000:0000:0000:0000:0002 2003:000a:0838:8f00:0000:c0ff:fea8:0002 fd59:3f01:6a1e:2000:0000:c0ff:fea8:0002 2003:000a:0838:8f00:0000:c0ff:fea8:0002 fd59:3f01:6a1e:2000:0000:c0ff:fea8:0002 2003:000a:0838:8f00:49aa:d2ac:7c5e:0e41 fd59:3f01:6a1e:2000:2946:f3cb:b212:0bc4 | client_class: default_enp3s0 | hostname: paperless

That's how DHCPv6 client reacts on the replies:

After a few retries and some time, DHCPv6 client finally is fine with the packet received and configures the interface. I know, that ISC is dead and Debian seems going to replace it with dhcpcd in the future. I am not willing to that now, since new things have to ripen their time.

Therefore: Do have any clue, what's happening here?

[HenriWahl]

Hi @FelixJacobi,

nice to hear that you still use it. 👍
Well, this sounds interesting. At a first sight the version of the package isc-dhcp-client is the same 4.4.3 in bookworm and trixie, just differs in Debian patches as it could be seen on https://packages.debian.org/bookworm/isc-dhcp-client and https://packages.debian.org/trixie/isc-dhcp-client.
I downloaded http://deb.debian.org/debian/pool/main/i/isc-dhcp/isc-dhcp_4.4.3-P1-2.debian.tar.xz and http://deb.debian.org/debian/pool/main/i/isc-dhcp/isc-dhcp_4.4.3-P1-8.debian.tar.xz for comparison. The great meld-tool showed not much differences, but one which seems to be important:

This patch contains this:

---
 client/dhc6.c     |  3 ++-
 client/dhclient.c | 17 ++++++++++++++---
 common/bpf.c      | 16 ++++++++++++++++
 common/lpf.c      | 16 ++++++++++++++++
 includes/dhcp.h   |  2 ++
 includes/dhcpd.h  |  2 +-
 server/dhcpv6.c   |  3 +++
 7 files changed, 54 insertions(+), 5 deletions(-)

Index: isc-dhcp/client/dhc6.c
===================================================================
--- isc-dhcp.orig/client/dhc6.c
+++ isc-dhcp/client/dhc6.c
@@ -5737,7 +5737,8 @@ make_client6_options(struct client_state
 	 */
 	if ((oc = lookup_option(&dhcpv6_universe, *op,
 				D6O_CLIENTID)) == NULL) {
-		if (!option_cache(&oc, &default_duid, NULL, clientid_option,
+		if (default_duid.len == 0 ||
+		    !option_cache(&oc, &default_duid, NULL, clientid_option,
 				  MDL))
 			log_fatal("Failure assembling a DUID.");
 
Index: isc-dhcp/client/dhclient.c
===================================================================
--- isc-dhcp.orig/client/dhclient.c
+++ isc-dhcp/client/dhclient.c
@@ -870,8 +870,8 @@ main(int argc, char **argv) {
 			if (default_duid.buffer != NULL)
 				data_string_forget(&default_duid, MDL);
 
-			form_duid(&default_duid, MDL);
-			write_duid(&default_duid);
+			if (form_duid(&default_duid, MDL) == ISC_R_SUCCESS)
+				write_duid(&default_duid);
 		}
 	}
 
@@ -3850,7 +3850,7 @@ write_options(struct client_state *clien
  * is not how it is intended.  Upcoming rearchitecting the client should
  * address this "one daemon model."
  */
-void
+isc_result_t
 form_duid(struct data_string *duid, const char *file, int line)
 {
 	struct interface_info *ip;
@@ -3863,6 +3863,15 @@ form_duid(struct data_string *duid, cons
 	if (ip == NULL)
 		log_fatal("Impossible condition at %s:%d.", MDL);
 
+	while (ip && ip->hw_address.hbuf[0] == HTYPE_RESERVED) {
+		/* Try the other interfaces */
+		log_debug("Cannot form default DUID from interface %s.", ip->name);
+		ip = ip->next;
+	}
+	if (ip == NULL) {
+		return ISC_R_UNEXPECTED;
+	}
+
 	if ((ip->hw_address.hlen == 0) ||
 	    (ip->hw_address.hlen > sizeof(ip->hw_address.hbuf)))
 		log_fatal("Impossible hardware address length at %s:%d.", MDL);
@@ -3908,6 +3917,8 @@ form_duid(struct data_string *duid, cons
 		log_info("Created duid %s.", str);
 		dfree(str, MDL);
 	}
+	
+	return ISC_R_SUCCESS;
 }
 
 /* Write the default DUID to the lease store. */
Index: isc-dhcp/common/bpf.c
===================================================================
--- isc-dhcp.orig/common/bpf.c
+++ isc-dhcp/common/bpf.c
@@ -650,6 +650,22 @@ get_hw_addr(const char *name, struct har
                         memcpy(&hw->hbuf[1], LLADDR(sa), sa->sdl_alen);
                         break;
 #endif /* IFT_FDDI */
+#if defined(IFT_PPP)
+                case IFT_PPP:
+                        if (local_family != AF_INET6)
+                             log_fatal("Unsupported device type %d for \"%s\"",
+                                        sa->sdl_type, name);
+                        hw->hlen = 0;
+                        hw->hbuf[0] = HTYPE_RESERVED;
+                        /* 0xdeadbeef should never occur on the wire,
+                         *  and is a signature that something went wrong.
+                         */
+                        hw->hbuf[1] = 0xde;
+                        hw->hbuf[2] = 0xad;
+                        hw->hbuf[3] = 0xbe;
+                        hw->hbuf[4] = 0xef;
+                        break;
+#endif
                 default:
                         log_fatal("Unsupported device type %d for \"%s\"",
                                   sa->sdl_type, name);
Index: isc-dhcp/common/lpf.c
===================================================================
--- isc-dhcp.orig/common/lpf.c
+++ isc-dhcp/common/lpf.c
@@ -563,6 +563,22 @@ get_hw_addr(const char *name, struct har
 			hw->hbuf[0] = HTYPE_FDDI;
 			memcpy(&hw->hbuf[1], sa->sa_data, 6);
 			break;
+#if defined(ARPHRD_PPP)
+		case ARPHRD_PPP:
+			if (local_family != AF_INET6)
+				log_fatal("Unsupported device type %d for \"%s\"",
+				           sa->sa_family, name);
+			hw->hlen = 0;
+			hw->hbuf[0] = HTYPE_RESERVED;
+			/* 0xdeadbeef should never occur on the wire,
+			 * and is a signature that something went wrong.
+			 */
+			hw->hbuf[1] = 0xde;
+			hw->hbuf[2] = 0xad;
+			hw->hbuf[3] = 0xbe;
+			hw->hbuf[4] = 0xef;
+			break;
+#endif
 		default:
 			log_fatal("Unsupported device type %ld for \"%s\"",
 				  (long int)sa->sa_family, name);
Index: isc-dhcp/includes/dhcp.h
===================================================================
--- isc-dhcp.orig/includes/dhcp.h
+++ isc-dhcp/includes/dhcp.h
@@ -80,6 +80,8 @@ struct dhcp_packet {
 					 * is no standard for this so we
 					 * just steal a type            */
 
+#define HTYPE_RESERVED	0		/* RFC 5494 */
+
 /* Magic cookie validating dhcp options field (and bootp vendor
    extensions field). */
 #define DHCP_OPTIONS_COOKIE	"\143\202\123\143"
Index: isc-dhcp/includes/dhcpd.h
===================================================================
--- isc-dhcp.orig/includes/dhcpd.h
+++ isc-dhcp/includes/dhcpd.h
@@ -3067,7 +3067,7 @@ void client_dns_remove(struct client_sta
 
 void dhcpv4_client_assignments(void);
 void dhcpv6_client_assignments(void);
-void form_duid(struct data_string *duid, const char *file, int line);
+isc_result_t form_duid(struct data_string *duid, const char *file, int line);
 
 void dhcp4o6_start(void);
 
Index: isc-dhcp/server/dhcpv6.c
===================================================================
--- isc-dhcp.orig/server/dhcpv6.c
+++ isc-dhcp/server/dhcpv6.c
@@ -482,6 +482,9 @@ generate_new_server_duid(void) {
 		if (p->hw_address.hlen > 0) {
 			break;
 		}
+		if (p->next == NULL && p->hw_address.hbuf[0] == HTYPE_RESERVED) {
+			log_error("Can not generate DUID from interfaces which do not have hardware addresses, please configure server-duid!");
+		}
 	}
 	if (p == NULL) {
 		return ISC_R_UNEXPECTED;

This clearly has some small change for the DHCPv6 client. Maybe this may point into the right direction, somehow. Maybe try to install the bookworm-package on a trixie-client to make sure. Maybe the author of this patch could be contacted to make sure this patch might interfere here somehow?

I might record some traffic between dhcpy6d and bookworm/trixie clients to see if there are any significant indicators.

Best regards
Henri

[HenriWahl]

@FelixJacobi can you increase the log level of the client on trixie?

[FelixJacobi]

Client is actually on Bookworm, I will do, as soon as I re-see this bug.

[HenriWahl]

@FelixJacobi in the comparison between bookworm and trixie there are some more apparmor files involved - might this be a source of trouble too?

Another idea: did you test with a fresh trixie host too, to make sure no garbage from upgrade interferes here?

[FelixJacobi]

No, not yet, but I surly can try this.