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

I use /root/scripts as @jimp said keep backups.

I am having the same problem, when I setting everything in bridge mode and set the jumbo size on the nic cards. After rebooting the system its show jumbo size on the every nic card but when I do the ifconfig command on shell, to confirm the setting has saved its show on every device MTU 1500 and when I do the benchmark its showing 1Gbes per transfers and these on 10Gb network card.

Its must be a bug...
On the older version of Pfsense never had a problem.

@markchen
For now both Suricata and Snort simply dump the contents of a given log into a PHP data variable and then print the contents of the variable out to the browser. When the log files are huge, this operation exhausts the available PHP memory in the session.

For now, as @Derelict mentioned, reduce the size of the logs by turning on the log size limiting and rotation features under LOGS MGMT. Keep the max log file sizes to the defaults or only a little larger.

I'm looking at a future update in the LOGS VIEW code that would output the log data in a series of smaller data blocks.

Ah the virusprot table? Hmm, would be nice to separate them into customizable tables but good to know! :)

This change appears to make it consistent, if you wanted it to be:
rc.initial:
/bin/sh -c $1
change to
/bin/sh -c "$1"

Hi,

Using a USB adapter is much better but I still experience crash from time to time (~ weelky). I found a procedure to compile the Realtek driver for FreeBSD (https://gist.github.com/jovimon/524e116471f249626fd2ccd141f3fe05), everything went as expected and I resumed using the ETH NICs however my PFSense keeps crashing (at least daily).

I also tried the official guide but keep getting the same results (https://docs.netgate.com/pfsense/en/latest/hardware/tuning-and-troubleshooting-network-cards.html#tuning-and-troubleshooting-network-cards).

Looking at the logs I was able to see an issue with the darkstat module so uninstalled it, but still experiencing daily crashes...
At this point I still don't know whether it is hardware related or software/setup related.0_1552440129045_PFsense crash March2019.zip

Please find attached the latest crash dump logs, any suggestions or help would be greatly appreciated!
Thanks

Thanks, I nailed it and endup with a script that does what I want, without the risk of running multiple instances in parallel.

Thanks @KOM and @Grimson

Looks like I can get so much more rather then wasting energy just to get traffic graphs.

I was googling, but I was asking the wrong question :)

Old news, check the forums before you do useless posts: https://forum.netgate.com/topic/140693/backup-restore-php-error