The Akismet plugin for NodeBB has basically zero configuration options. The only thing you can set is the reputation level above which it no longer applies.

Check for IPv6. pfSense will provide IPv6 by default if it sees it available and many devices will try to use it by default. If something upstream changed you might have IPv6 when you didn't before.

Hmm, Limiters do not have a priority like that in order that External traffic will get bandwidth.

It does have Weights but that simply divides traffic in ratio. It could help here but it won't solve it entirely.

You do need to use dynamic queues as shown in that blog post to share the bandwidth though.

You might be able to do it be using a 10M pipe for all traffic and an additional 10M pipe to Internal destinations. With both setup using dynamic queues to share bandwidth. That does mean you can never see the full 20M to an internal destination though even if there's only one client.

You can open a Redmine for that, will get addressed eventually. Seems like it will be quite a bit trickier to solve than it appears on the surface, though.

@gtenorio

Are you using PPPoE?
Since version 2.6, pfSense will be able to transport
the entire WAN load over much more then one queue.
So if the CPU is sorted with much cores and/or threats
it can be a really good chance to get a fast as can WAN port / throughput.

If you are running or using PPPoE you will be nailed
to one CPU core and one queue! So if you now
having much more to do for the CPU, it can be
pointed to that circumstance told above
(more queues = more throughput = more CPU
load or tasks)

7 x 1Gbps down/100Mbps up fiber
1 x 50Mbps leased line fiber

And with that much WAN ports, the entire amount of queues can be short and fast increasing once more
again and also stress the CPU once more as I see it.

You were correct. Swapping over to the latest 2.7 did not improve anything. I have rolled back to 23.01 at this point.

You might be able to do it for force reinstalling the repo pkg from:
https://pkg00-atx.netgate.com/pfSense_v2_4_3_amd64-pfSense_v2_4_3/All/pfSense-repo-2.4.3_4.txz

Then selecting previous version. However even that looks like it's set to use 2.4.4.
So maybe:
https://pkg00-atx.netgate.com/pfSense_v2_4_2_amd64-pfSense_v2_4_2/All/pfSense-repo-2.4.2_3.txz

Or create a custom repo conf file:

FreeBSD: { enabled: no } pfSense-core: { url: "pkg+https://pkg.pfsense.org/pfSense_v2_4_3_amd64-core", mirror_type: "srv", signature_type: "fingerprints", fingerprints: "/usr/local/share/pfSense/keys/pkg", enabled: yes } pfSense: { url: "pkg+https://pkg.pfsense.org/pfSense_v2_4_3_amd64-pfSense_v2_4_3", mirror_type: "srv", signature_type: "fingerprints", fingerprints: "/usr/local/share/pfSense/keys/pkg", enabled: yes }

The 2 links in a lagg is a much nicer setup but the switches should support cross-chassis LACP really.

@stephenw10
Got it thank you

Or check /etc/product_label /etc/product_name /etc/version.

I'm not sure how far back those go though so if you have a very old version they might not be present.

Steve

What problem are you looking for a solution to?

You should only need to wait. There is a restriction on how often the instance can pull repo data to prevent DoSing the server.
Or send me the NDI in chat and I can reset it for you.

Steve

Hmm, backtrace is similar but not identical:

db:0:kdb.enter.default> bt Tracing pid 96484 tid 100231 td 0xfffff8006f46e740 kdb_enter() at kdb_enter+0x37/frame 0xfffffe002eb0b630 vpanic() at vpanic+0x197/frame 0xfffffe002eb0b680 panic() at panic+0x43/frame 0xfffffe002eb0b6e0 trap_fatal() at trap_fatal+0x391/frame 0xfffffe002eb0b740 trap_pfault() at trap_pfault+0x4f/frame 0xfffffe002eb0b790 trap() at trap+0x286/frame 0xfffffe002eb0b8a0 calltrap() at calltrap+0x8/frame 0xfffffe002eb0b8a0 --- trap 0xc, rip = 0xffffffff811eef8e, rsp = 0xfffffe002eb0b970, rbp = 0xfffffe002eb0b9c0 --- vmspace_fork() at vmspace_fork+0x95e/frame 0xfffffe002eb0b9c0 fork1() at fork1+0x356/frame 0xfffffe002eb0ba60 sys_fork() at sys_fork+0x54/frame 0xfffffe002eb0bac0 amd64_syscall() at amd64_syscall+0x387/frame 0xfffffe002eb0bbf0 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe002eb0bbf0 --- syscall (2, FreeBSD ELF64, sys_fork), rip = 0x8003ed8ea, rsp = 0x7fffffffe558, rbp = 0x7fffffffe590 ---

But we see some errors in the message buffer:

<6>pid 75760 (unbound), jid 0, uid 59: exited on signal 11 <6>pid 4613 (awk), jid 0, uid 0: exited on signal 6 (core dumped)

I would guess that is pfBlocker updating except I don't see that running. In which case do you have a large number of custom Unbound values? Host overrides?

Check the crontab for processes running at 8.00. Installing the cron package will show that.

Steve

Yes that same fix is in the current 23.05 code.

In a virtual install like that I'd usually expect to see the LAN assigned to an interface connected to an internal only bridge. Such that other VMs on that bridge use pfSense as their gateway and traffic to/from them can be filtered.

Steve

@stephenw10 Hi,
Upgrading fails in all cases I have tried if upgrading from 2.6.0
Hyper-V and 4 different PC hardware routers I have tried it on.
I have two separate threads I started on that yesterday.
in the dev section for 2.7.0 CE
It used to work awhile back but at some point along the way it no longer works.
You can't upgrade from 2.6.0 to 2.7.0 dev latest
Well- you can but it results in an unbootable kernel or driver immediate failure when it goes
to reboot.
But works fine if you install the 2.7.0 CE memstick and then update from that.
That is my work-around and I'm very happy that at least works.
2.7 openvpns setups stay up like they're supposed to :)

That should work. Easy to test from a client using pfSense for DNS though. Just see if they resolve to 192.168.0.32.

Steve

@guardian said in How can I troubleshot these log messages:

Is there any reliable way to tell if unbound is really hung, or if it's just busy reloading?

Not really. Since if it takes that long to load the config Unbound really isn't running during that time.

You should not use the Service Watchdog for Unbound.

@cappie thank you for the reply. i have updated the drivers and rebooted, appears the interfaces were updated successfully. i'll continue to monitor the status over the weekend

@stephenw10 Thanks! That did indeed solve my issue.