User Details
- User Since
- Oct 8 2018, 2:48 PM (188 w, 5 h)
Feb 19 2022
Feb 10 2022
This inconspicuous tool might be handy, thanks.
Is MFC to stable/13 planned?
Jan 6 2022
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?
Nov 16 2021
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:
Nov 2 2021
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.
Oct 2 2021
I am sorry for the noise. Everything works fine. It looks like /etc/ssl/openssl.cnf was a bit overweight and busted.
Sep 25 2021
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.
Sep 23 2021
Of course, it works with xfce4-terminal and others including terminal MATE, terminal Gnome, even vanilla xterm.
Sep 22 2021
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
Sep 6 2021
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.
Aug 1 2021
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?
Jul 1 2021
Tested on stable/13. Affected counters work fine again after applying the patch.
Thank you for the fix.
Jun 14 2021
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.
Jun 13 2021
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.
May 8 2021
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.
May 5 2021
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?
Apr 4 2021
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.
Mar 16 2021
Overcome by events.
Mar 15 2021
Added commit hashes.
Mar 14 2021
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
Mar 2 2021
Feb 26 2021
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.
Dec 17 2020
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.
Nov 30 2020
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?
Jan 26 2020
Removed GH_PROJECT= and a few whitespaces; reachable e-mail address of port maintainer added.
Dec 28 2019
Updated to meet reviewer's suggestions
Dec 27 2019
Update to pkg-message and cleanup.
Dec 25 2019
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.
Dec 11 2019
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.
Dec 10 2019
Works fine for me on Raspberry Pi 2 running patched 13.0-CURRENT. Patch was applied on r355585
Jul 28 2019
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.
Jan 27 2019
Builds on 12.0-STABLE r343501 sources and works fine with Dell Latitude 5590. Thank you!