I had not named you, but since you outed yourself, I will respond.
I wasn't blaming you for the memory leak, that's due an interaction with how strongswan uses it's "built-in" printf extensions and the implementation of same in FreeBSD's libc.
Moving the printf extensions from "builtin" (libc) to vstr stopped (nearly all of) the leak, but, due to the way the strongswan plugin system is architected, the SMP interface is not compatible with the vstr library.
Several times I tried to get you to replace the SMP interface with VICI, and each time you abjectly refused. This despite the demonstrated need, because SMP had been deprecated in-favor of VICI, and the technical debt incurred in maintaining a set of custom patches to a port.
When we finally undertook the work to replace the SMP plugin, it took less than two days to a full solution. In the process, we reduced the technical debt of the project, because we now need fewer custom patches to the Strongswan port in FreeBSD.
The "logs" have not been erased as you accuse. We put the formerly discrete patches (and patches on patches) on a branch in a copy of the FreeBSD 'src' and 'ports' trees.
In closing, a lot of the work you did here was good. It was really your poor attitude, tendency to 'go missing' for extended periods and repeated instances of involving yourself in situations that presented a clear conflict of interest that catalyzed your dismissal.
Two systems (one bare metal with 2 GB, one VM with 512 MB) report 33 MB less than physical in the webgui dashboard. So those two cases would indicate about 479 MB detection requirement would work. Or slightly less to allow some margin for variation.
Yeah and don't use any of the ADI/Netgate/or pfSense rebranded routers if you're using Gigabit PPPoE, they all use the crappy igb drivers :(
I had to build an i5 box to support it with the em drivers, works like a charm with all *bsd routing platforms.
There's nothing crappy about igb. In fact it's better than em.
Broadly speaking, igb supports newer / higher end Intel Gigabit adapters, and em supports older / lower end Intel Gigabit adapters. The driver was split somewhere around five years ago, as it was hard to support NICs with such a wide spread of architectural differences and offloading features in a single driver.
cmb / anyone - is the plan that 2.2.5 is the last 2.2 release unless a serious security issue or erratum arises before 2.3 is ready to release? It would be useful to know, as there is little point submitting further pull requests against RELENG_2_2 once 2.2.5 has released if there is no intention to make any further 2.2 releases.
That is the plan, though for small but beneficial things we may still accept a PR or put a fix on RELENG_2_2, so long as it's not a binary change someone could use gitsync to pull in things fixed post-2.2.5 even if we don't roll an official release.
I just turned AES-NI off and will see what happens. Thanks for the information.
I found a couple crash reports submitted from the same IP you're visiting the forum from, and it's not likely that's the cause in your case. There have been known AES-NI panics related to FPU in all versions, which the vast majority never hit, but some routinely hit. It's something we're pursuing upstream and expect to have resolved in 2.3. It's something to try, but I don't expect it'll have any impact for you.
Your crash looks nothing at all like those (nor any others I can recall offhand), and the two different crashes aren't even similar to each other. Most often when you're getting crashes with that frequency, and they're not the same or at least similar, the root cause is a hardware problem. Both those were memory corruption related, which could still be a software problem.
If you're continuing to get crashes, keep submitting the crash reports, and start a new thread since this is not the same as the original issue here, and I'll check them and suggest how to proceed from there.
I didn't mention it in the last post, but after the changes, rebooted both sides, and the tunnel came up. But just went ahead and added this VPN>IPsec, Pre-Shared Keys tab, with identifiers back in, rebooted, and the tunnel came up again. Will leave this as the new running config and will watch it for stability to make sure it survives rekey and all.
tried a fresh install of 2.2.4 on all the 3 CF cards, booted it, configured interface, restored config and rebooted fine. Edit file also works. Even tried both things multiple times and with CF permanently mounted as RW as well as RO and then let it switch automatically when restoring config and in all possible scenarios everything works all good on 2.2.4 on all the 3 CF cards i have from pcengines so definitely something changed between 2.2.4 and 2.2.5 or some other patches in the php files etc caused this to happen to my box which was merged in 2.2.5