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

The initial issue is gone now.

Crashed again.
Any idea what else I might do to aid debug?

I split your posts off to a new topic since, although it was a crash, it was nowhere near the same crash.

Yours is crashing in the NIC driver while processing an interrupt from a vr(4) NIC. Those Via Rhine NICs are very, very old (They're only 10/100!) and were never all that reliable. I would strongly suggest replacing that NIC with a quality Intel NIC gigabit NIC. And replace those Realtek NICs while you are at it.

There are existing examples in the code for doing this as well. Start here:

https://github.com/pfsense/pfsense/blob/master/src/usr/local/bin/easyrule
https://github.com/pfsense/pfsense/blob/master/src/etc/inc/easyrule.inc

Yeah if your running your esxi in your own lab with your own vms - I wouldn't use any of the mitigation anything for this family of exploits.. If there is any possible performance hit.. Which most all of these mitigations are.. Some can be a pretty stiff hit..

Do you recall when meltdown first came out.. Lots of hoopla about that.. Even though most use cases of pfsense would have zero need for concern with such an attack vector..

Lots of traffic about it here and elsewhere, etc.. negate put out this blog back Jan of 2018
https://www.netgate.com/blog/an-update-on-meltdown-and-spectre.html

The important take away
Most of our users should not be concerned as long as they follow our basic guidelines for limiting access to the WebGUI, shell as well as physical access to the pfSense appliance.

Same goes for all of these sorts of exploits..