I was very excited when the ipsec/tcpmd5 module landed in stable since I've been having to compile my own kernel to get BGP with md5 signature to work. Unfortunately I am unable to use a pre-compiled kernel because while it includes the tcpmd5 kernel module, the ipsec_support kernel option is disabled in the default kernel config. Can this be enabled in time for 11.1? If I have to compile my own kernel anyway then having tcpmd5 as a module isn't terribly useful to me. Kernel Version: 11.1-BETA MFC of module ipsec into STABLE-11: r315514 https://svnweb.freebsd.org/base?view=revision&revision=315514 root@vps-vu-nj-1b:~ # kldload tcpmd5 kldload: an error occurred while loading the module. Please check dmesg(8) for more details. error in dmesg: KLD tcpmd5.ko: depends on ipsec_support - not available or version mismatch
I didn't have the goal to make TCP-MD5 loadable. This code was related to IPsec, and I had to redo it. So, it is just a bonus of projects/ipsec. I think it is too late to add IPSEC_SUPPORT to the GENERIC at time of producing the release.
Same problem here. Would be really nice to use a GENERIC kernel and binary updates for router projects using TCP-MD5.
Ditto here. Wondering what the point of making this a kernel module was, if it requires a custom kernel to load.
11.1-RELEASE is out, pull re@ from CC Update scope of request to CURRENT with desirable MFC (to stable/11)
Just so I understand, does this mean that there's a chance this will appear in an 11.1-Pn patch release, or is this a "wait for 11.2 if there is one" sort of case? I normally understand that we don't want kernel changes made within a release-cycle, but these are fairly minor changes (after all, full on options IPSEC is in -GENERIC) and it's pretty clear by the inclusion of the module that this support was intended to be there. Failing that, might there be a possibility of breaking out the ipsec_support option to a loadable that applies to -GENERIC as well? Perhaps something that could be compiled and loaded alongside base, even if not distributed with it? Updating to -STABLE on production systems is even more irritating than a custom kernel.
I think 11.2-RELEASE is realistic. Getting this to be an EN to 11.1-R probably isn't going to happen.
A commit references this bug: Author: jpaetzel Date: Thu Aug 31 20:16:29 UTC 2017 New revision: 323068 URL: https://svnweb.freebsd.org/changeset/base/323068 Log: Allow kldload tcpmd5 PR: 220170 MFC after: 2 weeks Changes: head/sys/amd64/conf/GENERIC head/sys/arm64/conf/GENERIC head/sys/i386/conf/GENERIC head/sys/powerpc/conf/GENERIC head/sys/riscv/conf/GENERIC head/sys/sparc64/conf/GENERIC
Any takers to test this with HEAD?
A commit references this bug: Author: jpaetzel Date: Fri Sep 1 15:54:54 UTC 2017 New revision: 323087 URL: https://svnweb.freebsd.org/changeset/base/323087 Log: Take options IPSEC out of GENERIC PR: 220170 Submitted by: delphij Reviewed by: ae, glebius MFC after: 2 weeks Differential Revision: D11806 Changes: head/sys/amd64/conf/GENERIC head/sys/arm64/conf/GENERIC head/sys/i386/conf/GENERIC head/sys/powerpc/conf/GENERIC head/sys/riscv/conf/GENERIC head/sys/sparc64/conf/GENERIC
I reverted r323087 for now.
A commit references this bug: Author: jpaetzel Date: Tue Sep 19 16:51:52 UTC 2017 New revision: 323770 URL: https://svnweb.freebsd.org/changeset/base/323770 Log: MFC: 323068 Allow kldload tcpmd5 PR: 220170 Changes: _U stable/11/ stable/11/sys/amd64/conf/GENERIC stable/11/sys/arm64/conf/GENERIC stable/11/sys/i386/conf/GENERIC stable/11/sys/powerpc/conf/GENERIC stable/11/sys/riscv/conf/GENERIC stable/11/sys/sparc64/conf/GENERIC
A commit references this bug: Author: jpaetzel Date: Tue Sep 19 20:40:06 UTC 2017 New revision: 323778 URL: https://svnweb.freebsd.org/changeset/base/323778 Log: Fix indentation for r323068 PR: 220170 Reported by: lidl MFC after: 3 days Pointyhat to: jpaetzel Changes: head/sys/arm64/conf/GENERIC head/sys/i386/conf/GENERIC head/sys/powerpc/conf/GENERIC head/sys/riscv/conf/GENERIC head/sys/sparc64/conf/GENERIC
To confirm, will this be the default in 11.2? -Dan
(In reply to Dan Mahoney from comment #13) Yep, per the MFC (merge from current) to the stable/11 branch referenced in comment 11. @Josh I believe this issue can now be closed/FIXED as resolved unless it's also a stable/10 MFC candidate.