Date: Thu, 19 Jun 2025 09:29:20 +0800 From: Zhenlei Huang <zlei@FreeBSD.org> To: Karl Denninger <karl@denninger.net> Cc: FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: dhcpcd(8) into FreeBSD base Message-ID: <79909EDE-CFB2-45E9-8DC0-E042704908B4@FreeBSD.org> 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
--Apple-Mail=_F02483BA-33A6-40F5-97D8-D4335BFE780B
Content-Type: multipart/alternative;
boundary="Apple-Mail=_7E893E2C-C76B-41AF-9D20-3A8B69795A02"
--Apple-Mail=_7E893E2C-C76B-41AF-9D20-3A8B69795A02
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
> On Jun 19, 2025, at 6:00 AM, Karl Denninger <karl@denninger.net> =
wrote:
>=20
> Resurrecting an older thread....
>=20
>=20
Can you please point me to the thread ? I'd like to gather more context =
from that.
> 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.)
>=20
> 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.)
>=20
> 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.
>=20
> 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!
>=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 =
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
>=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 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
>=20
> 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.
>=20
>=20
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.
> 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.
>=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.
>=20
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, 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.
>=20
> 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.....
>=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 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.
>=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:
>> Hi Ed
>>=20
>> ---- On Thu, 06 Jun 2024 02:48:36 +0100 Ed Maste wrote ---
>> > On Sun, 7 Aug 2022 at 01:32, Ben Woods woodsb02@freebsd.org =
<mailto: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.
>> >
>> > 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
> --
> Karl Denninger
> karl@denninger.net <mailto:karl@denninger.net>
> The Market Ticker
> [S/MIME encrypted email preferred]
Best regards,
Zhenlei
--Apple-Mail=_7E893E2C-C76B-41AF-9D20-3A8B69795A02
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 19, 2025, at 6:00 AM, Karl Denninger <<a href="mailto:karl@denninger.net" class="">karl@denninger.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class=""><p class="">Resurrecting an older thread....</p><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div>Can you please point me to the thread ? I'd like to gather more context from that.</div><div> <br class=""><blockquote type="cite" class=""><div class=""><div class=""><p class="">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.)</p><p class="">On a <b class=""><u class="">first use</u></b> dhcpcd gets both IPv4 and IPv6
addresses, <i class="">but </i>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 <i class="">never </i>fails on the second try.
If it fails on the first try doing a "arp -d" on the other end <i class="">resolves
nothing; </i>only recycling the interface does. Once it comes
up its 100% stable and <i class="">never </i>drops it. Obviously with no
arp for the other end you get nothing (in either direction.)</p><p class="">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.</p><p class="">The <i class="">more serious </i>problem is with Ipv6. If I shut down my
gear (<b class=""><u class="">and</u></b> the company's ONT) and then turn the power
back on (say, because I need to work on the UPS in my rack!) <i class="">it
will come back up on IpV4 but never gets an answer to the
SOLICIT response. </i>It also never sees anything from the
neighbor request!</p><p class="">In other words ("tcpdump -i ip6 ix0"):</p><p class="">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<br class="">
14:42:30.573650 IP6 fe80::2e0:b4ff:fe68:f894 > ff02::2: ICMP6,
router solicitation, length 16<br class="">
14:42:31.594474 IP6 fe80::2e0:b4ff:fe68:f894.dhcpv6-client >
ff02::1:2.dhcpv6-server: dhcp6 solicit<br class="">
14:42:32.690063 IP6 fe80::2e0:b4ff:fe68:f894.dhcpv6-client >
ff02::1:2.dhcpv6-server: dhcp6 solicit<br class="">
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 class="">
14:42:34.574904 IP6 fe80::2e0:b4ff:fe68:f894 > ff02::2: ICMP6,
router solicitation, length 16<br class="">
14:42:34.764176 IP6 fe80::2e0:b4ff:fe68:f894.dhcpv6-client >
ff02::1:2.dhcpv6-server: dhcp6 solicit<br class="">
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 class="">
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 class="">
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 class="">
14:42:38.580627 IP6 fe80::2e0:b4ff:fe68:f894 > ff02::2: ICMP6,
router solicitation, length 16<br class="">
14:42:38.732812 IP6 fe80::2e0:b4ff:fe68:f894.dhcpv6-client >
ff02::1:2.dhcpv6-server: dhcp6 solicit<br class="">
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 class="">
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 class="">
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 class="">
14:42:42.595011 IP6 fe80::2e0:b4ff:fe68:f894 > ff02::2: ICMP6,
router solicitation, length 16<br class="">
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 class="">
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 class="">
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 class="">
14:42:47.109267 IP6 fe80::2e0:b4ff:fe68:f894.dhcpv6-client >
ff02::1:2.dhcpv6-server: dhcp6 solicit<br class="">
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 class="">
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 class="">
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 class=""><b class="">The interface is up and is passing Ip4 traffic.</b></p><p class="">And even <i class="">more odd </i>I get this once in a while:</p><p class="">14:45:26.688858 IP6
<a href="http://enviable.census.internet-measurement.com" class="">enviable.census.internet-measurement.com</a>.53565 >
2606:83c0:8600::10c.58222: Flags [S], seq 3619826346, win 14600,
options [mss 1440], length 0<br class="">
14:45:26.696834 IP6
<a href="http://stupendous.census.internet-measurement.com" class="">stupendous.census.internet-measurement.com</a>.53321 >
2606:83c0:8600::10c.rsf-1: Flags [S], seq 3940102705, win 14600,
options [mss 1440], length 0</p><p class="">The prefix IS part of the provider's delegation but I have no
IPv6 address so I have <i class="">absolutely no idea </i>how they think
routing that to me is reasonable -- but they do.</p><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>For unwanted IPv6 packets, the net stack should drop them silently, and fundamentally <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">you</span> can NOT prevent your provider from sending them. Also be aware that tcpdump(1) by default turns the interface into promisc mode. </div><blockquote type="cite" class=""><div class=""><div class=""><p class="">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. <i class="">All
behave exactly the same way.</i></p><p class="">If I call and bitch they reset <i class="">everything </i>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.</p><p class="">I see absolutely nothing in tcpdump that implies there's a
problem, other than that when this happens they never answer <i class="">anything </i>I
send them. They claim their dhcp6 server has locked out my MAC
due to "invalid" things they're seeing from me.</p></div></div></blockquote><div>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 <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">link-layer address ( occurs when renaming the interface ) </span>. So I'm curious what "invalid" things your provider sees.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><p class=""> 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.</p><p class="">I'm trying to get their engineering people on the line to get a
packet capture while I power cycle and see <i class="">exactly </i>why
they're getting big-mad but my <i class="">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 class="">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 <i class="">perhaps </i>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 <i class="">per
se </i>with negotiation, but somehow their end is getting "big
mad" with me when it comes to IPv6 delegations and once it does <i class="">it
never clears it on its own.</i></p><p class="">Putting this in freebsd-net rather than directly to Roy because I
see the <i class="">same </i>behavior using the "stock" dhcp6c client......</p>
<div class="moz-cite-prefix">On 6/7/2024 09:12, Roy Marples wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:18ff2d4772a.129dde187836962.5411001908566459400@marples.name" class="">
<pre wrap="" class="moz-quote-pre">Hi Ed
---- On Thu, 06 Jun 2024 02:48:36 +0100 Ed Maste wrote ---
> On Sun, 7 Aug 2022 at 01:32, Ben Woods <a class="moz-txt-link-abbreviated" href="mailto:woodsb02@freebsd.org">woodsb02@freebsd.org</a>> 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 :)
</pre>
</blockquote>
<div class="moz-signature">-- <br class="">
Karl Denninger<br class="">
<a href="mailto:karl@denninger.net" class="moz-txt-link-freetext">karl@denninger.net</a><br class="">
<i class="">The Market Ticker</i><br class="">
<font size="-2" class=""><i class="">[S/MIME encrypted email preferred]</i></font></div>
</div>
</div></blockquote></div><br class=""><div class="">
<div>Best regards,</div><div>Zhenlei</div>
</div>
<br class=""></body></html>
--Apple-Mail=_7E893E2C-C76B-41AF-9D20-3A8B69795A02--
--Apple-Mail=_F02483BA-33A6-40F5-97D8-D4335BFE780B
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
iNUEARYKAH0WIQRj28YmNowGX1isJg7GJJ6Jgbd0XwUCaFNn8F8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0NjNE
QkM2MjYzNjhDMDY1RjU4QUMyNjBFQzYyNDlFODk4MUI3NzQ1RgAKCRDGJJ6Jgbd0
X7exAQCvVJ4p9Nizeuylb8lqPaGRSGVKNEeOUq2y26fluy16IwEAw/TImjfwMdij
M9HV8Uq6dAnf/SFrVGT/HQWEPj1n4wU=
=15Rt
-----END PGP SIGNATURE-----
--Apple-Mail=_F02483BA-33A6-40F5-97D8-D4335BFE780B--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?79909EDE-CFB2-45E9-8DC0-E042704908B4>