@bmeeks that would make sense. It does take a few hours to appear again after I purge the block list.

@stephenw10 Yes, You are right.

Only few items were left in the partition.

root@:~ # mount /dev/ada0p2 /mnt
root@:~ # ls
.k5login .profile .shrc recover_configxml.sh
root@:~ # cd /mnt
root@:/mnt # ls
.cshrc .profile .rnd .snap .sujournal dev lib libexec sbin usr var
root@:/mnt #

@giyahban said in Netmap (Suricata) cause crash:

didnt know its not recommended to have vlan with inline mode.

Inline IPS Mode has some limitations. The biggest is that VLANs and other virtual interfaces are not currently well supported. Things like a Bridge or LAGG setup will not work well. VLANs are especially problematic. There is some work happening within FreeBSD's netmap code to make things better, but none of those experimental updates are present in the pfSense kernel yet.

If you want to use Inline IPS Mode, you should only deploy it on plain-vanilla Ethernet interfaces (meaning no VLANs defined and not a member of a LAGG or Bridge). You may get by with running Suricata on the physical parent interface only and NOT on each defined VLAN interface.

Yeah, if you've removed the IPv6 traffic that was triggering it you should be fine. 23.05 is not far off now anyway.

As follow up,
the changes proposed in the topic about proxmox seems to work. The firewall has been up for 60 days without an issue.

Tyvm!

@stephenw10 Appreciate the guidance!

@thebear 2 vCPUs and 8G memory.

The sleep it's referring to there is a sleeping thread rather than a system power state.

Yes comparing multiple crash reports is the next step here. If they are consistent it's probably a bug somewhere.

Steve

Yes, it could be. I'll try to replicate and open something if there isn't anything already open.

BTW:

How do i close a Thread?

Danke - hatte ich noch nicht entdeckt! 🙈

@stephenw10 Thank you

this fixed it seems to be working fine now. no problems so far.

@fireodo said in router randomly freezes:

@elliopitas
Hi,
maybe thats a Realtek driver problem. Read this:
https://forum.netgate.com/topic/166746/realtek-re-kmod-missing-in-pfsense-2-6-repository
Could be a possible solution ...

@mrpete said in page fault kernel panics after 2.5.2 upgrade:

the fact that it is a UFS panic proves fsck is needed?

Yes, that. You would not see that panic if ZFS was used.

Steve

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