Kristof Provost

> Looks like the last update didn't regenerate the syscall definitions? Do you mean the constants in pf.txt.const? Those are the ioctl numbers and they didn't change. I'll fix the...

> The CI task is failing because `gmake generate` on your branch modifies pf.txt. On my system the result looks like this: > I'm not sure why. It looks like...

I've been pointed at this patch, and mostly like it. I've pulled it apart into three changes: - print gateway - kill by gateway - kill matching states The first...

The usual approach for crediting is to either add a 'Submitted by: ...' tag, or - new in the git world - set the committer field to your name and...

It turned out that we could actually avoid the locking issue by being slightly careful about when we search for and delete the matching state: https://reviews.freebsd.org/D30092 (and test https://reviews.freebsd.org/D30093).

We've obtained a backtrace over all threads in a wedged charon process: (From https://redmine.pfsense.org/issues/13014#note-35, on strongswan-5.9.8) I am insufficiently familiar with the architecture of strongswan to work out where the...

That should be in strongswan.conf (https://redmine.pfsense.org/attachments/4529), right? ``` syslog { identifier = charon # log everything under daemon since it ends up in the same place regardless with our syslog.conf...

To the best of my knowledge, yes. These are bug reports from pfSense users and we've not been able to reproduce the issue ourselves yet.

Fantastic! I'll build that into a package and ask the reporting users to verify.

We use the native compiler on FreeBSD main, which for the most recent released pfSense version (23.01) is LLVM llvmorg-14.0.5-0-gc12386ae247c.