Messages

Nice, thanks for the feedback!


Cheers,
Franco

This isn't about tools or politics.

When OpenVPN XOR patch was needed 10 years ago OpenVPN upstream declined to use the extension. FreeBSD ports maintainer reluctantly added it and tried to kill it every chance he got, too. The patch was rather small and controllable and completely optional.  You could use it from the advanced parameters found in the OpenVPN legacy GUI. We gladly kept it in OPNsense and defended it in FreeBSD ports as long as we could.

Fast forward 10 years and now we're asking:

Kernel module that can potentially crash the whole system or take it over. A toolkit to configure it. A user-space alternative that WireGuard itself abandoned years ago. And there is no plugin that was written yet... looking at the evolution of WireGuard plugin that is a lot of work to be made by someone, too.  Then somebody will drop an AI generated plugin as becoming customary nowadays. Is that really the way to go?

So I'm asking for a commitment here, because it's asking a lot of the project. WireGuard was rough (with community plugin being the first few years), NetBird and Tailscale do work but I don't particularly enjoy the complexity and the plugins IMO need a lot more work (including documentation). I just don't see that happening here and adding another hoping this one will do it will not help either.

Again, nothing against it, but it needs a committment from someone and then they are asking for a commitment on review and keeping it afloat when bugs arise from the community and us.



Cheers,
Franco

Nice job :)


Cheers,
Franco

https://github.com/opnsense/core/issues/10127#issuecomment-4234178683

In part that is because the use case was just created and there were also FreeBSD patches that needed to be written in order for it to work at all.

This will need more real world exposure to create best practices for.


Cheers,
Franco

Thanks for the hint. This makes it a lot easier to look for the issue.

GitHub PR (assume you created it too) is https://github.com/opnsense/core/issues/10124


Cheers,
Franco

Make sure to mention what version you're using.

We hotfixed 25.10.2 now due to the side effect from the security update:

https://github.com/opnsense/changelog/commit/055b8d6


Cheers,
Franco

A hotfix release was issued as 25.10.2_11:

o system: move ldap_escape() to caller for now to avoid side effects

Nothing is automatic... it's recommended to use "wan" "lan" "optX" because that's what the backend code understands easily and can convert:

https://github.com/opnsense/core/blob/f1a3150fa9b2401d515ab651affa125469decc1e/src/opnsense/scripts/interfaces/gen_duid.php#L45

$interface = 'wan';
$device = get_real_interface($interface);

$device will be the underlying network device name.

Make sure to copy the require_once entries of the script above because that's what the function needs in order to work.

The script also has an example to execute shell code.


Cheers,
Franco

Can you please be a lot more specific?


Thanks,
Franco

> I'll be euqally blunt. Who are you talking to?

I haven't seen your screenshot yet. You illustrate the problem of flushing pagination, action buttons, apply bad out of the browser view.

> Fix your release notes, unless you want to come across as a liar.

You really need to take a break and cool off.  Your screenshot shows that the grid uses the full height of the screen and this refers to "lots of empty space" by OP being fixed.


Cheers,
Franco

I'll be blunt:

> https://github.com/opnsense/core/commit/0e999cc5ab

this is real, works and addresses a specific concern.

> "browser must scroll"

this is vague, oversimplified and unrealistic.

I asked Stephan to look into this based on the topic and that's the end of it. PRs welcome.


Cheers,
Franco

The functionality change is evident when using the browser zoom.

A screenshot would help explain if the issue you're seeing is relevant to the changes or not.


Cheers,
Franco

> nobody uses parameters it seems, only a few (2, IIRC) internal scripts seem to

Yes, that's true for cron-visible actions (tagged with description: in the actions.conf file).  Also documented as such in the manual:

https://docs.opnsense.org/manual/settingsmenu.html#cron

It's also that the parameter passing from cron isn't ideal for multiple parameters but we want to change that, see

https://github.com/opnsense/core/issues/10075

> So, since this is cleared up (in a way), can I use the internal interface aliases, like "WAN" in the cron parameters somehow, and if so, how? Would be really handy. :)

Instructions unclear: what does your script do and what do you want to pass? internal identifier "lan" "wan" "optX" ? The passing is verbatim obviously but the question is what you want to input and how you want to use it underneath.


Cheers,
Franco

Hi,

Looks like one of the imfamous "cannot happen on FreeBSD" panics relating to turnstile_broadcast() during mutex operation.

The only thing I can say for sure here is that FQ PIE use is the culprit here and turning it off may avoid the panics.

--- trap 0xc, rip = 0xffffffff80c4ad10, rsp = 0xfffffe0084330db0, rbp = 0xfffffe0084330dc0 ---
turnstile_broadcast() at turnstile_broadcast+0x40/frame 0xfffffe0084330dc0
__mtx_unlock_sleep() at __mtx_unlock_sleep+0x76/frame 0xfffffe0084330df0
fqpie_callout_cleanup() at fqpie_callout_cleanup+0x83/frame 0xfffffe0084330e10
softclock_call_cc() at softclock_call_cc+0x129/frame 0xfffffe0084330ec0
softclock_thread() at softclock_thread+0xe5/frame 0xfffffe0084330ef0
fork_exit() at fork_exit+0x81/frame 0xfffffe0084330f30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0084330f30
--- trap 0xe0d0e0d0, rip = 0x2c262c262c262c26, rsp = 0xe3c7e3c7e3c7e3c7, rbp = 0x9282928292829282 ---


Cheers,
Franco