@motific Not sure; not using pfblocker-ng.

I have reverted to the latest Stable version and it is now working as expected. I will leave it like that for now, and maybe set up a 2.5 test again in a short while.

Elfranko

I didn't find issues at all, I'm not using traffic shapers or any super advanced feature. I think.

In the end I sort of panicked and restored the official version just for peace of mind. I think it might be ready to go, at least in VMs.

@jimp said in pfsense crash report happens daily then reboots:

I'd blame the bxe driver.

appreciate the feedback ive uploaded the file in text document if that helps.

textdump.txt

I finished! There was nothing but the scary warning.

The tiny files were like headers/metadata for the huge ones. It wasn't that hard, what I'm curious is how the **** are they treated like a folder?! That's kinda cool.
Screen Shot 2020-09-06 at 07.37.47.png

Soo much to learn, I can't even… Anyway, I couldn't attach them so here they are https://blahblah…-ends-with: dump-date20200905-time184037.zip. I'm sure somebody will make them go where they need to go and I now have one freshly guilt freed conscience.

Happy weekend everyone! :)

@JeGr said in cant login webgui:

Then your import is wrong. Seems you're trying to import network aliases as host aliases. That parsing with large lists alone would likely time out the PHP-FPM worker as the max execution time is reached. Would be my guess it's PHP rather than NGINX (as the latter makes no sense).

i am import a lot of ip CIDR list to networks.

this has good tool, I use tools to aggregate many ip network segments. This can reduce the number of IP network segments

https://tehnoblog.org/ip-tools/ip-address-aggregator/

idc3.txt

@louis2 said in Package Version Control, can anyone explain? (I am lost):

Someone has to compile the PIMD-master as it is now, including all those bug fixes (380! +) , in favor of FreeBSD .....

That should preferable be someone who has already the required development setup ...... and experience ....

Then we have to do some testing to assure that it is at least running correctly in the majority of situations.

Can't hardly be worse than it is now 😊

Louis

...Agreed...the author of PIMD...and he should probably do a version bump sometime. Somebody else doing it may unnecessarily fork it, and perhaps the author hasn't done a version bump because he doesn't feel good about where it is at.

@stephenw10

Ok, thanks.

Also, more detail here: https://forum.netgate.com/topic/154467/vlans-not-working-in-20200613-0050

@bmeeks

You are probably right. I did not see any realistic options as well. That is the reason, I did start this topic, just hoping anyone had a solution.

However, I did write a lot of software over time, and I do have a lot of technical knowledge, but all not related to vm, github, C, FreeBSD etc. And even if I did have that, the effort of creating:

vm for pfsense vm's for network, servers and pc 's as source and destination configuration testcases etc

Just not realistic 🎃

The only thing perhaps possible for the boot issue, is downloading the pimd source to have a look under which conditions it does generate the messages I see in the boot log.

I assume that just before it generates those messages, it does perform a function call towards an OS-layer just below PIMD. That would than my No-1 verdict ☺

Louis

It would be in the <nat><outbound> section.

@bmeeks Great, this is very helpful information (and thanks 👍 for your work on the Snort package! )

All of the backtraces in that are identical:

db:0:kdb.enter.default> bt Tracing pid 26689 tid 100757 td 0xfffff80251dd5620 kdb_enter() at kdb_enter+0x3b/frame 0xfffffe046257aaa0 vpanic() at vpanic+0x19b/frame 0xfffffe046257ab00 panic() at panic+0x43/frame 0xfffffe046257ab60 trap_pfault() at trap_pfault/frame 0xfffffe046257abb0 trap_pfault() at trap_pfault+0x49/frame 0xfffffe046257ac10 trap() at trap+0x29d/frame 0xfffffe046257ad20 calltrap() at calltrap+0x8/frame 0xfffffe046257ad20 --- trap 0xc, rip = 0xffffffff80e9a6fa, rsp = 0xfffffe046257adf0, rbp = 0xfffffe046257ae00 --- in_delayed_cksum() at in_delayed_cksum+0x5a/frame 0xfffffe046257ae00 pf_test() at pf_test+0x2493/frame 0xfffffe046257b010 pf_test() at pf_test+0x2088/frame 0xfffffe046257b220 pf_test() at pf_test+0x2088/frame 0xfffffe046257b430 pf_check_out() at pf_check_out+0x1d/frame 0xfffffe046257b450 pfil_run_hooks() at pfil_run_hooks+0x90/frame 0xfffffe046257b4e0 ip_output() at ip_output+0xa53/frame 0xfffffe046257b610 udp_send() at udp_send+0xa0c/frame 0xfffffe046257b6d0 sosend_dgram() at sosend_dgram+0x345/frame 0xfffffe046257b730 kern_sendit() at kern_sendit+0x1f9/frame 0xfffffe046257b7e0 sendit() at sendit+0x19e/frame 0xfffffe046257b830 sys_sendto() at sys_sendto+0x4d/frame 0xfffffe046257b880 amd64_syscall() at amd64_syscall+0xa86/frame 0xfffffe046257b9b0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe046257b9b0 --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x801f929ea, rsp = 0x7fffdf5f84a8, rbp = 0x7fffdf5f84f0 --- Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x18 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80e9a6fa stack pointer = 0x28:0xfffffe0462267df0 frame pointer = 0x28:0xfffffe0462267e00 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 = 11651 (unbound) trap number = 12 panic: page fault cpuid = 3 KDB: enter: panic

I'm not seeing any similar backtraces for previous crashes when I search, but in_delayed_cksum at the top of that makes me suspect it may be an issue with checksum processing, but it could also be a hardware issue in general.

Maybe try toggling the hardware checksum option under System > Advanced, Networking tab