Re: git: 31ec8b6407fd - main - sys/netinet6: Implement RFC 7217

On 9/21/25 13:49, Herbert J. Skuhra wrote:
> On Sun, 21 Sep 2025 12:44:42 +0200, Guido Falsi  wrote:
>>
>> On 9/21/25 11:58, Guido Falsi wrote:
>>> On 9/21/25 00:17, Herbert J. Skuhra wrote:
>>>> On Sat, 20 Sep 2025 14:31:52 +0200, Guido Falsi wrote:
>>>>>
>>>>> The branch main has been updated by madpilot:
>>>>>
>>>>> URL: https://cgit.FreeBSD.org/src/commit/?
>>>>> id=31ec8b6407fdd5a87d70265762457c67ce618283
>>>>>
>>>>> commit 31ec8b6407fdd5a87d70265762457c67ce618283
>>>>> Author:     Guido Falsi <madpilot@FreeBSD.org>
>>>>> AuthorDate: 2025-09-20 12:26:41 +0000
>>>>> Commit:     Guido Falsi <madpilot@FreeBSD.org>
>>>>> CommitDate: 2025-09-20 12:31:44 +0000
>>>>>
>>>>>       sys/netinet6: Implement RFC 7217
>>>>>       Implement RFC 7217 (A Method for Generating Semantically Opaque
>>>>>       Interface Identifiers with IPv6 Stateless Address Autoconfiguration
>>>>>       (SLAAC)) in our IPv6 stack.
>>>>>       A new ifconfig `stableaddr` flag is added to enable the feature on
>>>>>       interfaces, which defaults to on or off for new interfaces based
>>>>>       on the sysctl `net.inet6.ip6.use_stableaddr` (off by default, so
>>>>>       this commit causes no change in behavior with default settings).
>>>>>       The algorithm follows the RFC in its logic, using SHA256-HMAC as
>>>>>       the algorithm to derive addresses so as to provide code that can
>>>>>       be leveraged by future implentations of RFC 8981, leveraging the
>>>>>       `hostuuid` as the secret.
>>>>>       The source of the hostidentifier can be configured using the sysctl
>>>>>       `net.inet6.ip6.stableaddr_netifsource`, while the number of retries
>>>>>       generating a new address in case of collision can be configured
>>>>>       using the `net.inet6.ip6.stableaddr_maxretries` sysctl (default 3).
>>>>>       Documentation about all these flags is added to the ifconfig(8) man
>>>>>       page.
>>>>>       Reviewed by:            cognet, glebius, hrs
>>>>>       Tested by:              zarychtam@plan-b.pwste.edu.pl
>>>>>       Approved by:            cognet, glebius
>>>>>       Relnotes:               yes
>>>>>       Differential Revision:  https://reviews.freebsd.org/D49681
>>>>> ---
>>>>>    sbin/ifconfig/af_inet6.c    |   2 +
>>>>>    sbin/ifconfig/af_nd6.c      |   1 +
>>>>>    sbin/ifconfig/ifconfig.8    |  30 +++++
>>>>>    sys/netinet6/in6.h          |   3 +
>>>>>    sys/netinet6/in6_ifattach.c | 275
>>>>> +++++++++++++++++++++++++++++++++ ++++-------
>>>>>    sys/netinet6/in6_ifattach.h |   2 +
>>>>>    sys/netinet6/in6_proto.c    |  10 ++
>>>>>    sys/netinet6/ip6_input.c    |   1 +
>>>>>    sys/netinet6/ip6_var.h      |  12 ++
>>>>>    sys/netinet6/nd6.c          |   9 ++
>>>>>    sys/netinet6/nd6.h          |   2 +
>>>>>    sys/netinet6/nd6_nbr.c      |  35 +++++-
>>>>>    sys/netinet6/nd6_rtr.c      | 128 +++++++++++++--------
>>>>>    usr.sbin/ndp/ndp.c          |   7 ++
>>>>>    14 files changed, 423 insertions(+), 94 deletions(-)
>>>>
>>>> This commit breaks security/netbird:
>>>>
>>>> Management: Disconnected, reason: create wg interface: error
>>>> creating tun device: unable to get nd6 flags for tun0: invalid
>>>> argument
>>>> Signal: Disconnected, reason: create wg interface: error creating
>>>> tun device: unable to get nd6 flags for tun0: invalid argument
>>>>
>>>
>>> Thanks for reporting this,
>>>
>>> I'm going to take a look shortly, although I'm not sure why, since
>>> the functionality is disabled by default.
>>>
>>>
>>
>> Hi again,
>>
>> I'm going to try to reproduce this, but in the while, looking at the
>> source code, the error comes from the wireguard-go package that is
>> being used by netbird (we also have that in a port of its own BTW).
>>
>> The code there is manipulating the interface flags at a low level, but
>> my commit modified that structure. There is some chance that simply
>> forcing a rebuild and reinstall of the package will "fix" it.
>>
>> Have you tried that?
>>
>> If you already have, I'll go on and reproduce locally, if I can.
> 
> Yes, I've already rebuilt both go124 and netbird. Sorry I didn't
> mention this before.
> 

Yes, I now see recompiling would not have helped in this case.

A C program would have included the system include and noticed the 
change, but this software has hardcoded the struct in go code and 
requires patching.

I'm attaching a simple patch for the ports tree for this port, it 
compiles but I've not tested it at runtime, could you try applying this 
patch to the ports tree and recompile the port, and report back?

Please note this is not a proper patch for the ports tree, it just fixes 
the problem, but would break it for anyone else, I'll produce a proper 
patch for the ports tree once I have confirmed the approach woks.

Thanks in advance!

-- 
Guido Falsi <madpilot@FreeBSD.org>