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 
FreeBSD config, worked fine on both Cox and Spectrum without changes.)

On a *_first use_* dhcpcd gets both IPv4 and IPv6 addresses, /but 
/sometimes the IPv4 side fails to be able to ARP (!!!!) the other end.  
If I drop the interface (ifconfig ix0 down; ifconfig ix0 up) it /never 
/fails on the second try. If it fails on the first try doing a "arp -d" 
on the other end /resolves nothing; /only recycling the interface does.  
Once it comes up its 100% stable and /never /drops it.  Obviously with 
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 
connection 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 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 answer to the SOLICIT response. /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: 
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 
solicitation, length 16
14:42:31.594474 IP6 fe80::2e0:b4ff:fe68:f894.dhcpv6-client > 
ff02::1:2.dhcpv6-server: dhcp6 solicit
14:42:32.690063 IP6 fe80::2e0:b4ff:fe68:f894.dhcpv6-client > 
ff02::1:2.dhcpv6-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 
solicitation, length 16
14:42:34.764176 IP6 fe80::2e0:b4ff:fe68:f894.dhcpv6-client > 
ff02::1:2.dhcpv6-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 
solicitation, length 16
14:42:38.732812 IP6 fe80::2e0:b4ff:fe68:f894.dhcpv6-client > 
ff02::1:2.dhcpv6-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 
solicitation, 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.dhcpv6-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 
[mss 1440], length 0
14:45:26.696834 IP6 stupendous.census.internet-measurement.com.53321 > 
2606:83c0:8600::10c.rsf-1: Flags [S], seq 3940102705, win 14600, options 
[mss 1440], length 0

The prefix IS part of the provider's delegation but I have no IPv6 
address so I have /absolutely no idea /how they think routing that to me 
is reasonable -- but they do.

They're pointing at "my gear" as I'm not using their router.  Uh, yeah, 
ok.  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./

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.

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 because (1) there's no route until IPv6 comes up 
except for 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 implausible any inside device with a "stale" IPv6 address 
is sending, and everything 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 obviously didn't have any.

I'm trying to get their engineering people on the line to get a packet 
capture while I power cycle and see /exactly /why they're getting 
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 obviously a 
power loss while I'm not around is going to be a pain in the neck.  One 
thing 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 /with 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./

Putting this in freebsd-net rather than directly to Roy because I see 
the /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 ---
>   > On Sun, 7 Aug 2022 at 01:32, Ben Woodswoodsb02@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.
>   >
>   > 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]/