Trying to think who maintains the stuff for snort.. This is related to that I take it..

Prob be easier to just post up the "fix" and who maintains the package/port for pfsense could include it if they agree with the fix, etc.

You might notice that my fix was for a like 1 person ;) But did submit it to freebsd, and it got finally pushed down.

edit: Ah I see @bmeeks is already in your other thread - yeah that would be "the guy" to help for sure!!

These errors should all be fixed in the latest Snort-4.0_4 package for pfSense-2.5 snapshots.

Ahh yes, sorry for the mix up. Had to work late on a migration project last night and I'm kinda behind today.

Nice that's good to know. Thanks!

yikes i hope not :(
did reinstall still issues after installling packages .
all seemed well :( reset is the name of the game i guess.
cause daddy dun f'ed up :(

@bmeeks said in Suricata stopped working on 2.5.0-DEVELOPMENT (amd64) built on Sat Jun 01 20:37:20 EDT 2019:

That does sound interesting. I agree it sounds like a lot of coordination work to keep things straight. So does the user still have to choose the correct package from something like a list, or can pkg make a choice at install time?

If the package has a dependency set, it would have to depend on a specific flavor, so you'd have, say packagename@option1 for the package name with option1 enabled, and packagename@option2 for the package with option 2 enabled. What typically happens is then you'd have meta-ports for either one with slightly different names, and unique dependencies, and the user would choose one to install.

Another way would be to remove a specific dependency from the port and have the installer pick which flavor to install but since that breaks dependency tracking I wouldn't want to encourage that.

@JeGr Thanks!

It does boot but stops outputing to the console after mountroot. Exactly as though it's set to serial console as primary. But it isn't and you can't force VGA/EFI console from the boot loader.
Bigger brains than me are assigned to it. 😉

Steve

Just upgraded to the latest snapshot, 2.5.0-DEVELOPMENT-amd64-20190520-1137, and can confirm that this now seems to be working properly. Thank you for the quick response!

Are we talking about IP Addresses or Firewall Rules here? I see both in the posts up above...

If IP Addresses, what would be the point of removing or disabling those numbers at a later time, after your timer/scheduler expired? I understand the timed schedule on rules, and I use them myself. But I don't understand on IP Addresses.

Jeff

No. That crash is a filesystem problem, nothing to do with the update other than the update wrote files to the disk, so maybe it's hitting different spots on the disk.

If you still get errors, either you didn't run fsck enough times, or the filesystem is too corrupt and you need to reinstall.

Also possible, though less likely, is that there is a hardware problem with the disk or controller.

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.

For the record, if anyone needs this and wants an actual answer, the file is located here currently: https://github.com/pfsense/pfsense/blob/master/src/usr/share/doc/radius/dictionary.pfsense

VENDOR pfSense 13644 BEGIN-VENDOR pfSense ATTRIBUTE pfSense-Bandwidth-Max-Up 1 integer ATTRIBUTE pfSense-Bandwidth-Max-Down 2 integer ATTRIBUTE pfSense-Max-Total-Octets 3 integer END-VENDOR pfSense