Thank you for the clarification.

There is also a conflict between this revision and D49681.

Interesting proposal - could you share the use case behind it?
I’d support this if it doesn’t impact IPv6 privacy, but in my case, it breaks temporary addresses.

Thank you! Now it applies fine.
I have given it a try and run a few tests between two bridged VNET jails. It works as described above. No observable regression, filtering works, and setting ifpvid 0 passes all the traffic, which is sometimes important.

Encouraged by the invitation on the freebsd-net@ mailing list, I was curious to try it out. However, the patch does not apply cleanly. Could you please publish a rebased version, if feasible?

Thank you for this fix. Works fine with Netlink.

Polished diff.

In D49681#1146197, @lwhsu wrote:

There is also D50108 implementing RFC 8981, I think these 2 patches can be reviewed together, at least the part of getting an interface identifier, as suggested in RFC 8981 3.3.2.

The timers were updated to align with those proposed in RFC 8981 more closely. The MAX_TEMP_DESYNC_FACTOR_LIMIT constant was renamed to MAX_TEMP_DESYNC_FACTOR_BASE to better reflect its purpose.

I later came up with a patch to adjust MAX_DESYNC_FACTOR upon net.inet6.ip6.temppltime modification. It's likely the indispensable part of the change, so now it's squashed with Fernando's original patch.

Since it was code in contrib, I didn't want to change it much; I just used a simple duct-tape fix. Indeed, PF_LOCAL works fine here as well, and it's likely the right fix.

🍾🥂🎉

Improved readability (indentations adjusted), unused condition removed.

Thank you for the support @adrian.
I am adding @roy_marples.name as a reviewer, he has deep insight since contributed a lot to this project.
The patch was submitted to the upstream and is awaiting acceptance.

I am not the committer, nor a real programmer, so my acceptance is not relevant, but I tested this patch extensively. Our IPv6 stack has not been getting many updates recently, so I am fully supporting this enhancement.

In D49681#1135632, @madpilot wrote:

In D49681#1135624, @zarychtam_plan-b.pwste.edu.pl wrote:

I’ve just updated to the latest version of the patch, and now I no longer see a stableaddr on the interface - only an address with an EUI-64 suffix is present. The initial version of the patch was working fine for an entire week.

It’s possible there’s a conflict with another patch I’m testing[1]. However, both patches were working together as expected last week, with no apparent interference between them.

1. https://bz-attachments.freebsd.org/attachment.cgi?id=252676

The actual assignment of the IP is now controlled via ifconfig per interface, and the setting needs to be already in place when the interface is brought up. A good way to do this is via rc.conf, like this:

ifconfig_net0_ipv6="inet6 accept_rtadv stableaddr"

If you want it enabled globally you should set the default sysctl via tunable, in loader.conf. The sysctl value is used as a default when creating interfaces, and unluckily changing it value via sysctl.conf cannot work because when that is applied interfaces connected at boot have already been created with the default value.

I’ve just updated to the latest version of the patch, and now I no longer see a stableaddr on the interface - only an address with an EUI-64 suffix is present. The initial version of the patch was working fine for an entire week.

Please ignore. It should be possible to cherry-pick D49681 after it lands without MFC of the above.

I am referring to this serie of commits:
commit a68e4f7a065218f0bcc5b34ff8d2e73a240b59b2
Author: Gordon Tetlow <gordon@FreeBSD.org>
Date: Fri May 31 13:58:52 2024 -0700

Will it be feasible to officially MFC this to stable/14? Old code prevents MFC of the upcoming " Implement IPV6 RFC 7217", currently in review D49681.

In D49681#1133961, @emaste wrote:

We should also enable by default - probably as a separate commit (which might not be MFCd if there are POLA concerns).

Here's the reference to complete list of Reserved IPv6 Interface Identifiers:
https://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xhtml

Could it bring a new flow of messages into the kernel message buffer? After today's upgrade of my desktop PC, I see plenty of "Can't enable IRQ/MSI because no handler is installed," which didn't appear in the past.

It looks like someone has to fix also:
gfx-beastie.lua
gfx-beastiebw.lua
gfx-fbsdbw.lua
gfx-orbbw.lua

Thank you for coming up with the solution. I can confirm that it fixes the issue for sc(4). Please don't hesitate to push it, preferably shortly.
Edit:
Wow.... already committed. Impressive timings!

The original review D25155 (https://reviews.freebsd.org/D25155) has been committed in rGf03e1a42e92e: ciss: Minor formatting nit. (authored by pen_lysator.liu.se, committed by imp https://reviews.freebsd.org/rGf03e1a42e92eff76dcf474655b600db37b04ae2b)

In D31844#718844, @eric_metricspace.net wrote:

Abandoning, due to the existence of the upstream module in cddl

In the commit message, there is no info about MFC. Are there any plans to MFC this to stable/14?

Verbosity and RECEIVE_DIAGNOSTIC were removed, the rest remains.

Not to hijack, but to boost the thread I am uploading this patch rebased on the most recent CURRENT. Perhaps a wider audience will find it also useful as I found to. The original patch by Peter Eriksson submitted to review D25155

Will/was the port be created ?

We probably need a similar change for IPv6 redirects.

Is it worth MFC to stable/14 before releng/14.1 gets branched?

Cherry-picking leads to CONFLICT (content): Merge conflict in sys/dev/hid/hidbus.c. So more MFCs are required, and it will probably break ABI. Please ignore my previous comment then.

It was committed on Thu Aug 3 19:10:50 2023 +0300 as 4b1712817e56840acc5e9fd59028ef79007ff579. There is no info about MFC, but this change seems to be silencing multiple messages seen in dmesg[1]. While these messages are irrelevant to HID functionality, after MFC we will get rid of them

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.