After attempting to manually start vnstatd, you can check its status using the following command: service vnstatd status You should ensure that the configuration file for vnstatd is correctly set up. You can find the configuration file at /usr/local/etc/rc.d/vnstatd. See if any parameters or settings that might have changed in the new version. If your system uses systemd, there might be conflicts between the init system and systemd. Ensure that vnstatd is configured to work correctly with your init system. Even though you haven't found anything in the General logs, it's worth checking other logs such as /var/log/messages for any potential vnstatd-related issues.

@JonathanLee I am running 2.7.2-RELEASE and everything is the latest.

Thank you for doing this important research Fabricio. I apologize if I have misspelled your name. Please connect with me. I have information that can help both of us.

@heartk What shell are you running ? If its /bin/csh if ends with an endif

That one is not plus specific, the commit referenced there is showing on Github.

@stephenw10 I was reading the firmware for this card can also be updated at one point.

Is any news about enabling QUIC in pfSense CE at the end of 2023? Because around 90% of traffic in the world come to/from mobile gadgets, but we still using old congestion protocols in pfSense (even QUIC available in FreeBSD in that pfSense based, since several years…)

@Patch said in Download development snapshot: @bmeeks Seems to be fixed now as the binaries for the last few days are all different with relevant targeted changes. I checked out the latest 10-31-2023 image at the link you shared. It installs and appears to run fine, but you can't install any packages nor update any existing installed ones. I believe public access is shut down for now as the team is in the middle of merging some base updates from FreeBSD 14 into the 2.8 CE DEVEL snapshot branch. I also guess that effort has taken a bit of a back seat of late as it's probably "all hands on deck" prepping the 23.09 Plus release. Once pfSense Plus 23.09 releases, I expect activity to resume on the 2.8 CE snapshot branch.

Yeah, while hex editing on a binary can work every now and then, one problem I foresee in this particular case is that the PPPOE_CONNECT_TIMEOUT constant is defined once but then will possibly be used in a several places in the code. Finding all of those would be a tedious exercise. Edit the wrong 0x09 value somewhere and you would create a potentially serious bug.

@SteveITS I know it is not recommended, so I won't ask for help for my particular problem challenge. :) However, I have to manage lots of systems with different OS's, and I like to minimize the number of packages I manage them with. Luckily, except for this one, all other packages I use are in the pfSense repo.

@jimp said in another os: Like others have said, Netgate does our best to support hardware for as long as possible. My SG-2440 is a good example of this. It perfect sitting in the closet as a cold backup if needed right now. Following is my opinion: As for the OP question, if it's out of warranty, add non-eMMC storage reinstall the latest using ZFS and use it as a cold/warm backup.

@Patch I'll definitely be looking at example configs pulled from manually-configured pfsense installs, and refining what I need to include in the config.xml. The point of what I'm doing is to fully-automate the pfsense installation, like described here in the docs by providing the installer a config.xml file to apply. This config.xml will be different for different installations on different machines, so I must generate it programatically, which is why I'm asking about the xml schema and/or other config generation tools.

@michmoor said in Patches update: Yep. Sorry if that wasnt clear. I am doing full MITM. Np, I was just trying to understand :) @michmoor said in Patches update: If you rely only on the internal redirect then pfsense points back to itself on the management port (firewall.example.com:443) . The problem of course is that in order to serve the page you must make your management port accessible to all LAN clients. That means making management accessible to all LAN clients. The only workaround is to use an external webserver that has php code on it to interrupt whats being sent to it from pfsense Now I see what you meant, yes, indeed that would be a problem.. Using an external server for that solves this problem.

That error has only been reported one other time that I am aware of, and it turned out to be a corrupted alerts.log file if I recall correctly. That error is saying that a value read from the alerts.log was NULL, but there is no way that can happen unless the file is corrupt. One possibility is a disk read or write error. When you go to the ALERTS tab, can you display all the alerts from all Suricata configured interfaces without any problem? The exact same code is used within the ALERTS tab and Suricata Wiget, so a corrupt file would impact both. It's also possible that the error happened some time back in the past and by now the alerts.log has been rotated out and the current file may be fine. Does the error repeat every single time the widget updates, or has it only popped up once? Normally, issues with Snort or Suricata would be posted here: https://forum.netgate.com/category/53/ids-ips.

@bmeeks said in new package / best practices: I think the /usr/local/etc/rc.d/ path is currently hard-coded into the parts of pfSense that start packages at boot or when executing a "restart all packages" command. I do not believe it will find a script in /etc/rc.d/. Of course, sorry, I meant /usr/local/etc/rc.d/crowdsec and crowdsec_firewall. Meaning I don't need to wrap them from another script. They are supposed to work in vanilla freebsd after all. I can just enable them in /usr/local/etc/rc.conf.d/* I'm tagging @jimp in this thread. He is a Netgate developer and may have some helpful input. Great, thanks

@fabricioguzzy said in Compiling from Source - Problems with "php-pfSense-module": @bmeeks Hi Bill, Thanks for the heads up. I have created a ticket --> Issue #14593 on redmine. Hopefully it will be fixed. Did you open a ticket for the pfsense-repoc ? I have noticed that it points to an internal Netgate URL, so it's impossible to compile it. Thanks Much, Fabricio. No, I had not gotten around to submmitting a ticket. This issue with pointing to the internal Gitlab URL has happened with other packages in the past, and it eventually sorted itself out. Was just still waiting to see if it would get updated when I saw your post about it.