Messages

Hi Toon,

This does indeed look suspicious. Perhaps it's best if you open a ticket on GitHub (https://github.com/opnsense/core/issues) with the relevant details you provided so we can track it more accurately.

Cheers,
Stephan

From the console, can you share the output of "# pfctl -vs ether -a captiveportal_zone_0" when your client is connected? (sanitize IPs as needed)

Well let me know if the issue persists on 25.7, and if so, how you tested it. Setting the idle timeout to 1 minute and leaving a ping running on the client should show quick enough if there is a problem.

For context, I tested on 25.7 but nothing has changed on the Captive Portal side between these two versions.

> There was a section where I had entered 10000 Mbp/s because there was no limit on the number of Mbp/s, and I had to retype this as 40000 Mbp/s or 4 Gbp/s, or use the command revert

Validations were added to the GUI to prevent entries above 4Gbps a long time ago, perhaps this configuration was from before this validation was added, and now crashes due to the backend service change.

Before this patch the shaping was fully handled by IPFW, so if it broke there, traffic would likely still pass through pf. However, since pf now handles this and crashes on the pipe configuration it's reasonable to assume this would lock up traffic as well. However, since it's an incorrect configuration in both scenarios the right thing to do is to ditch the 10Gbps pipes.

A CARP VIP got deleted here while an IP alias was still present with the same VHID group, this should be a validation.

I'll add a patch that bails if no primary CARP is found, but your leftover IP alias should have its VHID group stripped as well.

Hi,

The development documentation is not live yet, but you can find it here: https://github.com/opnsense/docs/tree/dashboard.

Cheers,
Stephan

I did spin it as well in a VM, and I must say I am impressed, that new dashboard is fluid, also in regards of resources drain, I don't see anything significant.

Well done OPN devs.

Much appreciated! The design focuses on efficiency as much as possible in contrast to the old dashboard, which had a tendency to be slow on page load.

When you consider resource drain, there's always going to be a cost to data collection. Things are now better with the streaming implementations which prevent backend processes from having to start/stop all the time - reducing a lot of the overhead.

While the roadmap for the dashboard for 24.7 is set (some widgets have yet to be added), new ideas for widgets are welcome of course. For anyone willing to have a go at this themselves, the development documentation will be synced around the time of the 24.7 release.

Cheers,
Stephan

I just hope that will not be 'heavy' on CPU like the current one....

Which CPU, client or firewall?

In general, CPU/GPU usage has increased somewhat on the client side (neat graphics aren't free), and reduced on the firewall side.

Cheers,
Stephan

Thank for checking on the mobile too.

Yes that may be uncomfortable I am logging a lot via phone when I am on VPN or not on my PC.
Hopefully here will be some lock function or something to prevent widget movement when scrolling.

Regards,
S.

Sure, here you go: https://github.com/opnsense/core/commit/34cafe3e9835cb48c41ad063d2aba2700e7f701a

I hadn't done extensive tests on touch yet other than increasing the responsiveness with auto-sizing widgets based on screen size, but this is an obvious one.

Thanks for the feedback! The other points have been noted as well.

Cheers,
Stephan

Probably best to inspect the certificate chain in your browser to see what's being returned.

Hi there,

I'm not aware of anyone working on this. If you could take a stab at it that'd be great. You don't have to submit a PR for every file, the PR should be limited to a single subject that the changes are trying to address, which may include multiple files.

That being said, if the PR is large, make sure you limit yourself to only the markup attributes (such as aria-hidden etc.) and don't introduce large changes in logic that need proper vetting - these should be submitted in a more isolated manner.

Cheers,
Stephan

The system log (system -> log files -> general), under process "kernel" should reveal if the driver has anything to say about it. The fact that the LEDs are not coming up shows that this is a low level linking issue. Either there is no other end, or the module is not compatible with the intel chipset.

the Max-Payload is a bit weird.. have you configured an MTU on the parent interface? If so, try removing it

What do you suggest putting as a prefix for the log statement besides just "dnsbl_module:"?  I'm currently using Result but not sure if there's anything better.

Perhaps "logger:" would suffice, it should only be unique within the scope of Unbound. I need to think a bit on this, but this can always be reviewed in the PR.

I have it working locally.  Now I just need to figure out the config setup to add a UI toggle.

Most of the steps required to build this are documented: https://docs.opnsense.org/development/frontend.html. Luckily the general page was already migrated to MVC, so this should be plug&play.

What might not be obvious is the communication to the dnsbl_module itself. There's a concrete example here: https://github.com/opnsense/core/blob/master/src/opnsense/service/templates/OPNsense/Unbound/core/dnsbl_module.py#L167, in combination with https://github.com/opnsense/core/blob/master/src/etc/inc/plugins.inc.d/unbound.inc#L413