This inconspicuous tool might be handy, thanks.
Is MFC to stable/13 planned?

Thank you for adding ChaCha20-Poly1305 support to KTLS and bringing it to the wider audience. I see these bits or at least "kern.ipc.tls.stats.ocf.tls13_chacha20_encrypts" in stable/13 since a while to, but can't make it working (GCM and CBC works fine). Does it require CURRENT or OpenSSL 3.0 to do the trick?

Thanks for this patch. I had the opportunity to test it a bit on two routers running the most recent stable/13 and looks like there is a problem with forwarded packets, so the solution is fine for the host but not for the router. While the entry is being added on the router, then it disappears and normal arp resolution begins which after a few seconds results in acquiring the correct arp. Steps to reproduce:

Thank you for reimplementing this really valuable feature.
Is anything that prevents committing it ? I am eagerly waiting to cherry-pick it to stable/13 to kill some L2 traffic on the border router.

I am sorry for the noise. Everything works fine. It looks like /etc/ssl/openssl.cnf was a bit overweight and busted.

In D31440#723967, @jhb wrote:

This change was already MFC'd to stable/13. Note that because of this change, you now need to enable KTLS explicitly as an SSL option. One way is to use a config file (and in a followup to the commit to main I gave an example config file which does this).

Thank you for taking the time to take a look at this. It is appreciated. Probably better solution will be to add this as another fortune to /usr/share/games/fortune/freebsd-tips.

Of course, it works with xfce4-terminal and others including terminal MATE, terminal Gnome, even vanilla xterm.

Will the MFC to stable/13 of this change unbreak not working kTLS in this branch? It looks like after recent OpenSSL upgrade kTLS stoped working here. Now stable/13 in the base system has OpenSSL 1.1.1l-freebsd 24 Aug 2021 is installed and despite the fact it was built with WITH_OPENSSL_KTLS=yes and enabled ,all kTLS related stats are empty:
kern.ipc.tls.stats.ocf.tls13_gcm_crypts: 0
kern.ipc.tls.stats.ocf.tls12_gcm_crypts: 0
kern.ipc.tls.stats.ocf.tls11_cbc_crypts: 0
kern.ipc.tls.stats.ocf.tls10_cbc_crypts: 0

I have tried to apply this patch but crypto/openssh/sftp-realpath.c seems to be a completely new file missing in 14-CURRENT sources.

This is likely the optimal choice. Thanks for the explanation of how the affiliation is gonna work here.

Very positive change, but looks a bit ridiculous at a glance. The Regents will be replaced by Netflix, Inc, but was at that time Netflix really involved?

Tested on stable/13. Affected counters work fine again after applying the patch.
Thank you for the fix.

It seems not to be easily reproducible. I am testing it on stable/13 for more than 1 mont and so far I have had only two panics while switching from dxr to dpdk_lpm4, though neither one was properly recorded (no core dumps). Likely those panics are more related to algo switching than to specific algo, but for some time I have USB key plugged in and configured as a dump device.
The overall performance of DXR algo seems to be decent., but the MFC to stable/13 might help with bringing it to a wider audience and more intensely testing.

I have updated patch to clarify how to obtain firmware files. Port builds and works 100% fine. It was tested with portilint and poudriere testport.

I have cherry-picked "2aca58e16f50 - main - Introduce DXR as an IPv4 longest prefix matching / FIB module" with "aad59c79f5f2 - main - Fix panic when trying to delete non-existent gateway in multipath route" to stable/13 and tested a few hours under light load without problems. Everything was going fine until I tried to switch manually to dpdk_lpm4 what immediately introduced panic. Unfortunately I have no core of this panic. After reboot I tried to reproduce this but it seems to be not so easily reproducible. DXR was working fine, function dxr_build with caller dxr_change_rib_batch seems to be still active, but not overloading this 8-core ATOM.

It's great to see another, performant route search algo in reworked FreeBSD's routing stack, especially that MFC is planned after 1 week. I have to admit that really, the name "dxr_lpm4" and would be probably more recognizable since at a glance fib_dxr looks to me like an addition or supplementation to dpdk_lpm4 and other (bsearch4, radix4, radix4_lockless) routing algos, but from the above review, I assume that it's another independent routing algo module and should be considered as full replacement, not any supplementation.
As a potential tester on stable/13 branch, I have a question regarding FIB_ALGO auto-selection - as far as I understand it's neither enabled nor planned yet? I want also to ask if any fib_dxr6 for IPv6 is planned?

I am not from the community of developers and gave some feedback on this on the freebsd-stable@ mailing list. I don't know what you get from depreciating it. If the security is the concern, then it's completely misfired since ftpd is not enabled on default. Comments about deprecating also ftp client I get as an April's fool joke. I don't believe that purging insecure protocol daemons from the base will make the operating system more modern or secure.
On the other hand, so far there was no note about svnlite(1) deprecation and removal, but problems with this, useless now svn, prevented WITH_OPENSSL_KTLS=yes from being the default in FreeBSD 13.0. We have still have useless biff(1) in the tree - so far no notes about deprecations of either one.

Overcome by events.

Added commit hashes.

This one probably has to be documented either in the handbook or in wiki pages. Extending lib/libpam/pam.d/ files is probably an undesired way of making people aware of such a gap in password policy enforcement.

Update to fix context issue

In D28933#648321, @naito.yuichiro_gmail.com wrote:

In D28933#648167, @zarychtam_plan-b.pwste.edu.pl wrote:

The IPv6 endpoint is accepted fine, but the tunnel is still not able to carry the data, at least legacy IP. Is it the complete solution or am I missing anything? At a glance, some outgoing and returning traffic can be dumped on the wg(4) interface, but it doesn't look fully functional since it behaves like a sinkhole with no local exit.

Yes, this patch works for me.
I'm going to show you a simple example between hostA and hostB.

After setting up wireguard tunnel:

hostA:
ifconfig wg0 inet 10.0.0.1
route add -host 10.0.0.2 -iface wg0

hostB:
ifocnfig wg0 inet 10.0.0.2
route add -host 10.0.0.1 -iface wg0
ping 10.0.0.1

Could you try this one?
wg(4) is a interface so that outgoing packet must be routed via the interface.

In D27656#648184, @debdrup wrote:

After talking it over on IRC, I think this needs little more descriptive information as to what the options in the config files do.

Further, the note in the manual page is ambiguous - what are the circumstances? (Submitter mentioned ssh on IRC, but this needs to be elucidated).

The IPv6 endpoint is accepted fine, but the tunnel is still not able to carry the data, at least legacy IP. Is it the complete solution or am I missing anything? At a glance, some outgoing and returning traffic can be dumped on the wg(4) interface, but it doesn't look fully functional since it behaves like a sinkhole with no local exit.

Update pam_passwdqc(8) manual page to reflect and highlight the change and let the user chance to get the gist.

When the password is expired user root changes password on the behalf of the user during the login process, so only "enforce=everyone" will be fully respected here.

Thanks for in-kernel Wireguard. That's really great news before 13-STABLE is branched !
Everything works fine for me allowing to tunnel both legacy IP and IPv6 over legacy IP link. I was not able to utilise IPv6 address as tunnel endpoint so far. It failed with such an error: "wg0: wg_peer_add bad length for endpoint 28". Will tunnelling over IPv6 be supported in future?

Removed GH_PROJECT= and a few whitespaces; reachable e-mail address of port maintainer added.

Updated to meet reviewer's suggestions

Update to pkg-message and cleanup.

I don't know if comments to this review are still relevant, but I'd like to report that this driver built on recent 12.1-STABLE can work fine after resume. To enable suspend/resume support the module acpi_iichid has to be unloaded and loaded again which can be done for instance with the help of rc.{suspend,resume} scripts.

This patch allows to seamlessly get ow_tem(4) working over 1-wire bus on boards, where building custom overlay is more problematic like for Pine64-LTS.
For this board only adding a few lines to /boot/loader.conf is required:

Spleen 1.6.0 has been released a few days ago --> https://github.com/fcambus/spleen/blob/1.6.0/ChangeLog. It would be a nice Christmas gift for 4K monitor users to add this font to the base.

Works fine for me on Raspberry Pi 2 running patched 13.0-CURRENT. Patch was applied on r355585

Updated D16698 builds and runs fine on 12-STABLE though it still lacks resume support.

Please commit this simple patch and MFC to 12 before code slush phase begins.

Builds on 12.0-STABLE r343501 sources and works fine with Dell Latitude 5590. Thank you!