Is there really a typical use case for this call?

What about src-ipv4? (for the sake of symmetry)
Somebody may think about "*ip" to accept both address families.

Patch does work with 12-STABLE, too. (removing the NEEDGIANT flag)

Fixed spacing for "if (" statements.
Running the whole source through indent(1) would make a much larger patch.

That would be my approach https://reviews.freebsd.org/differential/diff/69565/
I'd further eliminate the temporary storage "struct sockaddr_storage result", and copy directly from the gai result into the action (with memcpy).

I tried to use the already existing socket infrastructure to change the socket buffer values ...

In D24021#528343, @driesm.michiels_gmail.com wrote:

Does this mean that for a current dual stack IPFW rule like:

allow tcp from any to me 443

It will only match for IPv4 packets, as "me" is only working with IPv4 addresses under the hood with the current behavior?
This is not the current behavior I'm observing since my web server answers IPv6 requests perfectly fine with my above rule.

Good catch.

In D23971#528126, @rgrimes wrote:

I have no idea why someone thinks a network device should have a minimum MTU of 1280, that is simply the IPv6 value, ethernet is very happy to transfer 64 byte packets. There should be some implementation detail of the in kernel vt driver that can at least go that small, and perhaps smaller as you do not have the collision detection minimum wire time that ethernet has(had).

In D24011#527998, @lutz_donnerhacke.de wrote:

How about detecting the port separator first? (i.e. repeatly call strpbrk)

How about detecting the port separator first? (i.e. repeatly call strpbrk)
Then you can easily distinguish between the cases

• starts with '[' -> numeric IPb6
• contains ':' -> numeric IPv6
• contains no letters -> numeric IPv4
• use gai()

Ping?

Ping?

Ping?

@melifaro Are your concerns resolved?

@hrs Are your concerns resolved?

@brueffer Are your concerns resolved?

Widen the range of priority classes.

I'm sorry, but I do not see anything functionally connected with the new fib number.
This patch only stores and retrieves the number but does not consider it in its natting process itself.
So the whole fib processing is done in the ipfw ruleset, it has nothing to do with libalias.
What do I miss?

In D23963#526951, @aleksandr.fedorov_itglobal.com wrote:

Is it really useful to have multiple uplinks?

Updated to revision 358668.

The man page needs an update, too.

In D23721#526022, @glebius wrote:

This can make sense in certain setups. However, since originally node provided writable copies to each of "many" hooks, we can't change that. This can be configured as a node option, if sysadmin is sure that nodes downstream of "many" hooks are fine with read only mbufs.

Store the current parameters of socket initialization in per socket data structures.
This way control and data sockets are allowed to have different buffer sizes (in theory).
And the buffer size of the socket in question is available for fragmentation handling, even if the sysctl values are changed.

We are going to hard production now.
Any interest in reviewing it?

Updated to revision 358500.

In D23727#525485, @neel_neelc.org wrote:

I thought about one "alternative": a copy-on-write mode for mbufs. However, this means modifications to the mbuf code.

In D22915#524996, @neel_neelc.org wrote:

However, I believe IP_FW_XADD will call commit_rules() via add_rules() (which is called via do_get3()), so I'm uploading an updated patch removing that code.

There is no implemented use case for count != 1.

Allow the documented version to differ from the real structure. Document only the guaranteed elements.

Using libnetgraph is sufficient, no explicit test for version numbers necessary.

Added two more occurences of direct use of NG_VERSION: libexec/pppoed/pppoed.c usr.sbin/ppp/ether.c

The idea is to allow a split of large messages into smaller ones over size limited links. In kernel this is never necessary.

Change to the correct idiom for enabled state.

Updated to revision 358355.

Updated to revision 358355.

That are the numbers for 400 CPE connecting per line for 12 lines and 900 active clients (dhclient ngethxxx).

  Type name   Number of living nodes
  ---------   ----------------------
        car     452
      patch      12
        tag      13
   one2many      13
     bridge       2
        bpf       1
        tee      13
vlan_rotate       1
       vlan    4865
     eiface    9600
     socket       2

Declare temporary variable as local.

Switch to a more effienct processing of rc.files

Updated to revision 358170.

In D23760#521993, @gallatin wrote:

I'm 1/2 joking, but what would you think about not supporting extension headers at all? They are the worst part of IPv6 and make everything complicated and add lots of hairy cases. What benefit are they?
(I'm legitimately curious)

In D23695#521734, @hrs wrote:

If we can assume an interface route also implies an on-link prefix, just installing an on-link prefix list entry upon installing an interface route is more reasonable to me than looking up the routing table because the current code uses the prefix list to determine if an address is a neighbor or not.

In D23695#521458, @hrs wrote:

I have no strong objection to allow a prefix route with no gateway, but I think the case pointed out in Bug 194485 can be solved by just adding an address with the delegated prefix on the interface (EUI-64 always works as the interface id). Is there any specific reason for DHCP-PD (or another use case) to have an interface route?

In D23721#521154, @neel_neelc.org wrote:

You make a good point.

I decided to call m_dup() one time and then call m_copypacket() on the copy made my m_dup(), so if the original packet gets modified, the copies made by m_copypacket() aren't affected.

I'm not sure if the NG_FREE_M(mcpy) is the right thing to do, or if it will cause problems with the copy. I didn't want to cause a memory leak, but don't want to remove the data and cause a null dereference in the copies either.

According to the man page "m_copypacket" makes a read-only version of the packet (by virtually setting some pointers to the same area of memory.
On contrary "m_dup" does copy also the content, so each version can be modified differently afterwards.

rebase to r358008.

In D23577#520236, @eugen_grosbein.net wrote:

Naturely, using setsockopt() for SO_SNDBUF/SO_RCVBUF.

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.

Fix a lot of errors.
Renaming the struct and fields.
id numbers are not longer generic ints, but uint16_t.
Fix locking.
Document creation of new nat instances in a more readable way.
Alloc memory only if outside of any locks.

Chance to a simple table based approach.
Remove the whole caching framework incl. special opcode extensions.
Keep the table small (dynamically allocated).
Move local managment structures from global into local file.
No need for externally visible tunables anymore, no man page changes.
Not yet fully tested (only module loading/unloading, rule creating, deletion).

If somebody has some spare time to land this, it would be fine.
I do not have any commit rights.

In general, I'm pleased with the renaming from the generic "alias" to "range".

considering routed as a common case, not a special handling

In D23577#518833, @eugen_grosbein.net wrote:

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.

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?

Well, we already allocate 2 such arrays for the rule index, so 512k won't drastically increase the footprint.

In D23586#519046, @melifaro wrote:

General comment: I'd prefer not to add non-resizable hashes. It should be system job, not user, to resize the hash. Unfortunately, there is no existing generic resizable hash primitive in the kernel code currently.

Speaking of this particular case, I would suggest doing it slightly differently.
We know that nat numbers are limited to 65k. Given that, we can simply allocate 65k array of pointers on the first addition of the nat rule, w/o bothering about hash efficiency, resizing, etc.

Is there anything missing?

Rebase to r357812

Rebase to r357812