From nobody Tue Nov 04 20:14:28 2025 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4d1KS83Nkkz6FDL8 for ; Tue, 04 Nov 2025 20:14:48 +0000 (UTC) (envelope-from pusateri@keehole.org) Received: from kem.keehole.org (kem.keehole.org [136.41.224.255]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4d1KS73QMrz49Ly for ; Tue, 04 Nov 2025 20:14:47 +0000 (UTC) (envelope-from pusateri@keehole.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=keehole.org header.s=202408 header.b=WUX5ycGI; dmarc=pass (policy=none) header.from=keehole.org; spf=pass (mx1.freebsd.org: domain of pusateri@keehole.org designates 136.41.224.255 as permitted sender) smtp.mailfrom=pusateri@keehole.org Received: from smtpclient.apple (dhcp-67-145-164-9.gobrightspeed.net [67.145.164.9]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by kem.keehole.org (Postfix) with ESMTPSA id EE477203C8; Tue, 04 Nov 2025 15:14:40 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=keehole.org; s=202408; t=1762287281; bh=0EFpo2EnWaO8tsJlzi0AM6eoSNM4rBpuRhdEH4PwqYE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=WUX5ycGImg1T8P3Yhlh3oGbJZZBs3+PKu4Wq/wQi3kFTyn8wCe38eEJOswtIDhcwc qJmHwHDhBQcNA39rBofUG8ysHX0BMA7wsrfewCUohZS9rJ5A6Yv82Y5QFhDZil2tzz hAMvVL1ULPomtEIFHDFtxtcfPhUu9UJDghsYcH/6aqxJQm1ougJh0LwJ6E8CNYPBVm pZMENBkoa0BDdtW8mGOfUJ5Rn2LZ5Fmfp6lu709mHveFalyDNXLJ7tTVwMgQyBwLef QP3BH0HnONe1wsYajZXVeREJr4zRdpVLZ+2PfRqKTB1mXScJQb+3DMCVgjnpBF+2Tt hq3ExhsY64okQ== Content-Type: text/plain; charset=utf-8 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\)) Subject: Re: IPv6 routing, Verizon FiOS, dhcpcd From: Tom Pusateri In-Reply-To: Date: Tue, 4 Nov 2025 15:14:28 -0500 Cc: freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A0A976D-EB8A-4ABF-B216-3CB6358C2559@distal.com> To: Chris Ross X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.79 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.995]; DMARC_POLICY_ALLOW(-0.50)[keehole.org,none]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[keehole.org:s=202408]; ONCE_RECEIVED(0.20)[]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[keehole.org:+]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:16591, ipnet:136.32.0.0/11, country:US]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_RCPT(0.00)[freebsd]; TO_DN_SOME(0.00)[] X-Rspamd-Queue-Id: 4d1KS73QMrz49Ly Does the same problem occur with KAME DHCP client and if so, does the = same delay fix the problem at boot? I use the KAME dhcp6 client still = (dhcp6-20080615) and it doesn=E2=80=99t seem to have this problem for me = but I am using a different upstream provider. It sounds like dhcpcd is not handling dynamic interfaces correctly. Tom > On Nov 4, 2025, at 2:48=E2=80=AFPM, Chris Ross = wrote: >=20 > Apologies for top-post, but the earlier retained below is little more = than > trimmed history. I wanted to come back to this for advice. What I = have done > to solve (aka work around) this problem for myself is two changes in > /usr/local/etc/rc.d/dhcpcd: >=20 > =E2=80=94=E2=80=948<=E2=80=94=E2=80=948<=E2=80=94=E2=80=948<=E2=80=94=E2= =80=948<=E2=80=94=E2=80=948<=E2=80=94=E2=80=94 > --- dhcpcd.orig 2024-10-13 12:22:44.181922000 -0400 > +++ dhcpcd 2025-10-06 13:41:14.523012000 -0400 > @@ -1,6 +1,7 @@ > #!/bin/sh > # PROVIDE: dhclient dhcpcd > +# REQUIRE: netif > # KEYWORD: nojailvnet > # > @@ -29,6 +30,23 @@ > { > # dhcpcd may need local binaries > export PATH=3D${PATH}:/usr/local/sbin:/usr/local/bin > +} > + > +start_postcmd=3D"dhcpcd_pause" > +dhcpcd_pause() > +{ > + boottime=3D`sysctl -n kern.boottime | sed -e 's/.*sec =3D = \([0-9]*\),.*/\1/'` > + now=3D`date +%s` > + # When running at boot, it'll take a while to initially set up the > + # interfaces such that the addresses et al can be bound, I don't > + # know why, but in the normal case if I don't wait here, = local_unbound > + # cannot bind port 53 on one or more of the addresses. > + if [ `expr $now - $boottime` -lt 90 ]; then > + stdbuf -o 0 echo "${name} waiting for addresses to stabilize ... " > + sleep 2 > + echo "done" > + fi > + > } > load_rc_config $name > =E2=80=94=E2=80=948<=E2=80=94=E2=80=948<=E2=80=94=E2=80=948<=E2=80=94=E2= =80=948<=E2=80=94=E2=80=94 >=20 > Part 1 is what avoids the problem I was originally seeing. If I delay > dhcpcd starting until after the interfaces are all online, it is able > to successfully talk with the next-hop router. I still do not know = why > it is failing to reach the IPv6 next-hop when it is, and why starting > dhcpcd later avoids the problem. Any thoughts welcome. > Part 2 above is for the problem I mentioned in a second email about > interface renaming. It turns out that if local_unbound tries to bind > to the address that dhcpcd has _just_ shoved onto the interface, it > will fail. The above delay avoids this problem. >=20 > The problem, of course, is that I=E2=80=99ve changed dhcpcd to run = _after_ netif, > which is not a general solution. For anyone using dhcpcd to do it=E2=80= =99s normal > job of obtaining addresses, it needs to run before or as part of = netif. > So, so that I don=E2=80=99t need to maintain my own separate version = of this > that is unusable upstream, what can I do to figure out why starting > dhcpcd later (after IPv4 is fully operational or something else in = netif), > is required to avoid the problem? >=20 > Thanks. >=20 > - Chris >=20 >> On 6 Oct 2025, at 13:59, Chris Ross wrote: >>=20 >> [=E2=80=A6] What I am _not_ seeing in tcpdump is=20 >> neighbor advertisements in response to my NS=E2=80=99s. At least, = when >> the problem is occurring. I can wait for hours, and I never get >> an NA for the router I=E2=80=99m NS=E2=80=99ing for. >>=20 >> I see now that in my test where I delayed dhcpcd startup, I do get >> NS back, so that makes sense. But I can=E2=80=99t imagine how when I = start >> dhcpcd affects whether or not Verizon responds to my NS. >>=20 >>> Does this act the same with another DHCPv6 client like KAME dhcp6c = instead of using dhcpcd? >>=20 >> I have not tested others. Again, I don=E2=80=99t think it=E2=80=99s = a DHCP thing, >> The DHCP part is actually working. It=E2=80=99s that something else = is >> happening at an addressing level. >=20 >=20 >=20 >=20