Hello,

Just to update about the crashs: they didn't happen again.
Also, I've being using Suricata 6.0.3 release since than, and no netmap issues 😸

So, I changed my RAM, and tested the old ones:
24H of MemTest86+ and at least 5hrs of GoldMemory (not the best tests, but still), resulted in not a single red flag for them (tested individually), AND I'm using them on other Win machines withouth BSOD or anything in the logs.

I already saw RAM tests failing to detect problems, so based on what you explained, I'm assuming that both 1 - the issue with Suricata's Multithreading ring access, and 2 - darkstat, were hitting some intermittent problem, that I could not with tests and other OS.

Anyway, thank you for helping me out solving this. Really appreciate @stephenw10 and @bmeeks !

@akegec thanks ... no luck so far. I'll see if I can find the post you are referencing.

there is nothing to worry about, just make a backup of you configuration from diagnostic / Backup and Restore just in case.
uninstall pfblockerng and install pfblockerng-devel
You probably only need to reconfigure it
there are no particular precautions or particular problems to take into account
the code is just more updated and stable, pfblockerng is old and will be removed in the future

Sorted it.

On line 96 of /etc/inc/ipsec.auth-user.php it reads:

$userGroups = getUserGroups($username, $authcfg, array());

Where it should read:

$userGroups = getUserGroups($username, $authcfg, $attributes = array());

To abide by PHP referenced variable.

Open a ticket with the support, they can 100% help you out.
https://go.netgate.com

-Rico

I have not been able to reproduce the problem here, but I can see how it might happen. I opened https://redmine.pfsense.org/issues/9582 to track it and committed a fix: https://github.com/pfsense/pfsense/commit/45f95753963e497b5ce14493f9cca05336d75c7b

You can install the System Patches package and then create an entry for 45f95753963e497b5ce14493f9cca05336d75c7b to apply the fix.

Alternately, you can use viconfig to edit the config and remove that <vlans></vlans> line, or download a backup, edit it out, then restore.

It crashed in a network memory operation.

db:0:kdb.enter.default> bt Tracing pid 12 tid 100026 td 0xfffff80004e1f620 m_tag_delete_chain() at m_tag_delete_chain+0x83/frame 0xfffffe01735bf8d0 mb_dtor_pack() at mb_dtor_pack+0x11/frame 0xfffffe01735bf8e0 uma_zfree_arg() at uma_zfree_arg+0x42/frame 0xfffffe01735bf940 mb_free_ext() at mb_free_ext+0xfe/frame 0xfffffe01735bf970 m_freem() at m_freem+0x48/frame 0xfffffe01735bf990 vmxnet3_stop() at vmxnet3_stop+0x273/frame 0xfffffe01735bf9e0 vmxnet3_init_locked() at vmxnet3_init_locked+0x2c/frame 0xfffffe01735bfa50 softclock_call_cc() at softclock_call_cc+0x13a/frame 0xfffffe01735bfb00 softclock() at softclock+0x79/frame 0xfffffe01735bfb20 intr_event_execute_handlers() at intr_event_execute_handlers+0xe9/frame 0xfffffe01735bfb60 ithread_loop() at ithread_loop+0xe7/frame 0xfffffe01735bfbb0 fork_exit() at fork_exit+0x83/frame 0xfffffe01735bfbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe01735bfbf0 vmx0: watchdog timeout on queue 0 vmx0: watchdog timeout on queue 0 vmx0: watchdog timeout on queue 0 vmx0: watchdog timeout on queue 0 vmx0: watchdog timeout on queue 0 vmx0: watchdog timeout on queue 0 vmx0: watchdog timeout on queue 0 vmx0: watchdog timeout on queue 0 vmx0: watchdog timeout on queue 0 vmx0: watchdog timeout on queue 0 Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 06 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80d0eee3 stack pointer = 0x28:0xfffffe01735bf8c0 frame pointer = 0x28:0xfffffe01735bf8d0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi4: clock (0))

It's not normal to see those kinds of NIC timeouts in a VM either.

I'd make sure your ESX or VMWare install is completely current first, and upgrade the VM hardware compatibility as far as possible. Also make sure the selected OS version matches what you have installed. The exact text will vary depending on your ESX/VMware version but it should be set to FreeBSD 11.x 64-bit.

That looks like a hardware issue but it's still processing. It's something different.

Steve

After spending time on this that I'd rather have back, I found that the root cause could have been any one or all of the widgets on the dashboard. After removing all the widgets on the source host and then redeploying the "All" configuration on the new host, the issue went away. The crash seemed to be triggered by clicking any link on the UI while the dashboard was present.

I would be surprised if that is what solved it. The behaviour really looks hardware related.

Still, it would be nice if that has resolved it. 😉

Steve