No, that's ok. I'm working on one right now since it's easy for us to reproduce, but I'm still gathering some data for it so I know more about when it happens.

Update: After clearing the pfBlockerNG logs and restarting pfBlockerNG services the error has disappeared. All seems to be running smooth again.

@grug0r said in High CPU usage /sbin/pfctl -ss: TL;DR /sbin/pfctl -ss pinning CPU at 100% Hello As per above and my reddit post Happy to provide further information. Devs are aware -- /me hands out coffee and cookies to devs : )

@jimp 2021.06.13 and after version has the issue [image: 4RLPFFM.jpg]

@gwaitsi said in 20210614.0100 just trashed my system: @jimp after re-installing with latest 2.5.2RC, the system information widget now shows /var seven times Unlikely that it's specifically /var but various directories underneath since there are a lot more separate ZFS datasets now. It's part of the new ZFS layout. But we're working on the best subset of those to show by default in the widget for the next release.

@jimp It's really weird. I just swapped from one gateway in the firewall rule to another and things were non-functional until a reboot to the firewall. After that, I was able to connect through the correct gateway and things were working correctly. I had done the above on the state purge and no rules turned errors on reload, but no avail on working until reboot. EDIT: Just tried it again on a different interface and different gateway and same thing. Only thing I am changing is the below. [image: 1622573507462-6d18bedf-f4a5-4647-b356-989d83c5ca13-image.png]

I can replicate that as well. I opened https://redmine.pfsense.org/issues/11982 for it

The QAT drivers are only in Plus, not coming to CE. That part of the dashboard status was likely intended to only show up in Plus.

@psp Next release will fix it.

@jimp After updating to 2.6.0.a.20210521.0100, this problem was solved.

The kernel now has been updated to return the desired a more correct error code that aligns with the change in RADVD ~~Well I spoke too soon, the revised patch is checking for the wrong error code. In my case, EINVAL also needs to be trapped (edited to point to the necessary additional error code). ~~

My previous post seems to have disappeared. Anyway, I was able to recover by editing /etc/inc/utils.inc per @rschell. So far, everything seems to be working after a reboot. Edit: the missing previous post was for this issue but different thread. Edit: just installed the latest build and everything is still working. I think this crisis is over.

@viktor_g That worked. Thanks

You haven't provided any information on the problem, other than "not work". There are plenty of people who are using IPv6 with no problems, myself included. If you put some effort into this by looking at other user reports on this forum, you will see that the users who get help are the ones that provide details about the problem. Users like you who say, "not work", don't get help. If you aren't willing to help others to help you, you aren't going to get anywhere.

@bobbenheim on 2.6 there was no traffic going through my limiter rules for IPv4/6 on floating or even upon moving the rules to the WAN Rules tab, this was on a fresh install on 3/31. I switched to 2.5.1-RC1 yesterday after seeing your post and my limiters work fine now.

@jimp if you want to pass it along... the better fix is to pass available_kernel_memory in the post data to keep up with the MVC refactoring that it is going on. I added an hidden input field in the form in /usr/local/www/systrm_advanced_misc.php at the end of the RAM disk section as follow: $group->add(new Form_Input( 'use_mfs_tmp_size', '/tmp RAM Disk Size', 'number', $pconfig['use_mfs_tmp_size'], ['placeholder' => 40] ))->setHelp('/tmp RAM Disk<br />Do not set lower than 40.'); $group->add(new Form_Input( 'use_mfs_var_size', '/var RAM Disk Size', 'number', $pconfig['use_mfs_var_size'], ['placeholder' => 60] ))->setHelp('/var RAM Disk<br />Do not set lower than 60.'); $group->setHelp('Sets the size, in MiB, for the RAM disks. ' . 'Ensure each RAM disk is large enough to contain the current contents of the directories in question. %s' . 'Maximum total size of all RAM disks cannot exceed available kernel memory: %s', '<br/>', format_bytes( $pconfig['available_kernel_memory'] )); // new hidden input field to pass available kernel memory in POST data $group->add(new Form_Input( 'available_kernel_memory', 'Available Kernel Memory', 'hidden', $pconfig['available_kernel_memory'])); $section->add($group); no changes required to the save data function in etc/inc/web/system_advanced_misc.inc