Date: Thu, 19 Jun 2025 10:21:03 +0200 (CEST) From: Ronald Klop <ronald-lists@klop.ws> To: Karl Denninger <karl@denninger.net> Cc: freebsd-net@freebsd.org Subject: Re: dhcpcd(8) into FreeBSD base Message-ID: <1188806329.62817.1750321263908@localhost> In-Reply-To: <bf3f1d62-70bb-4191-82ae-d8c9358d0b47@denninger.net> References: <e401671f-6a67-49ed-bc41-e8fbb9de27cb@www.fastmail.com> <CAPyFy2BackF0FshyjfV6qoOoJjFqiqcu%2BVxx9X_%2BRHpepOXTsw@mail.gmail.com> <18ff2d4772a.129dde187836962.5411001908566459400@marples.name> <bf3f1d62-70bb-4191-82ae-d8c9358d0b47@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
------=_Part_62812_84339164.1750321263682
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Hi,
I don't know the details about your setup, but I tried dhcpcd in my network=
last few months and I encountered that it:
- runs fine in a 14.X jail on a 14.X machine (RPI3B) for both IP4 and IP6 =
=F0=9F=91=8D
- it does not work well on a 14.X jail on a 15.x machines. (RPI4)
The symptoms look a lot like what you describe. Sometimes it got an address=
and a day later it was gone again. Restarting sometimes helped, often didn=
't change anything.
Up to the point that I started reading to code of dhcpcd and encountered th=
at it writes a line in the log about getting a lease and the next statement=
was sending a packet out on the network and I never see that packet in tcp=
dump.
Anyway on the RPI3 I still use it. On the RPI4 I went back to dhclient + SL=
AAC after I put a lot of time in tcpdumping and testing. Maybe it is just t=
hat 14 userland doesn't match enough with 15 kernel to do BPF/dhcp. But tha=
n again.... with dhclient it works fine.
I didn't run dhcpcd yet on the host OS yet as I was first testing it in the=
VNET jails.
Just my 2 cents.
Regards,
Ronald.
=20
Van: Karl Denninger <karl@denninger.net>
Datum:donderdag, 19 juni 2025 00:00
Aan:freebsd-net@freebsd.org
Onderwerp:dhcpcd(8) into FreeBSD base
>=20
> Resurrecting an older thread....
>=20
> I have Kub Fiber here and have run into an interesting problem I've not s=
een on anything else (this same config, absent dhcpcd but on the stock Free=
BSD config, worked fine on both Cox and Spectrum without changes.)
>=20
> On a first use dhcpcd gets both IPv4 and IPv6 addresses, but sometimes th=
e IPv4 side fails to be able to ARP (!!!!) the other end. If I drop the in=
terface (ifconfig ix0 down; ifconfig ix0 up) it never fails on the second t=
ry. If it fails on the first try doing a "arp -d" on the other end resolve=
s nothing; only recycling the interface does. Once it comes up its 100% st=
able and never drops it. Obviously with no arp for the other end you get n=
othing (in either direction.)
>=20
> That I can handle (but its damned annoying) with a script that checks con=
nection to the other side and, if it can't get anything, does the above.
>=20
> The more serious problem is with Ipv6. If I shut down my gear (and the c=
ompany's ONT) and then turn the power back on (say, because I need to work =
on the UPS in my rack!) it will come back up on IpV4 but never gets an answ=
er to the SOLICIT response. It also never sees anything from the neighbor =
request!
>=20
> In other words ("tcpdump -i ip6 ix0"):
>=20
> 14:42:25.301564 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6,=
neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32
> 14:42:30.573650 IP6 fe80::2e0:b4ff:fe68:f894 > ff02::2: ICMP6, router sol=
icitation, length 16
> 14:42:31.594474 IP6 fe80::2e0:b4ff:fe68:f894.dhcpv6-client > ff02::1:2.dh=
cpv6-server: dhcp6 solicit
> 14:42:32.690063 IP6 fe80::2e0:b4ff:fe68:f894.dhcpv6-client > ff02::1:2.dh=
cpv6-server: dhcp6 solicit
> 14:42:34.506030 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6,=
neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32
> 14:42:34.574904 IP6 fe80::2e0:b4ff:fe68:f894 > ff02::2: ICMP6, router sol=
icitation, length 16
> 14:42:34.764176 IP6 fe80::2e0:b4ff:fe68:f894.dhcpv6-client > ff02::1:2.dh=
cpv6-server: dhcp6 solicit
> 14:42:35.501814 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6,=
neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32
> 14:42:35.934710 IP6 2a06:4880:4000::68.53490 > 2606:83c0:8000:ff00:ba27:e=
bff:fe39:701d.4567: Flags [S], seq 605251823, win 14600, options [mss 1440]=
, length 0
> 14:42:36.509588 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6,=
neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32
> 14:42:38.580627 IP6 fe80::2e0:b4ff:fe68:f894 > ff02::2: ICMP6, router sol=
icitation, length 16
> 14:42:38.732812 IP6 fe80::2e0:b4ff:fe68:f894.dhcpv6-client > ff02::1:2.dh=
cpv6-server: dhcp6 solicit
> 14:42:40.337515 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6,=
neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32
> 14:42:41.321509 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6,=
neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32
> 14:42:42.329737 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6,=
neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32
> 14:42:42.595011 IP6 fe80::2e0:b4ff:fe68:f894 > ff02::2: ICMP6, router sol=
icitation, length 16
> 14:42:44.782492 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6,=
neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32
> 14:42:45.749503 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6,=
neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32
> 14:42:46.745515 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6,=
neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32
> 14:42:47.109267 IP6 fe80::2e0:b4ff:fe68:f894.dhcpv6-client > ff02::1:2.dh=
cpv6-server: dhcp6 solicit
> 14:42:48.809742 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6,=
neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32
> 14:42:49.805572 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6,=
neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32
> 14:42:50.801697 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6,=
neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32
>=20
> The interface is up and is passing Ip4 traffic.
>=20
> And even more odd I get this once in a while:
>=20
> 14:45:26.688858 IP6 enviable.census.internet-measurement.com.53565 > 2606=
:83c0:8600::10c.58222: Flags [S], seq 3619826346, win 14600, options [mss 1=
440], length 0
> 14:45:26.696834 IP6 stupendous.census.internet-measurement.com.53321 > 26=
06:83c0:8600::10c.rsf-1: Flags [S], seq 3940102705, win 14600, options [mss=
1440], length 0
>=20
> The prefix IS part of the provider's delegation but I have no IPv6 addres=
s so I have absolutely no idea how they think routing that to me is reasona=
ble -- but they do.
>=20
> They're pointing at "my gear" as I'm not using their router. Uh, yeah, o=
k. Its not hardware -- the same thing happens on a pcEngines box with two =
"igb" interfaces, a "cube" box that has two "re" interfaces and my current =
box (which I want to keep using) that has two SFP+ interfaces that come up =
on the "ix" driver. All behave exactly the same way.
>=20
> If I call and bitch they reset everything on their end and it comes up --=
once and from there its stable. But if I take a power hit beyond my UPS's=
capacity, well, it'll happen again.
>=20
> I see absolutely nothing in tcpdump that implies there's a problem, other=
than that when this happens they never answer anything I send them. They =
claim their dhcp6 server has locked out my MAC due to "invalid" things they=
're seeing from me. Well, it can't be coming from the inside devices becau=
se (1) there's no route until IPv6 comes up except for the link-local, whic=
h I verify is in fact there but there is no default route until they send i=
t and I receive it and therefore its ridiculously implausible any inside de=
vice with a "stale" IPv6 address is sending, and everything in the rack (th=
is last time at least) went down with the power and all that gets its IPv6 =
by SLACC -- so until it gets a delegation it obviously didn't have any.
>=20
> I'm trying to get their engineering people on the line to get a packet ca=
pture while I power cycle and see exactly why they're getting big-mad but m=
y suspicion is that their ONT is in some way obtaining and forwarding thing=
s before it negotiates fully -- which of course it shouldn't, but.....=20
>=20
> Any ideas here? Once it comes up its completely stable, but obviously a =
power loss while I'm not around is going to be a pain in the neck. One thi=
ng I've contemplated is sticking a delay in the rc script for dhcpcd so it =
doesn't start for a bit after a boot, which perhaps gives the port time to =
negotiate. Since it does the same thing with an igb, re, and ix port (with=
a 1G SFP transceiver in it) I assume the issue has nothing to do per se wi=
th negotiation, but somehow their end is getting "big mad" with me when it =
comes to IPv6 delegations and once it does it never clears it on its own.
>=20
> Putting this in freebsd-net rather than directly to Roy because I see the=
same behavior using the "stock" dhcp6c client......
>=20
> On 6/7/2024 09:12, Roy Marples wrote:
>>=20
>> Hi Ed
>>=20
>> ---- On Thu, 06 Jun 2024 02:48:36 +0100 Ed Maste wrote ---=20
>> > On Sun, 7 Aug 2022 at 01:32, Ben Woods woodsb02@freebsd.org> wrote:
>> > In the previous threads some objections were raised about dhcpcd's
>> > lack of sandboxing (Capsicum / privilege separation), which has since
>> > been addressed.
>> >=20
>> > I would like to start building and installing dhcpcd by default so
>> > that it is available for testing and experimentation. I do not intend
>> > to replace dhclent or rtsold, at least without more information, test
>> > results, and consensus.
>>=20
>> That's nice news, thanks for carrying the torch here :)
>>=20
>>=20
>=20
> --
> Karl Denninger
> karl@denninger.net
> The Market Ticker
> [S/MIME encrypted email preferred]
> =20
=20
------=_Part_62812_84339164.1750321263682
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body>Hi,<br>
<br>
I don't know the details about your setup, but I tried dhcpcd in my network=
last few months and I encountered that it:<br>
<br>
- runs fine in a 14.X jail on a 14.X machine (RPI3B) for both IP4 and IP6 =
=F0=9F=91=8D<br>
- it does not work well on a 14.X jail on a 15.x machines. (RPI4)<br>
<br>
The symptoms look a lot like what you describe. Sometimes it got an address=
and a day later it was gone again. Restarting sometimes helped, often didn=
't change anything.<br>
Up to the point that I started reading to code of dhcpcd and encountered th=
at it writes a line in the log about getting a lease and the next statement=
was sending a packet out on the network and I never see that packet in tcp=
dump.<br>
<br>
Anyway on the RPI3 I still use it. On the RPI4 I went back to dhclient + SL=
AAC after I put a lot of time in tcpdumping and testing. Maybe it is just t=
hat 14 userland doesn't match enough with 15 kernel to do BPF/dhcp. But tha=
n again.... with dhclient it works fine.<br>
<br>
I didn't run dhcpcd yet on the host OS yet as I was first testing it in the=
VNET jails.<br>
<br>
Just my 2 cents.<br>
<br>
Regards,<br>
Ronald.<br>
<br>
<p><strong>Van:</strong> Karl Denninger <karl@denninger.net><br>
<strong>Datum:</strong>donderdag, 19 juni 2025 00:00<br>
<strong>Aan:</strong>freebsd-net@freebsd.org<br>
<strong>Onderwerp:</strong>dhcpcd(8) into FreeBSD base</p>
<blockquote style=3D"padding-right: 0px; padding-left: 5px; margin-left: 5p=
x; border-left: #000000 2px solid; margin-right: 0px">
<div class=3D"MessageRFC822Viewer" id=3D"P">
<div class=3D"MultipartMixedViewer">
<div class=3D"MultipartAlternativeViewer">
<div class=3D"TextHTMLViewer" id=3D"P.P.P1.P">
<p>Resurrecting an older thread....</p>
<p>I have Kub Fiber here and have run into an interesting problem I've not =
seen on anything else (this same config, absent dhcpcd but on the stock Fre=
eBSD config, worked fine on both Cox and Spectrum without changes.)</p>
<p>On a <b><u>first use</u></b> dhcpcd gets both IPv4 and IPv6 ad=
dresses, <i>but </i>sometimes the IPv4 side fails to be able to A=
RP (!!!!) the other end. If I drop the interface (ifconfig ix0 down; =
ifconfig ix0 up) it <i>never </i>fails on the second try. I=
f it fails on the first try doing a "arp -d" on the other end <i>resol=
ves nothing; </i>only recycling the interface does. Once it come=
s up its 100% stable and <i>never </i>drops it. Obviously w=
ith no arp for the other end you get nothing (in either direction.)</p>
<p>That I can handle (but its damned annoying) with a script that checks co=
nnection to the other side and, if it can't get anything, does the above.</=
p>
<p>The <i>more serious </i>problem is with Ipv6. If I shut =
down my gear (<b><u>and</u></b> the company's ONT) and then turn the p=
ower back on (say, because I need to work on the UPS in my rack!) <i>i=
t will come back up on IpV4 but never gets an answer to the SOLICIT respons=
e. </i>It also never sees anything from the neighbor request!</p=
>
<p>In other words ("tcpdump -i ip6 ix0"):</p>
<p>14:42:25.301564 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: IC=
MP6, neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32<br=
>
14:42:30.573650 IP6 fe80::2e0:b4ff:fe68:f894 > ff02::2: ICMP6, router so=
licitation, length 16<br>
14:42:31.594474 IP6 fe80::2e0:b4ff:fe68:f894.dhcpv6-client > ff02::1:2.d=
hcpv6-server: dhcp6 solicit<br>
14:42:32.690063 IP6 fe80::2e0:b4ff:fe68:f894.dhcpv6-client > ff02::1:2.d=
hcpv6-server: dhcp6 solicit<br>
14:42:34.506030 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6=
, neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32<br>
14:42:34.574904 IP6 fe80::2e0:b4ff:fe68:f894 > ff02::2: ICMP6, router so=
licitation, length 16<br>
14:42:34.764176 IP6 fe80::2e0:b4ff:fe68:f894.dhcpv6-client > ff02::1:2.d=
hcpv6-server: dhcp6 solicit<br>
14:42:35.501814 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6=
, neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32<br>
14:42:35.934710 IP6 2a06:4880:4000::68.53490 > 2606:83c0:8000:ff00:ba27:=
ebff:fe39:701d.4567: Flags [S], seq 605251823, win 14600, options [mss 1440=
], length 0<br>
14:42:36.509588 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6=
, neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32<br>
14:42:38.580627 IP6 fe80::2e0:b4ff:fe68:f894 > ff02::2: ICMP6, router so=
licitation, length 16<br>
14:42:38.732812 IP6 fe80::2e0:b4ff:fe68:f894.dhcpv6-client > ff02::1:2.d=
hcpv6-server: dhcp6 solicit<br>
14:42:40.337515 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6=
, neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32<br>
14:42:41.321509 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6=
, neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32<br>
14:42:42.329737 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6=
, neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32<br>
14:42:42.595011 IP6 fe80::2e0:b4ff:fe68:f894 > ff02::2: ICMP6, router so=
licitation, length 16<br>
14:42:44.782492 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6=
, neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32<br>
14:42:45.749503 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6=
, neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32<br>
14:42:46.745515 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6=
, neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32<br>
14:42:47.109267 IP6 fe80::2e0:b4ff:fe68:f894.dhcpv6-client > ff02::1:2.d=
hcpv6-server: dhcp6 solicit<br>
14:42:48.809742 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6=
, neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32<br>
14:42:49.805572 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6=
, neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32<br>
14:42:50.801697 IP6 fe80::3a94:edff:fe47:f2f8 > ff02::1:ff0b:946d: ICMP6=
, neighbor solicitation, who has fe80::6a22:8e00:c80b:946d, length 32</p>
<p><b>The interface is up and is passing Ip4 traffic.</b></p>
<p>And even <i>more odd </i>I get this once in a while:</p>
<p>14:45:26.688858 IP6 enviable.census.internet-measurement.com.53565 > =
2606:83c0:8600::10c.58222: Flags [S], seq 3619826346, win 14600, options [m=
ss 1440], length 0<br>
14:45:26.696834 IP6 stupendous.census.internet-measurement.com.53321 > 2=
606:83c0:8600::10c.rsf-1: Flags [S], seq 3940102705, win 14600, options [ms=
s 1440], length 0</p>
<p>The prefix IS part of the provider's delegation but I have no IPv6 addre=
ss so I have <i>absolutely no idea </i>how they think routing tha=
t to me is reasonable -- but they do.</p>
<p>They're pointing at "my gear" as I'm not using their router. Uh, y=
eah, ok. Its not hardware -- the same thing happens on a pcEngines bo=
x with two "igb" interfaces, a "cube" box that has two "re" interfaces and =
my current box (which I want to keep using) that has two SFP+ interfaces th=
at come up on the "ix" driver. <i>All behave exactly the same wa=
y.</i></p>
<p>If I call and bitch they reset <i>everything </i>on their end =
and it comes up -- once and from there its stable. But if I take a po=
wer hit beyond my UPS's capacity, well, it'll happen again.</p>
<p>I see absolutely nothing in tcpdump that implies there's a problem, othe=
r than that when this happens they never answer <i>anything </i>I send=
them. They claim their dhcp6 server has locked out my MAC due to "in=
valid" things they're seeing from me. Well, it can't be coming from t=
he inside devices because (1) there's no route until IPv6 comes up except f=
or the link-local, which I verify is in fact there but there is no default =
route until they send it and I receive it and therefore its ridiculously im=
plausible any inside device with a "stale" IPv6 address is sending, and eve=
rything in the rack (this last time at least) went down with the power and =
all that gets its IPv6 by SLACC -- so until it gets a delegation it obvious=
ly didn't have any.</p>
<p>I'm trying to get their engineering people on the line to get a packet c=
apture while I power cycle and see <i>exactly </i>why they're get=
ting big-mad but my <i>suspicion </i>is that their ONT is in some=
way obtaining and forwarding things before it negotiates fully -- which of=
course it shouldn't, but..... </p>
<p>Any ideas here? Once it comes up its completely stable, but obviou=
sly a power loss while I'm not around is going to be a pain in the neck.&nb=
sp; One thing I've contemplated is sticking a delay in the rc script for dh=
cpcd so it doesn't start for a bit after a boot, which <i>perhaps =
;</i>gives the port time to negotiate. Since it does the same thing w=
ith an igb, re, and ix port (with a 1G SFP transceiver in it) I assume the =
issue has nothing to do <i>per se </i>with negotiation, but someh=
ow their end is getting "big mad" with me when it comes to IPv6 delegations=
and once it does <i>it never clears it on its own.</i></p>
<p>Putting this in freebsd-net rather than directly to Roy because I see th=
e <i>same </i>behavior using the "stock" dhcp6c client......</p>
<div class=3D"moz-cite-prefix">On 6/7/2024 09:12, Roy Marples wrote:</div>
<blockquote>
<pre class=3D"moz-quote-pre">Hi Ed
---- On Thu, 06 Jun 2024 02:48:36 +0100 Ed Maste wrote ---=20
> On Sun, 7 Aug 2022 at 01:32, Ben Woods <a class=3D"moz-txt-link-abbre=
viated" href=3D"mailto:woodsb02@freebsd.org">woodsb02@freebsd.org</a>> w=
rote:
> In the previous threads some objections were raised about dhcpcd's
> lack of sandboxing (Capsicum / privilege separation), which has since
> been addressed.
>=20
> I would like to start building and installing dhcpcd by default so
> that it is available for testing and experimentation. I do not intend
> to replace dhclent or rtsold, at least without more information, test
> results, and consensus.
That's nice news, thanks for carrying the torch here :)
</pre>
</blockquote>
<div class=3D"moz-signature">--<br>
Karl Denninger<br>
<a class=3D"moz-txt-link-freetext" href=3D"mailto:karl@denninger.net">karl@=
denninger.net</a><br>
<i>The Market Ticker</i><br>
<font size=3D"-2"><i>[S/MIME encrypted email preferred]</i></font></div>
</div>
</div>
<div class=3D"DefaultViewer"> </div>
</div>
</div>
</blockquote>
<br>
</body></html>
------=_Part_62812_84339164.1750321263682--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1188806329.62817.1750321263908>