That's the way how DragonFlyBSD devs solved the problem
https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/451640b7cf6bcf7826b901ac9a51647442adb96b

Resigning from this; I tried to provide feedback over IRC, but that was seemingly not well-received (and questions unanswered) and I'm not interested in reviewing this as-is. I'd much prefer splitting it into two scripts, one with, e.g., verbs, that manages wireguard interfaces and then the rc script that simply drives that in an obvious way. The last objection I heard was that there's too much state to pass around, but it's not at all clear why unless this is trying to mix way too much rc.conf configuration in with wg config.

In D41318#980524, @pauamma_gundo.com wrote:

No manual page to review, yet manpages is a group reviewer. Did a file get accidentally left out?

No manual page to review, yet manpages is a group reviewer. Did a file get accidentally left out?

This is my first review here, I hope to not be stepping on any toes. If I have, please correct me so I might do better next time. Overall your wireguard startup mechanism looks good and my suggestions are strictly cosmetic in nature. I would not be at all disappointed if this patch were committed unaltered.

The interface name restriction function is a judgment call restricting users from creating problematic (for shell scripts) interface names. Applying the same restrictions to existing services like netif and routing could break (partly) working configurations.

Manual page English LGTM.

first pass…

In our repo this is two separate commits, one for adding the enum and a second for the -r option. Anyone who wants to commit this, I'd be happy to provide git format-patch format.

Restructured to use an enum for output formats rather than a bool, making it easier to change the defaults or add additional formats in the future. This was rebased onto 13.2 as a part of our migration; I haven't checked whether it still applies to 14-current.

I rewrote this to use an enum for the format type rather than a boolean, making it more flexible in the future. Will re-upload some day.

Minor nits, fixable on commit if nothing else requires another round.

Upated ipfw.8, fix some mandoc -T lint warnings.

This patch is no longer needed since I'm trying to use wpa_supplicant(8) on wtap(4). See D38508.

@glebius ?

Ref the wiki of ifnet project: https://wiki.freebsd.org/projects/ifnet

In D37070#841801, @bz wrote:

See also https://reviews.freebsd.org/D32847

See also https://reviews.freebsd.org/D32847

In D36691#839695, @kp wrote:

What problem does this fix? In other words, what is the motivation for this change?

No known problems.
When I was trying to resolve https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266712, I dug into the privileges design. I checked multiple tunnel interface implementations and found that if_me shares network privilege with if_gre. Intuitively this would confuse consumer. Fortunately there is no other consumers in base system.

Is there a use case for separating the GRE and ME privs? It's conceptually cleaner, but it could (theoretically at least, I doubt anyone actually does this) break existing configurations that rely on granting PRIV_NET_GRE to administer me interfaces.

There is no other consumers (of PRIV_NET_GRE) in base system, except for if_gre and if_me. I have not checked ports yet but it should be easy to fix ( in ports ).

What problem does this fix? In other words, what is the motivation for this change?

The IPv4/IPv6 over IPv6 vxlan looks good after test.

1. Rebase
2. Update as @bryanv suggested.

I would expect there are other avoidable slowdowns which prevent realizing the benefit.

In D36872#837076, @glebius wrote:

Is there any performance increase?

In D36872#837077, @zlei.huang_gmail.com wrote:

For 12.x, i386 is Tier 1 supported platform. The counter_u64_add() still has runtime branches.

There is a long trend in FreeBSD to make struct ifnet as less visible to drivers as possible. Ideally make it fully opaque. That will allow to change struct ifnet without breaking KBI of drivers. Some years ago I was really close, see https://svnweb.freebsd.org/base/projects/ifnet/. Actually today we have less drivers and this project is worth resurrecting, if I or somebody else have time for it.

For 12.x, i386 is Tier 1 supported platform. The counter_u64_add() still has runtime branches.

Is there any performance increase?

This looks sane to me. We really do have to make sure there's enough contiguous data before we access it.

Document the change in man pages.

In D34579#828698, @glebius wrote:

I can't see how this can be used maliciously, e.g. forcing some application outside of jail to send its SCM_RIGHTS to a jail.

In D32820#824395, @zlei.huang_gmail.com wrote:

Hi @melifaro ,
Any chance will this be MFCed into stable/13 ?

I can't see how this can be used maliciously, e.g. forcing some application outside of jail to send its SCM_RIGHTS to a jail. Even if such case exists for a certain application, that would be bug in that application, IMHO. The initial idea of SCM_RIGHTS was actually to grant rights intentionally, so there can be a valid case for a certain application that wants to grant rights to its peer in a jail.

Committed.
https://cgit.freebsd.org/src/commit/?h=vendor/dhcpcd&id=96dba636abec6d5451820add99300bda2ca6d86a

This looks good.

Hi @melifaro ,
Any chance will this be MFCed into stable/13 ?

In D36242#823477, @cy wrote:

Will there be a man page update for this at some point?

Will there be a man page update for this at some point?

I like this (and will commit it soon), but there's two epoch_drain_callbacks() in sys/net/if.c that should also be changed. I'll do that as part of the commit.