Re: dhcpcd(8) into FreeBSD base

On 6/18/2025 21:29, Zhenlei Huang wrote:
>
>> On Jun 19, 2025, at 6:00 AM, Karl Denninger <karl@denninger.net> wrote:
>>
>> Resurrecting an older thread....
>>
>
> Can you please point me to the thread ? I'd like to gather more 
> context from that.
It was under this title; should be in the archives from June of last year.
>>
>> 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 
>> <http://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 
>> <http://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.
>>
>
> For unwanted IPv6 packets, the net stack should drop them silently, 
> and fundamentally you can NOT prevent your provider from sending them. 
>  Also be aware that tcpdump(1) by default turns the interface into 
> promisc mode.

I understand that, but their infrastructure should not be sending them.  
It is.  But its only a few packets here and there, which implies 
rather-strongly it was aimed at the former (valid) address I had and not 
something else in their infrastructure -- I think. The prefix is correct 
(at least) but I don't know what my end actually got for the final 
octets since it was before I turned the power off.

They hand out a /56 for IPv6.

>> 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.
>>
> Do ( can ) they provide the details of the "invalid" things ? I'm 
> recently overhauling the attaching process of interfaces. For ethernet 
> interfaces, there're rare races that the driver see un-initialized 
> link-layer address ( 00:00:00:00:00:00 ) or incomplete link-layer 
> address ( occurs when renaming the interface ) . So I'm curious what 
> "invalid" things your provider sees.
>
Well not so sure on that.  I've asked, and will continue to, but they 
haven't said exactly *_what_* got their end big-mad.  But whatever it is 
they're getting it makes their IPv6 DHCP server angry enough that it 
locks my connection out once they see it.  To clear it they clear the 
provisioning which resets BOTH IPv4 and V6 assignments so whatever 
they're clearing it looks to me like they're resetting all their 
provisioning for my service, including (probably) the ONT configuration 
that they send down to their box here.

I have a theory however which might be involved after going back through 
the last time --  I had not shut off ipv4ll; if the interface comes up, 
their DHCP server is slow, my end sends a request and gets no immediate 
reply dhcpcd will try to configure a link-local address on that 
interface /and then attempt to ARP the address across that interface to 
confirm its not in use./ If they see *_that_*, which is of course 
non-routeable and their system says "oh no you don't!" and instead of 
just throwing it out they lock out that source as attempted game-playing 
well.... that could certainly be it.  Then the solicitation never gets 
anywhere because the blackball is on the ONT's address as the "rogue" 
source (its a FTTH setup with optical splitters and an ONT at my 
premises that feeds a standard gigabit ethernet out the back of it to my 
gear.)

I've turned that option off (and set noarp) and will see if it happens 
again but since they're playing a bit coy with me I am loathe to just 
yank the cord out of their ONT and reset it without knowing that this 
MIGHT be involved lest I find myself with no IPv6 again (and have to go 
through their call center and such.) Of course that will eventually 
happen because eventually I've have to take things down or there will be 
an extended power outage that exceeds what my UPS can hold things up for 
(or a fiber cut, or problem on their end that causes a reset on the 
connection, etc.)

I used to be on cable service and had no problems with this; the cable 
companies (two of them over the years with various hardware but this 
same basic software load, although its been updated several times over 
the years as FreeBSD has advanced) were either fast enough that it never 
tried for link-local or didn't care -- and the default of dhcpcd IS to 
try to use it temporarily at least if the DHCP server doesn't reply 
right away.

>
> Best regards,
> Zhenlei
>
-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/