NetBSD Problem Report #59677

From www@netbsd.org  Tue Sep 30 11:45:40 2025
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 165F81A9239
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 30 Sep 2025 11:45:40 +0000 (UTC)
Message-Id: <20250930114538.A4F2E1A923C@mollari.NetBSD.org>
Date: Tue, 30 Sep 2025 11:45:38 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: dhcpcd: slaac config change not handled by stop/edit/start
X-Send-Pr-Version: www-1.0

>Number:         59677
>Category:       bin
>Synopsis:       dhcpcd: slaac config change not handled by stop/edit/start
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Sep 30 11:50:00 +0000 2025
>Originator:     Taylor R Campbell
>Release:        10.1
>Organization:
The NetDHCPCD Fe80dation
>Environment:
NetBSD netbsd 10.1_STABLE NetBSD 10.1_STABLE (amd64-DOMU_SERVER) #3: Sat Jun 21 13:32:10 UTC 2025  spz@franklin.NetBSD.org:/home/netbsd/10/amd64/obj/sys/arch/amd64/compile/amd64-DOMU_SERVER amd64
>Description:

	Changing dhcpcd(8) from `slaac private' to `slaac hwaddr'
	by

		service dhcpcd stop
		edit /etc/dhcpcd.conf
		service dhcpcd start

	doesn't take effect gracefully without a reboot or manual
	intervention -- the random fe80 and slaac addresses remain
	configured (and a second slaac address gets configured), and no
	hwaddr fe80 or slaac addresses get configured by this.

	While the alternative

		edit /etc/dhcpcd.conf
		service dhcpcd reload

	appears to work, it doesn't fit with the ordering of bringing
	services down (e.g., shutdown to single-user mode) and then
	bringing them back up again, particularly when applying a whole
	new network configuration.  (Really we should have a way for
	the host to provide the whole network configuration _before_
	dhcpcd starts in the first place, but we don't right now.)


>How-To-Repeat:

	1. Boot a fresh live image.  For example, on a Xen host:

xenhost# lvm lvcrate --size 4g --name test20250930 guests
xenhost# ftp -o - https://ftp.NetBSD.org/pub/NetBSD/images/10.1/NetBSD-10.1-amd64-live.img.gz | progress -z dd ibs=64k obs=1m of=/dev/mapper/rguests-test20250930'
xenhost# cat <<'EOF' >/usr/pkg/etc/xen/test20250930
> # Testing a dhcpcd bug.
> kernel = "/home/netbsd/amd64-nb10/netbsd"
> memory = 1024
> name = "test20250930"
> cpus = ["1-15"]
> vcpus = 1
> vif = [ 'mac=aa:de:ad:be:e2:0b, bridge=bridge0' ]
> disk = [ '/dev/mapper/guests-test20250930,raw,0x1,w' ]
> EOF
xenhost# xl create -c /usr/pkg/etc/xen/test20250930

	2. At boot, note that dhcpcd(8) has configured a random fe80
	   address:

[   1.0000030] xennet0 at xenbus0 id 0: Xen Virtual Network Interface
[   1.0000030] xennet0: backend features 0x7<IPV6-CSUM,SG,RX-COPY>
[   1.0000030] xennet0: MAC address aa:de:ad:be:e2:0b
...
Starting network.
Hostname: netbsd
IPv6 mode: host
Configuring network interfaces:.
Adding interface aliases:.
Waiting for duplicate address detection to finish...
Starting dhcpcd.
...
netbsd# ifconfig xennet0
xennet0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        capabilities=0x3fc00<TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx>
        capabilities=0x3fc00<TCP6CSUM_Rx,TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx>
        enabled=0
        ec_capabilities=0x5<VLAN_MTU,JUMBO_MTU>
        ec_enabled=0
        address: aa:de:ad:be:e2:0b
        inet6 fe80::aca6:a93c:8a6b:ef3e%xennet0/64 flags 0 scopeid 0x1
        inet6 2001:470:a085:999:970:35ed:caf3:b8c1/64 flags 0x40<AUTOCONF>
        inet 169.254.115.94/16 broadcast 169.254.255.255 flags 0

	   If it were a hwaddr-based fe80 address, it would have

        inet6 fe80::aade:adff:febe:e20b%xennet0/64 flags 0 scopeid 0x1

	   instead.

	3. Stop dhcpcd, switch from `slaac private' to `slaac hwaddr'
	   in /etc/dhcpcd.conf, and start dhcpcd again:

netbsd# service dhcpcd stop
Stopping dhcpcd.
netbsd# grep slaac /etc/dhcpcd.conf
#slaac hwaddr
slaac private
netbsd# printf '/^slaac private/s/^/#/\n/slaac hwaddr/s/^#*//\nw\n' | ed -s /etc/dhcpcd.conf
netbsd# grep slaac /etc/dhcpcd.conf
slaac hwaddr
#slaac private
netbsd# service dhcpcd start

	4. Now dhcpcd(8) has configured _two_ random slaac addresses
	   for xennet0, and no hwaddr addresses:

netbsd# ifconfig xennet0
xennet0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        capabilities=0x3fc00<TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx>
        capabilities=0x3fc00<TCP6CSUM_Rx,TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx>
        enabled=0
        ec_capabilities=0x5<VLAN_MTU,JUMBO_MTU>
        ec_enabled=0
        address: aa:de:ad:be:e2:0b
        inet6 fe80::aca6:a93c:8a6b:ef3e%xennet0/64 flags 0 scopeid 0x1
        inet6 2001:470:a085:999:970:35ed:caf3:b8c1/64 flags 0x40<AUTOCONF>
        inet6 2001:470:a085:999:aca6:a93c:8a6b:ef3e/64 flags 0x40<AUTOCONF>
        inet 169.254.115.94/16 broadcast 169.254.255.255 flags 0


>Fix:

	Yes, please!

Home	PR Database Search