Rebase after other changes.

In D30166#678451, @markj wrote:

In D30166#677401, @donner wrote:

The free() is called outside of the interesting function an may be called on an still active component.

Sorry, I'm having trouble understanding what you're suggesting here.

In D30164#678274, @ae wrote:

I meant the case fwd tableargs.home.lan:8000.

In D30164#678109, @ae wrote:

Replacing _substrcmp() with strncmp(,,8) breaks the case, when "tablearg" is part of hostname:port syntax.

• Table name fixed.

Do you have a committer for this patch?

The free() is called outside of the interesting function an may be called on an still active component.

Okay, the ip*_output functions will always consume the mbuf. I just read the souce

Everything is better than EINVAL in this case. Even EEXISTS.
If the requested result is already active, even "errno = 0;" would be possible.

Add @kp for the pflog reference.

• Restructure the error handling in a more common way.

LGTM

Can you add a rule to drop fragments in jail "second"?

How do you ensure, that the packet is indeed reassembled by pf and not by the receiving stack?

• Free packet if not send at all.

So we are currently handle all multicast packets from LL sources as locally handled streams regardless of the destination.
That might be correct, even if the local machine is processing the multicast destination itself. So it is able to receive such stream over the local link.

May you please add context to the diff?

In D29797#669445, @kp wrote:

We have standardised on 2001:db8 for our IPv6 test ranges (e.g. in tests/sys/netinet6/{forward6.sh,mkd.sh,ndp.sh}). If there were a dedicated testing prefix I'd suggest we should change them all in a separate commit, but I don't think the benchmarking prefix is sufficiently better to justify changing.

According to https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml, the documentation prefix should never be assigned to any real interface. So please consider tto use 2001:2::/48 (benchmarking) instead. A real "Test-Prefix" is not assigned, yet.

In D29741#668129, @freqlabs wrote:

We only want to get the media status once, because we make changes to it in multiple operations. Right now we're applying each change to a fresh state, rather than accumulating the changes. When we finally get into the callbacks, we end up setting (and freeing) the result of only one operation, then the rest of the changes are skipped (because the callback is a one-shot).

May you please add tests for the edge cases where the number is exactly the limit?
Thanks.

So there is a singleton constructor, which caches the result for later usage?
But setmedia will free the struct without resetting the singleton?

https://blog.regehr.org/archives/268
It's complicated.

The variable b and the struct member rn_bit are both signed values because they are supposed to hold negative numbers.

May you please provide a full context diff?
I can't see, why the compiler issued a warning and how the fix will break other things (i.e. logic errors)

Yes, please. Remove this technical debt.

I do not understand enough from the testing infrastructure to help.

In D26447#663880, @gordon wrote:

All of that said, we are not removing the client from base. Additionally, ftpd will still exist in the ports tree and will be able to be trivially installed via the pkg system. Think of this like HTTP(S). We have a client in the base, but we do not ship a server. This will be the same scenario for ftpd.