That's the way how DragonFlyBSD devs solved the problem
https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/451640b7cf6bcf7826b901ac9a51647442adb96b

I will keep you updated. It still applies, builds and runs fine on CURRENT and stable/14. The patch in the link below is rebased against recent CURRENT
https://zarychtam.pb.pwste.edu.pl/diffs/D25155_rebased.diff

Some people criticised this change, while others were enthusiastic. What about MFC? The commit message states "MFC after 1 week". It would be nice to MFC this change to stable/14. I have cherry-picked it just after the original commint and thus now get a 25% smaller zstd compressed archives of daily 5 GB log file.

Will it be possible to use legacy settings and compress logs using different tools, for example, some files with bzip2, others with xz and a few with zstd ?

Thank you. It deserves to be called the commit of the month. Would you please do a MFC to stable/14 ?

This script looks very promising, but it won't be easy to fulfill all committers' needs, but perhaps it would be easier to make it available as a port, for example, net-mgmt/ng_bpf_firewall ?

That's an interesting but not so important change. I think that the current "No such file or directory" is far better than the proposed "Invalid argument". When I saw "No such file or directory" for the first time it was clear to me that the module has to be loaded. "Invalid argument" will rather not bring any useful clues.

The patch still applies and works great on recent 15-CURRENT.

In D25155#927416, @imp wrote:

In D25155#927401, @imp wrote:

In D25155#926657, @zarychtam_plan-b.pwste.edu.pl wrote:

I am still testing this solution 24/7. So far I had no issues.
The patch rebased against recent CURRENT is hosted here:
https://zarychtam.pb.pwste.edu.pl/diffs/D25155_rebased_full.diffs

Hmmm, no it isn't... Is there a reason?

The current patch doesn't apply... Let's try to get this done this go around.

I am still testing this solution 24/7. So far I had no issues.
The patch rebased against recent CURRENT is hosted here:
https://zarychtam.pb.pwste.edu.pl/diffs/D25155_rebased_full.diffs

Perhaps it can be committed before stable/14 gets branched?

Neat, thank you for this one! Probably in stable/14 we will have no errors like the one below from stable/13.
[703139] [nl_io] PID 64148 nl_on_transmit: socket RX overflowed, 218 messages (18848 bytes) dropped. bytes: [202095524/805306368] mbufs: [1073741312/1073741824]

The rebased patch applies clearly on stable/13, there were also no problems running patched stable/13. I hope it will make it into the head before stable/14 is branched. Whilst additional ciss(4) verbosity could be helpful, fixing the enumeration problem for a larger number of disks is critical.

The link was temporarily disabled due to problems with the Apache where I was testing things related to another PR 268318. It should work now. I am sorry for the inconvenience.

I tried to get rid of problem with hidden devices and applied the change suggested by kaktus. Updated diff works for me.

I have a while to take another look into this promising patch and found out that the culprit of not mounting the root filesystem was the setting: hw.ciss.expose_hidden_physical=1 in loader.conf, which really did nothing before* the patch but also was harmless. After removing this line from loader.conf I booted successfully in normal and verbose mode. Since I am not able to update the review, I paste links to the patch. I skipped changes in lines 1287-1289 and had to change a bit 2345-2346 to rebase on the recent main.
https://zarychtam.pb.pwste.edu.pl/diffs/D25155_rebased.diff
https://zarychtam.pb.pwste.edu.pl/diffs/D25155_rebased_full.diff
Perhaps the author can look into this and fix, add 1287-1289 if relevant and update the review. It's still probably possible to reach the main before stable/14 gets branched.

I have rebased patch against the recent HEAD, compiled, installed and rebooted. The hardware for test was Hp Proliant Dl360 G7 with
ciss0: <HP Smart Array P410i> port 0x4000-0x40ff mem 0xfbe00000-0xfbffffff,0xfbdf0000-0xfbdf0fff irq 28 at device 0.0 on pci1
with 3 logical drives and firmware 6.64. This controller is not capable of switching to JBOD, at least when flashed with official firmware, so I was using each disk as a separate logical drive.

Thanks for taking care of the problem. Will it grow vnet memory requirements? Can the change be applied safely to stable/13? Are any plans to MFC when gets committed to HEAD ?

In the future FreeBSD will have ip(8) or it's analogue. Mentioning now these temporary -o -O in netstat(1) will probably bring more harm than benefit, so the -o and -O options should remain as options for insiders.

As the person from whose inspiration D38644 was created, I can only refer to the annoyance and usefulness of messages generated this way. Currently, setting the net.inet6.ip6.log_interval to a high value does the trick of preventing log spamming, but it is not intuitive and easy for the average user to find without searching the source code. There is only a mention of this sysctl in inet6(4). Perhaps digging the mailing list archives could bring more ideas on how to get rid of the irritating "cannot forward src ...." from dmesg(8).
These types of forwarding error messages can be still useful to some extent, especially when a FreeBSD-based IPv6 router is deployed for a small LAN, it is easy, for example, to detect errors in the RA configuration. On the other hand, in the case of an edge router, which cannot do much with packets with a link-local source address received on the link from upstream, disabling the logging of these extinguished packets is an optimal solution (Yes, such packets do circulate in the Internet!). In this case, it will be even better to ignore them instead of sending "ICMP6, destination unreachable, beyond scope...", but I am far from demanding it nor want to put any burden on committers who would struggle with the implementation.

Thanks for taking care of it, looks to me like another positive change.

Unfortunately vt(4) still doesn't support VESA Display Power Management Signaling.

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!