User Details
- User Since
- Jun 15 2015, 5:39 PM (504 w, 2 d)
Jan 8 2025
@des did you find the time to make a technical assessment? thanks!
Dec 23 2024
The Common Criteria aspects are documented here https://docs.vmware.com/en/VMware-SD-WAN/6.0/VMware-SD-WAN-Administration-Guide/GUID-DF592A36-E680-44CE-ABFC-ACE19B55B448.html
Dec 20 2024
Dec 18 2024
change summary
@kp let me know how to proceed
Dec 16 2024
We've tested https://github.com/opnsense/src/commit/7f55b75b successfully with the user in OPNsense.
Dec 13 2024
Dec 11 2024
Dec 6 2024
Dec 5 2024
Done, for reference: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283137
Dec 4 2024
Potentially fixed by c22c98798 ;)
This commit likely causes the following panic reported by multiple users:
Dec 3 2024
Offered a test kernel to the user in the meantime. @glebius is probably busy (last I spoke with him) and doesn't mind if you commit?
Like this?
Dec 2 2024
For the record I have no stakes in SCTP and I'm not involved in the changes done here. This work with the user reporting it is a courtesy to the FreeBSD pf code and to triage panics which I only think is a good idea for production code.
What's the status now? From my point of you I've explained the previous behaviour, the change that caused this to exhibit the wrong behaviour and how it was fixed. I'd like to get to a more productive cooperation based on technical urgency. I don't think tests prevented this from happening and I don't think the issue gets any better discussing commit messages.
Nov 28 2024
Here it is:
Nov 27 2024
Feel free to make a different suggestion. I've long been under the impressions explaining one liners is not the scope of a commit message and the tests should make this rather clear as requested in previous discussions.
I changed the summary.
D47658 is on hold as I struggle to understand why the code discussed there is not covered by existing tests and how to actually trigger it (it should easily panic after all but the code is never hit).
Nov 18 2024
Sounds good to me, thanks :)
Meh, sorry for the misinformation. All of this is very difficult to trace.
(kyua depends on e.g. libexec/atf-sh for script execution via shebang in /usr/src/tests/sys/netpfil/pf/*.sh)
I have WITHOUT_TESTS=yes and WITH_TESTS_SUPPORT=yes which adds kyua and libatf, but not atf tools in libexec. On a build without WITHOUT_TESTS=yes the atf tools are placed in the base system as a side effect.
Sure. For context:
I'm trying to understand the entry barrier here. If kyua fixes everything that's alright and thanks for the pointers. From release engineering scope there are a number of kyua integration challenges irrelevant to your argumentation (which I can understand), but you both seem to see the situation too easy from an established development workflow ("just do it right"). Using a custom src.conf already makes kyua defunct, but it is what it is. Going to raise appropriate patches elsewhere then. Thanks!
Nov 15 2024
So regardless of why I already stated this is a technical issue that is by no means "pointless", what do you suggest to improve this particular test to make it more robust? Uncontrolled creation of processes that inherit file descriptors isn't exactly clean design but I can see why you do not want to apply this mere bandaid with that larger issue at hand. I'm happy to do the work since a lot of people were asking for test cases and here I am offering work on test cases to get started. :)
Nov 14 2024
Thanks, just to be clear you imply the change is wrong even though the test still works?
Consider running tests from the src tree using atf-sh (I'm using devel/atf but the base one also works with the full path I think):
Nov 13 2024
Nov 8 2024
- libfetch: shuffle SSL_CRL_VERIFY options
"all" to "chain" is also fine. We can do "none" but it will just add conditionals to the code and the libfetch style works with implicit defaults everywhere. Your choice :)
So I avoided the "none" case for lack of functionality and added the "leaf" (could call it "one") case for flexibility. "opt" or "optional" .. I'm not attached either way. I also added the error number to the default message which has bugged me for a while now while testing this and the optional message that a CRL was not provided now goes to stderr which attempts to make sure it is seen by the user. In the pkg case fetch_info appeared to be suppressed somewhere. What do you think? :)
- libfetch: rewrite SSL_CRL_VERIFY behaviour
- libfetch: add the error number to verify callback failure case
- libfetch: wording
- libfetch: redo docs
Nov 6 2024
- lib/libfetch: feedback on previous
Oh about SSL_VERIFY or SSL_CRL I'm not sure. Keeping it closer to SSL_CRL_FILE may be more beneficial also with SSL_CRL_OPTIONAL in mind later. Don't want these vars too long if it can be avoided and cluster all CRL into SSL_CRL prefix?
Nov 5 2024
remove unused variable
Nov 4 2024
Oct 11 2024
Let's get this in for the sake of correctness although my testing was inconclusive and will circle back eventually.
Oct 7 2024
In any case finally fixed, thanks! :)
Aug 29 2024
as requested: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281125
Aug 8 2024
@pkubaj @erj we upgraded from FreeBSD 13.2 to 14.1 and ran into this driver related issue issue: https://github.com/opnsense/src/issues/212
Jul 31 2024
Jul 30 2024
May 29 2024
Update the downstream code and adapt for main
May 28 2024
In principle this only changes the user side setup (rc.conf), not the ports side. There is no direct ports consumer of this feature and it tries to hook into all services in order to automate configuration changes when service commands are dispatched.
Yes I just need to wrap up testing for the updated GH PR
This won't merge, I'm talking to @imp at https://github.com/freebsd/freebsd-src/pull/1258
May 25 2024
May 24 2024
Maybe fixed, who knows ;)
Mar 26 2024
No takers? This has been in a half-working state in FreeBSD 14 for quite some time. :/
Dec 20 2023
@vmaffione yes I am not a committer
Dec 1 2023
- libnetmap: different approach as discussed on GitHub upstream
Nov 22 2023
Nov 21 2023
Maybe to add to that: the main motivation was a user-side precmd type hook support since the precmd is hard or impossible to overwrite (being used in the rc scripts defined by the ports) and name_setup=path/to/file seemed to be the easiest solution.
Set up script variable:
@oshogbo I've updated this again fixing a remaining issue with restart_precmd -- if you can find the time to review I'd appreciate it.