Avoid returning badkey error for EDDSA.

@ziaee
Thank you for reviewing the 53786 . I wanted to politely ping you on this revision, when you have a chance.

@glebius can I commit this revision?

LGTM
I also tested interface creation and destruction to advertise/withdraw its routes with bird3 (ospf) and openbgpd8.

LGTM.
I also tested with the CSUM_IP patch applied to if_epair.c:447 and saw good results.

Address @ziaee comments

I will test it with openbgp and bird.
I suspect that removing routes before detaching the actual interface might cause unexpected behavior in them.

Address @bz comment for manual.

Address @bz comments

In D54636#1250365, @ivy wrote:

the only purpose that RFC8781 mentions for having multiple PREF64s advertised is renumbering, in which case the lifetime of the deprecated prefixes should be set to zero. iiuc, this diff allows that by setting pref64lifetime0, pref64lifetime1, etc. - can i check i have that right?

P.S. Love the KAME project, but honestly, most of their userland code is weird.
For instance, I also have a branch for mobile ipv6 implementation, where I made a fair amount of changes to rtadvd, rtsold, rtadvctl, and others.
I have to say the layer of indirection in KAME code makes adding a single floating point number almost impossible without refactor.
I don't like their style of coding in userland either. However, To see if I should use our own style or simply follow existing, I checked the other revisions for these toolset found other developers simply didn't touch KAME style.

rebase to latest commit and cleanup unused var

Here is the output sample of rtadvctl:

% mdo rtadvctl -v show
bridge0: flags=<UP,TRANSITIVE,PERSIST> status=<RA_SEND> mtu 1500
DefaultLifetime: 10m
MinAdvInterval/MaxAdvInterval: 3m20s/10m
AdvLinkMTU: <none>, Flags: MO, Preference: low
ReachableTime: 0s, RetransTimer: 0s, CurHopLimit: 64
AdvIfPrefixes: yes
Next RA send: Thu Jan 15 00:58:25 2026
Last RA send: Thu Jan 15 00:58:06 2026
Prefixes (1):
2a01:e140:1234:5678::/64 (CONFIG, vltime=30d, pltime=7d, flags=LA)
DNSSL entries:
spmzt.net (ltime=15m)
PREF64:
2a01:e140:cafe:ff::/96 (ltime: 3m45s)
2a01:e140:dead:ff::/64 (ltime: 3m45s)

Change revision to add support for multiple PREF64 options.

leave trailing space on authors.adoc and add freebsd email uid to my pgp key for signing emails.

committers-src: Add myself (pouria@) with glebius@ as mentor

Convert action_show_pref64 from int to void and use assertion to address @zlei comment.

LGTM
also tested:

# kyua test -k /usr/tests/sys/netinet6/Kyuafile ndp
ndp:ndp_add_gu_success  ->  passed  [2.012s]
ndp:ndp_del_gu_success  ->  passed  [3.407s]
ndp:ndp_prefix_len_mismatch  ->  passed  [2.128s]
ndp:ndp_prefix_lifetime  ->  passed  [15.506s]
ndp:ndp_prefix_lifetime_extend  ->  passed  [0.078s]
ndp:ndp_slaac_default_route  ->  passed  [5.364s]

LGTM
tested:

IMHO, this case should not happen at all. Therefore, if there is a possible scenario, it maybe more appropriate to use KASSERT instead.

In D54561#1246664, @markj wrote:

The function is used in multiple compilation units, so to make it inline the definition would have to be in a header, probably nd6.h since that's where ND6_INFINITE_LIFETIME is defined.

You're right! it's definitely overkill. Thank you!

LGTM. Why don't you inline it? I know that the compiler will do ultimately what it wants. but at least we can suggest the right thing to it.

Why don't we allow new committers to use curve algorithms?
I can see that there are multiple ed25519 keys currently in use by committers, as reported by ./doc/documentation/tools/pgpkeyreport.
However, committer's guide states that checkkey.sh must be used to ensure the key is valid.
The checkkey.sh script does not allow committers to use curve algorithms. Is this ok or should we write an exception for curve algorithms?

Fix ability to modifying generic and link-specific attributes at the same time in geneve_clone_modify_nl

LGTM

I wasn't sure whether this change was necessary or whether my approach was correct. I thought this was a known issue that someone would address eventually, and no one had enough time to do it. If that's not the case, I'll close this revision.
@bz Thank you for your feedback. @zlei If a bug appears in the future and the team decides it should be fixed, I can help.

Thank you for your review. Done.

Done suffix of what I have done bullet points was redundant.

Rebase and update according to 0bd0c3295ac09f759f2816b73cbd2d950e3bef7e .

LGTM

In D54109#1238798, @melifaro wrote:

To fix this one specifically I'd probably try to set curtread creds during the thread setup: https://github.com/freebsd/freebsd-src/blob/80726c2257e9d6d79341aac65ba22987f53619bc/sys/netlink/netlink_io.c#L149

• Replace IFF_DRV_RUNNING with GENEVE_FLAG_RUNNING, address @glebius note

In D54109#1238115, @glebius wrote:

The patch as is definitely brings correct behavior. But, IMHO, we should try to propagate the cred change as deeper in the call stack as possible. It seems trivial while we are withing netlink, as nlp carries correct cred. But once we go from netlink to if_clone.c, we lose it. Let's hear from @melifaro

In D54175#1237698, @glebius wrote:

In D54175#1237696, @markj wrote:

That's what I thought, but other software ifnet implementations I looked at (gif, wg, bridge, epair) all seem to behave like this.

IMHO, it is a continuous copy-and-paste from one driver to the other and this chain needs to broken, rather than continued.

• if_clone change is separated into D54190
• all the INET and INET6 macros are removed.
• remove vnet members from sc and gnvso due to fix on D54109
• replace int mcast with bool mcast

Ok, I will try to fix it using VNET_SYSUNINIT().

Fix lint warning on if_geneve.sh test and remove changes to netlink_route.py to avoid error that are not mine

Resolve PEP8 test warnings for netlink_route.py

without this patch:

# kyua test -k /usr/tests/sys/net/Kyuafile if_geneve
if_geneve:ether_ipv4  ->  Dec  8 15:53:29 ftsr1 kernel: geneve1: DAD detected duplicate IPv6 address fe80:d::5a9c:fcff:fe10:3953: NS in/out/loopback=1/1/0, NA in=0
Dec  8 15:53:29 ftsr1 kernel: geneve1: DAD complete for fe80:d::5a9c:fcff:fe10:3953 - duplicate found
Dec  8 15:53:29 ftsr1 kernel: geneve1: manual intervention required
Dec  8 15:53:29 ftsr1 kernel: geneve1: possible hardware address duplication detected, disable IPv6
failed: atf-check failed; see the output of the test for details  [1.162s]
if_geneve:ether_ipv6  ->  Dec  8 15:53:32 ftsr1 kernel: geneve1: DAD detected duplicate IPv6 address fe80:d::5a9c:fcff:fe10:3953: NS in/out/loopback=1/1/0, NA in=0
Dec  8 15:53:32 ftsr1 kernel: geneve1: DAD complete for fe80:d::5a9c:fcff:fe10:3953 - duplicate found
Dec  8 15:53:32 ftsr1 kernel: geneve1: manual intervention required
Dec  8 15:53:32 ftsr1 kernel: geneve1: possible hardware address duplication detected, disable IPv6
failed: atf-check failed; see the output of the test for details  [1.172s]
if_geneve:inherit_ipv4  ->  passed  [0.129s]
if_geneve:inherit_ipv6  ->  passed  [0.166s]

This is tested and works. However, I'm not sure if it's clean or need a lock due to changing references in a async thread

The problem with netlink_socket not having the correct prison credential is that it’s run as an async/taskqueue function in a separate thread, therefore it doesn't have the same credentials as the caller thread. When we call the ioctl it runs as a synchronous thread and therefore doesn’t change its thread and its credentials. However, when we call netlink it runs in a separate thread named netlink_socket.

After writing some tests with kyua I found a problem to my code.
CURVNET_SET sets the curthread->td_vnet. However, ether_gen_addr use curthread->td_ucred->cr_prison->pr_vnet which is different.
It seems like nl_taskqueue_handler already sets curthread->td_vnet.
In summary, TD_TO_VNET value is not same as curvnet, and ether_gen_addr use curthread->td_ucred.
I wonder how can I change the td_ucred to the actual one.
Maybe I should use OSD(9)... I have to figure things out.

In D54109#1236248, @glebius wrote:

Looks correct! Thanks. What did happen before? This command failed?

ifconfig -j nlvnet1 vlan0 create inet6 2001:db8::2 vlandev epair0b vlan 10

No, However, it is the only interface that uses the if_clone_addreq_v2. So it's the only test that I can do to make sure existing implementation doesn't break.

During clone creation of my new Geneve interface module, I found that when I use ether_gen_addr it generates the same MAC address for interfaces with the same name in different jails.
However, it worked correctly when I'm not using create_nl (netlink). I found that netlink does not set the curvnet the way ioctl does.

Rebase to main. @tuexen Done. From now on, I'll always create commits from the base. Thank you.

@tuexen done.

In D53786#1228565, @pauamma_gundo.com wrote:

Perhaps, to make it even easier in this case, you could add a mention of what snl(3) is good for, for example in the first paragraph of section "PROTOCOL DESCRIPTION". Something like:

In addition, wrapper library
.Xr snl 3
can make parsing or assembling messages easier.

What do you think?