From nobody Thu Jun 19 08:21:03 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 4bND8V5k0Sz5yMGy for ; Thu, 19 Jun 2025 08:21:14 +0000 (UTC) (envelope-from SRS0=ghkO=ZC=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int-backup.realworks.nl (smtp-relay-int-backup.realworks.nl [87.255.56.188]) (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 4bND8V0B8zz3nCs for ; Thu, 19 Jun 2025 08:21:13 +0000 (UTC) (envelope-from SRS0=ghkO=ZC=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; none Received: from smtp-relay-int-backup.realworks.nl (crmlive3.colo2.realworks.nl [10.2.52.23]) by mailrelayint1.colo2.realworks.nl (Postfix) with ESMTP id 4bND8J2njZz1Fq; Thu, 19 Jun 2025 10:21:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1750321264; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TszEFAgry4dw5M5JY28F1il3tICdPGnEoevRKK0t21A=; b=WTVFESYkI9BozG0DcW0HzCUDIHcoxUx4F6Gq9wR+P2uecWEqldZe06uPMU8YHPstF8efSV APGy1B8AOv5OXKGW2hW6BtKrTIMtyGaiMfyTeuyAAP23FUoFfNa55hiXlQyEGgo2V/YMIY quoGQJ30VaC79wBwLnV3RTEUgDbJq+qK80MjdJ7liK+tzlxJZRqlOVOH++m9Hszi9jthnc 9CRpQGIqF47LienpFPX+vrAnbUZrko2XMm5dujaSFhoWp299etWpeyX9qQpoOGlRLSAiiI 8/qlalUVT0Sit4CY3I3Ku0wLzJSpMNn1fLYdTc420KANEOwYH/KObYjlMgCyBA== Received: from crmlive3.colo2.realworks.nl (localhost [127.0.0.1]) by crmlive3.colo2.realworks.nl (Postfix) with ESMTP id 0D6DF2A02EA; Thu, 19 Jun 2025 10:21:03 +0200 (CEST) Date: Thu, 19 Jun 2025 10:21:03 +0200 (CEST) From: Ronald Klop To: Karl Denninger Cc: freebsd-net@freebsd.org Message-ID: <1188806329.62817.1750321263908@localhost> In-Reply-To: References: <18ff2d4772a.129dde187836962.5411001908566459400@marples.name> Subject: Re: dhcpcd(8) into FreeBSD base 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 Content-Type: multipart/alternative; boundary="----=_Part_62812_84339164.1750321263682" X-Mailer: Realworks (752.24) X-Originating-Host: from (83-81-212-149.cable.dynamic.v4.ziggo.nl [83.81.212.149]) by crmlive3 [10.2.52.23] with HTTP; Thu, 19 Jun 2025 10:21:03 +0200 Importance: Normal X-Priority: 3 (Normal) X-Originating-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:139.0) Gecko/20100101 Firefox/139.0 X-Rspamd-Queue-Id: 4bND8V0B8zz3nCs X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:38930, ipnet:87.255.32.0/19, country:NL] ------=_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 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 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.

 

Van: Karl Denninger <karl@denninger.net>
Datum:donderdag, 19 juni 2025 00:00
Aan:freebsd-net@freebsd.org
Onderwerp:dhcpcd(8) into FreeBSD base

Resurrecting an older thread....

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.)

On a first use dhcpcd gets both IPv4 and IPv6 ad= dresses, but 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 never fails on the second try.  I= f it fails on the first try doing a "arp -d" on the other end resol= ves nothing; only recycling the interface does.  Once it come= s up its 100% stable and never drops it.  Obviously w= ith no arp for the other end you get nothing (in either direction.)

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.

The more serious problem is with Ipv6.  If I shut = down my gear (and 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= t will come back up on IpV4 but never gets an answer to the SOLICIT respons= e.  It also never sees anything from the neighbor request!

In other words ("tcpdump -i ip6 ix0"):

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 14:42:30.573650 IP6 fe80::2e0:b4ff:fe68:f894 > ff02::2: ICMP6, router so= licitation, length 16
14:42:31.594474 IP6 fe80::2e0:b4ff:fe68:f894.dhcpv6-client > ff02::1:2.d= hcpv6-server: dhcp6 solicit
14:42:32.690063 IP6 fe80::2e0:b4ff:fe68:f894.dhcpv6-client > ff02::1:2.d= hcpv6-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 so= licitation, length 16
14:42:34.764176 IP6 fe80::2e0:b4ff:fe68:f894.dhcpv6-client > ff02::1:2.d= hcpv6-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:= ebff: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 so= licitation, length 16
14:42:38.732812 IP6 fe80::2e0:b4ff:fe68:f894.dhcpv6-client > ff02::1:2.d= hcpv6-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 so= licitation, 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.d= hcpv6-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

The interface is up and is passing Ip4 traffic.

And even more odd I get this once in a while:

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
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

The prefix IS part of the provider's delegation but I have no IPv6 addre= ss so I have absolutely no idea how they think routing tha= t to me is reasonable -- but they do.

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.  All behave exactly the same wa= y.

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 po= wer hit beyond my UPS's capacity, well, it'll happen again.

I see absolutely nothing in tcpdump that implies there's a problem, othe= r than that when this happens they never answer anything 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.

I'm trying to get their engineering people on the line to get a packet c= apture while I power cycle and see exactly why they're get= ting big-mad but my suspicion is that their ONT is in some= way obtaining and forwarding things before it negotiates fully -- which of= course it shouldn't, but..... 

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 perhaps = ;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 per se with negotiation, but someh= ow 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.

Putting this in freebsd-net rather than directly to Roy because I see th= e same behavior using the "stock" dhcp6c client......

On 6/7/2024 09:12, Roy Marples wrote:
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 woodsb02@freebsd.org> 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 :)
--
Karl Denninger
karl@= denninger.net
The Market Ticker
[S/MIME encrypted email preferred]
 

  ------=_Part_62812_84339164.1750321263682--