Please skip the change for security/ipsec-tools as was already applied and then reverted: the change breaks upgrade path from previous version like 9.x or 10.x or 11.0 because they do no have ipsec.ko as a module.

I agree that snprintf() should be avoided here, as well as stack abuse. Please consider using asprintf() that allocated memory on heap all by itself dealing with space requirements automatically, just free the pointer just after posix_spawnp().

In D26447#664154, @gnn wrote:

Now that this review has devolved to the point of discussing democracy, rather than the deprecation of a piece of long surviving, but, inherently insecure code in our base system, it's time for people to step back from their keyboards and realize that removing this from base does not make it impossible to install or use, it simply reduces the default attack surface of our system. So, let's let emaste put this deprecation in for 14, and move on.

Please keep ftp and telnet clients and servers in base system. Removing violates POLA and does not buy anything. Servers already disables by default.

Sorry for the mess, my latest actions on this differential were unintentional, some problems with old Firefox.

CCing Roman Kurakin (ce(4)) and Serge Vakulenko (cp(4)), see later.

I'm going to commit this soon unless an objection is raised.

My goal is to improve performance by default not requiring any user actions while not breaking things same time. Both GNU binutils version of strip(1) and our version from contrib/elftoolchain/elfcopy support -o, so there would be no slowdown but improvement for all supported branches. However, install(1) could be used in some strange environment for cases other than "installworld" and I don't want it to break there making regression.

Thanks, I've fixed this.

Use: strip -o to_name -- from_name

Thanks!

Correct wording in the manual page.

I'm going to commit this soon unless an objection is raised.

In D25029#552845, @lutz_donnerhacke.de wrote:

If I understand correctly

ifconfig -a -g lagg -G lagg*1

will match all lagg interfaces besides those ending in 1.

But

ifconfig -a -g lagg -g vlan

will match vlan interfaces only.

Correct?

Add explicit note to the manual page that additional options -g override previous ones, same for -G.

Fix case when none of -g nor -G is specified that was broken with addition of second option.

Do not use prefix to negate condition. Instead, use new flag -G and allow user to specify both -g and -G same time.

In D25029#552131, @lutz_donnerhacke.de wrote:

"^" does look like an regex starting point and will cause confusion: "Why is '-g la.*2[345]' not working?"

In D25029#551705, @ae wrote:

You can just use another option name to specify excludes.

Compactify code a bit.

Fix misprint that somehow passed testing.

Kernel side asprintf() uses M_NOWAIT internally and may return -1 on memory allocation failure. It would need a check.

Please consider to decrease abuse of kernel stack. We already had problems with kernel-land double faults due to kernel thread stack overflows. Could you please aggregate these big but fixed-sized arrays to single struct and allocate it using one malloc() call at heap instead?

In D24416#537135, @kp wrote:

I can't create epair0 again even though it no longer exists in the host vnet.

In D24416#537151, @wollman wrote:

I haven't been paying attention to this, but IME the problem with epair (and also bridge) interfaces was always that the generator would come up with the same MAC address on different *machines*. We simply gave up and manually assigned LAA MAC addresses to all such interfaces.

You still miss the point. Please read PR 229957 there all epairs are created within host, so they have same UUID. But after epair is created and MAC generated, epair get moved to another VNET, so next one may be created within host with same properties and get same MAC address.

Sadly, ether_gen_addr() cannot be used for epair safely. Your change removes parts of code that was brought in for a reason. This change would re-introduce problems fixed by code removed. Please read PRs 184149 and 229957 for details.

Also, trim(8) calls candelete() for cosmetic reasons only and in verbose mode only (by default).
"trim -q" does not call candelete() and always reveals real error of system call.

This seems to be driver-dependent as it works as expected for md:

I'm not sure I understand the problem.

In D23577#519163, @aleksandr.fedorov_itglobal.com wrote:

divert sockets can be used with other software but present exactly same significant overhead.
Do you have an example when suggested change improves performance really?

I agree with you that divert sockets have a known overhead. And I don't have a suitable example, because I don't use them anywhere. On the other hand, I see no reason why the initial socket buffer size should be hardcoded. My experience with other types of sockets indicates that large buffers can increase throughput. For example, netgraph sockets.

So, if some people want to use divert sockets, why not add the ability to resize the buffer socket?

In D23577#520228, @lutz_donnerhacke.de wrote:

In D23577#520226, @eugen_grosbein.net wrote:

In D23577#519182, @lutz_donnerhacke.de wrote:

Can you please explain, what the issue is with the sysctl itself?

Sysctls are great tools and very handy, so our sysctl tree grows quick and already bloated and needs increasing amounts of memory. I don't think we should add new one just because it's easy and we can do it, without any practical use case.

So how implementing an (existing) socketopt to modify the desired behavior from the application side?

In D23577#519182, @lutz_donnerhacke.de wrote:

Can you please explain, what the issue is with the sysctl itself?

In D23577#519163, @aleksandr.fedorov_itglobal.com wrote:

divert sockets can be used with other software but present exactly same significant overhead.
Do you have an example when suggested change improves performance really?

I agree with you that divert sockets have a known overhead. And I don't have a suitable example, because I don't use them anywhere. On the other hand, I see no reason why the initial socket buffer size should be hardcoded. My experience with other types of sockets indicates that large buffers can increase throughput. For example, netgraph sockets.

So, if some people want to use divert sockets, why not add the ability to resize the buffer socket?

In D23577#518798, @aleksandr.fedorov_itglobal.com wrote:

divert(4) sockets can be used not only with natd(8), so the changes looks reasonable for me.

In D23577#518767, @neel_neelc.org wrote:

In D23577#518755, @eugen_grosbein.net wrote:

Please describe use case for this change. Also, defauls are not 65536 but (65536 + 100).

This can be used to reduce divert memory consumption on "small" devices (e.g. low power routers) or increase divert performance on "big" devices (e.g. middleboxes, IDS).

I updated the description.

Please describe use case for this change. Also, defauls are not 65536 but (65536 + 100).

In D23091#518544, @lutz_donnerhacke.de wrote:

@eugen_grosbein.net are your concerns handled?

We already have "nat tablearg" feature for this task:

In D23450#515674, @pi wrote:

What happens, if some port mapping is defined unexpected source IPs are sent from behind the CGN ? Will this packet/port end up 'somewhere' in the reserved range or will it map somewhere outside of all reserved ranges ?

In D23450#515673, @pi wrote:

The use case is a static mapping from behind-nat users to the outside world. If such a static mapping is possible, CGN-operators do not need to log every transaction.

Please describe why do you need to limit aliasing port rangle for NAT instance and what is wrong with current unlimited and mixed usage of ports for NAT instances?

In D23091#507459, @lutz_donnerhacke.de wrote:

In D23091#507447, @lutz_donnerhacke.de wrote:

Add an explanation to the man page.

Could you please supply use case? Why do we need another virtual ethernet interface? We already have many kinds of them.

In D21724#477488, @kaktus wrote:

Wouldn't /usr/libexec be a better place for it, like for many other such daemons (like fingerd etc…)?