Your use case doesn't align with the intended use case of the package, and limiting it in the way you describe would also limit its usefulness for others. My point is that it's not necessary to run the watchdog package in nearly all cases. If you feel that the watchdog package is necessary there is almost certainly something else wrong with your setup that is making it appear like it's what you want, when it likely is masking the real problem. The watchdog package is unlikely to gain additional features due to the fact that it really shouldn't exist at all, and is only a workaround for other bugs people have hit over the years.

Hmm, probably better to report in that thread then whilst we try to pin this down. Steve

@stephenw10 said in When pfSense CE reaches Netgate TAC end of support will a pfSense+ ISO be available to download?: I couldn't tell you what the situation will be by the end of year but I anticipate there may be changes to meet subscribers requirements as those become clear. Fair enough that answers my question. I will just wait and see what happens later on. Netgate does have good informational blog posts etc so I assume if/when a pfSense+ ISO for x86_64 hardware becomes available Netgate will let us know. Thank you for the help.

I think the mount entries is processed according to the order. So the tmpfs mounted at /var at a lower position masks (or overlay) the zfs /var/log. The system is actually using tmpfs for the whole /var.

@lhatroch see https://docs.netgate.com/pfsense/en/latest/firewall/aliases.html#bulk-import-network-aliases just copy-paste a list of IPs to the Aliases to import field: [image: 1645013551446-screenshot-from-2022-02-16-15-12-24.png]

They were able to re-forward the token e-mail to me and I have it all set and updated to the plus version. Thanks for your help!

@viktor_g Yea, I fixed that error with a patch here... https://forum.netgate.com/topic/169869/there-were-errors-loading-rules-solved-and-patched/7 The problem was the continuous emails every 20 to 30 seconds. The fix for me was to uninstall mailreports, disable SMTP notifications under "System -> Advanced -> Notifications" and reboot. Uninstalling and disabling wasn't enough, the emails kept going, a reboot is required following the disable and uninstall. After the reboot the emails stopped. I then enabled SMTP notifications and a couple emails came through but not continuously. Later I then reinstalled mailreports and everything seemed to be normal and continues to look normal as I'm not getting blasted with the same error in my emails. Keep in mind that prior to disabling and uninstalling I had already done a couple reboots. First reboot was after the upgrade Second reboot was to try to get the emails to stop Third reboot was after disabling SMTP notifications and removing mailreports. I wanted to at least post it on the forums that this had happened in case others ended up with the same issue as it could be a potential upgrade bug, but time will tell and now if others have the same problem they know what I did to get the emails to stop and return to normal.

Generally if you're hitting that it's because something is rapidly filling the logs causing them to rotate/compress so check the logs are not full of errors. Steve

All, Succeeding some further investigation the issue at hand seems to be due and related to the Gateway Monitoring Deamon requiring some modest adjustment in configuration parameters. I cannot say with categorical certainty it was due to the upgrade from 2.5.2 to 2.6, but surely did become evident in succession the upgrade. That said, some additional configuration changes were made to the router configuration thereafter as well, so perhaps something changed unintentionally. One thing to note: If you have your WAN and LAN ports both running over one Ethernet port using VLANs (as I do), then it is important to assure that a drop of the WAN IP address does not cause the port to get shutdown as this could make it very difficult to access. That said, nothing prevents access to the router from the console. Thus, the issue can now be declared resolved. Stuart

As a home user not really. You can always reinstall 2.6 if you really want to. Steve

@stephenw10 said in Is there a command to view current cpu clock speed?: How did it show those things enabled? The second output is after enabling it? In the BIOS? powerd relies on some driver to actually control the cpu speed, est(4) for Intel CPUs. And that relies on either hard coded values or, far more commonly, values passed to it by ACPI. It's not unusual for those to be wrong or missing unfortunately. Steve No both outputs are taken right after one another it shows the proc jumping all around to different clock speeds as the processor sees fit. My guess is the usage of hwpstate_intel is what allows the different visibility into the two different operating systems. https://www.freebsd.org/cgi/man.cgi?query=hwpstate_intel&apropos=0&sektion=4&manpath=FreeBSD+13-current&arch=default&format=html

Because 12 divides by 1,2,3,4 and 6 but not 5.

@jimp that's what I meant :) Thank you !

@jimfreeze An IDS package like Snort or Suricata has rules that can look for things like SSH attempts or other web requests. There isn't a great way to block specific URLs but maybe you can write your own rules if you're really familiar with doing so. I would read up on implementing it in the forum here before jumping in, and not block by default for a while until you can observe what alerts are being triggered.

Hi! I cant describe how it happends.. its. long time ago... . Thanks.. this fixed it also for me! ""Remove empty rule <rule></rule> from <outbound>" in the config file."

@sergei_shablovsky hint.sc.0.flags should be "0x0080" for VESA, not "0x180", per the man page here: https://www.freebsd.org/cgi/man.cgi?query=sc&sektion=4 So for mode 279 (1024x768x16), in /boot/device.hints it should be hint.sc.0.at="isa" hint.sc.0.flags="0x0080" hint.sc.0.vesa_mode="0x117" and in /boot/loader.conf make sure you have kern.vty=sc

Unable to connect to some random sites like that is usually either an MTU issue or a bad subnet mask somewhere. Since you're unable to ping or even reach the first hop in a traceroute it's unlikely to be MTU so check the routing table for some bad route. Steve

Yes, it's only 5.2 that is no longer supported upstream and was removed. The expected behaviour is that the package would simply be removed at upgrade. But that is not the case currently. So if you have zabbix_agent52 installed it should be removed before upgrading until we get a fix in. Steve