phylosophically this interface more like L2 loopback, right?
can be emulated by ng_ether somehow?

vt has serious flow if compare with sc: it is not possible to switch it to any mode except 80x25 in some virtual environments

As this review was closed, I've submitted the fixed version as 288599

In D51265#1177633, @diizzy wrote:

In D51265#1177629, @kevans wrote:

In D51265#1177628, @vova_fbsd.ru wrote:

In D51265#1177623, @kevans wrote:

(for what it's worth, "amneziavpn-" would seem like a fine name that ties back into the website better anyways)

Amnezia-VPN project provides support for multiple VPN protocols, and only one of them is amneziawg, the port support only that protocol, and does not support others.
In case of "amneziavpn" - such name will misslead users.

You can check, for example how they name relative repos in their github -
about amneziawg:

https://github.com/amnezia-vpn/amneziawg-tools
https://github.com/amnezia-vpn/amneziawg-linux-kernel-module

Can you please answer on my question about motivation to not name it "amneziawg"?

Because you were asked not to, and that's clearly a pretty thin line to be dancing around..

In D51265#1177623, @kevans wrote:

(for what it's worth, "amneziavpn-" would seem like a fine name that ties back into the website better anyways)

In D51265#1177614, @kevans wrote:

Drop the 'wg' from the name and any description/advertising materials. That's just another spelling for 'WireGuard'.

Obviously nothing stops them from using if_wg as the basis and that's
all fine, but the upstream WireGuard project has already expressed their
concern and have been completely ignored. Just re-brand the damn thing
as Amnezia and an Amnezia tunnel, fix the docs to avoid calling it
WireGuard. We'll get it into review and commit it, then then let's
perhaps chat on the list (as already requested) about how we could
integrate other ideas that can improve WireGuard as a whole.

use awg0/awg1 in rc.conf example

v1.0.6 of upstream driver, only cosmetic changes

• remove not used any more rc.d file

In D51265#1175412, @jason_zx2c4.com wrote:

Do you think it’s a bad idea to extend the existing WireGuard driver with Netgraph hooks or custom UDP stream processing? (Similar to how mpd handles PPP streams in flexible ways.) — just a side question. Would that be a question better suited for the mailing list?

That sounds pretty intriguing to me. I'd be interested to learn how this would work on Linux too, and maybe even user space implementations, and what a generic library api for accessing this would be like. What sorts of events would bubble up? And would this be better suited as an in-kernel eBPF hook? I am definitely interested in kernel hooks for efficiently plugging in different obfuscators or encapsulators. If you've got a big idea about this, indeed the mailing list would probably be a good venue, especially if you CC in Kyle & folks from here whose feedback are really valuable.

Sad to hear that ...

net/amneziawg-kmod and net/amneziawg-tools

Can you elaborate on this a little bit? You don't seem to have really changed the ioctl interface in a way that isn't compatible with if_wg (we would just ignore the new nvlist elements you've added), and requests get routed to the correct ioctl handler based on the interface named in the request passed to ioctl(2).

In D51265#1171381, @diizzy wrote:

Any attempts of upstreaming?

I'm uncomfortable with you calling this "wireguard" in any way shape or form.

• bump wireguard-amnezia-kmod-v1.0.4

Can you elaborate on this a little bit? You don't seem to have really changed the ioctl interface in a way that isn't compatible with if_wg (we would just ignore the new nvlist elements you've added) and requests get routed to the correct ioctl handler based on the interface named in the request passed to ioctl(2).

well, then kmod as port - https://reviews.freebsd.org/D51265

probably become rapidly obsolete as soon as it’s deployed and profiled

• better compatibility with original if_wg code (accomodate recent changes)

Thank you for explanation ... now I better understand the "boundaries" of the problem -

thanks a lot for explaining,

if an tagged incoming frame does not patch the port's pvid, it will be dropped.

should be read as "if an tagged incoming frame does not match the port's pvid, it will be dropped.", right?

Come on