@viktor_g

After several attempts, it worked...very strange. I had to uninstall and reinstall, and then voila, it worked.

There is no way to downgrade in-place. You would have to reinstall the older version and restore a configuration made on the previous release as well.

@luckman212
Thanks,
I fixed the issue with what @stephenw10 posted

@jegr Never used the backup or filer packages although I've always been vaguely aware of them. Somehow I thought they were unmaintained for years and broken on recent versions of pfSense but I guess that's wrong. I'll check it out (as soon as pkg is fixed 😳 )

@luckman212 Ah we had something similar with a SG-5100 that also utilized the eMMC and had it as primary boot. Every time our coworker installed the new image, it still booted the old one until he finally realized he was booting the eMMC every time but installing on the SSD 😁

But good point about the nuking of the mmcsd0 partition. Will bookmark that to remember it when dealing with such a case again. Thanks 😄

Huh, now that someone mentions it... YES. That would definetly save some time with setting up a restore or similar box without having to edit the complete config.xml to do a full restore. Great idea!

I made a simple script to check if patches are applicable from the console. It's completely non-destructive (checks only).

GitHub gist: ptest.sh

Get

save to your box with fetch -o /root/ptest.sh https://gist.githubusercontent.com/luckman212/f58329c5c0e98d38154bcab910783f30/raw/48b82380572fb70de314bb463c279457077506c4/ptest.sh make executable: chmod +x /root/ptest.sh

Run

./ptest.sh [-r] <commit-hash>

Sample output

[22.01-DEVELOPMENT][root@pfSense.home.arpa]/root: ./ptest 332052b8bd2a5d35662be2dba773b7a9f0d50681 commit: https://github.com/pfsense/pfsense/commit/332052b8bd2a5d35662be2dba773b7a9f0d50681 subject: Static routes handling update. Fixes #11599 #11895 #7547 result: patch CAN be cleanly applied

Steve,
Thanks for the advice. Patch seems to work, pcscd is no longer running.

It's not that significant a concern, so nobody has taken the time to clean them all up. They should probably be removed for consistency, but it's not a priority.

If anyone wants to test the package, you can try this script below.
Place it in /usr/local/etc/rc.d, change mode to 0755, disable PowerD in the System / Advanced / Miscellaneous
reboot the system and wait for 5 min, check dashboard for current CPU frequency and temperature.

#!/bin/sh case "$1" in start) #safety timer 3min sleep 180 logger "Check powerd++ status" #check no pkg jobs currently running CHECKPKG=$(pgrep pkg) while [ "$CHECKPKG" != "" ]; do sleep 60 CHECKPKG=$(pgrep pkg) done #check powerd++ installed or not, if not going to install it, if yes going to start CHECKPOWERDXX=$(pkg info powerdxx | grep Categories) && CHECKPKG=$(pgrep pkg) if [ "$CHECKPOWERDXX" != "Categories : sysutils" ] && [ "$CHECKPKG" = "" ]; then /bin/rm -f -r /usr/local/etc/pkg/repos_ && /bin/mv -f /usr/local/etc/pkg/repos /usr/local/etc/pkg/repos_ && /usr/local/sbin/pkg install -f -y powerdxx && /bin/mv -f /usr/local/etc/pkg/repos_ /usr/local/etc/pkg/repos && /bin/rm -f -r /usr/local/etc/pkg/repos_ && sleep 60 logger "PowerDxx reinstalled, started!"; else logger "NORMAL start: powerd++ exists!"; fi # starting powerd++, if this does not work, try "powerdxx -a adp" powerdxx -H 55:65 -t dev.cpu.0.temperature ;; stop) ;; esac exit 0

Packages on pfSense generally offer a GUI component for managing their configuration. Usually the GUI configuration piece is accessed via a menu entry under SERVICES put there by the package when it is installed from the pfSense packages repo (available under SYSTEM > PACKAGE MANGER.

If you mean you installed a package directly from the CLI from a package repo that is not part of the official pfSense distro, then you can be on your own. In that case, the package is unlikely to be manageable from pfSense itself. You would need to resort to manually editing any config files the package might have installed in /usr/local/etc (or more rarely, in /etc).

@pandafy said in Stray commented line in pfsense/src/etc/inc/openvpn.inc:

From looking at the commit which made this change, this seems like it was commented out purposefully back then. Should I open a PR to remove those lines?

That would be fine, I'd say being commented out for over 11 years means we really don't need to keep them hanging around.

Hello @gertjan!

Thank you very much for clearing out my doubts.
This was troubling me for quite a while that why there's a restriction in changing management interface.

Even after adding management 127.0.0.1 7505 directive using Custom Options, the OpenVPN instance on pfSense always used a UNIX socket. (It opens a UNIX socket with IP address as name)

Because ..... that is the way how the Dashboard Server VPN widget 'scans' the OpenVPN server so it can update the dashboard info about a current connections.

This is the crucial information I was missing. I will check the documentation again to confirm if it is already mentioned there. If not, I will open an issue/pull request to add this.

But now, I want to take a dive into the implementation of the "scan client" feature and would like to investigate why usage of TCP ports has been ruled out completely.

It will be really helpful if you can provide links to related code or documentation which can give me a starting point.

Again, thanks a lot. :)

@jimp Thank you, new thread is here

It does appear to be a similar case to exit notify for point-to-point modes.

In "sever" mode (SSL/TLS with a tunnel network larger than /30) it considers Inactive to only apply to client sessions and not the server itself.

In point-to-point mode (client or server are ambiguous to OpenVPN) it terminates the process on inactivity.

https://redmine.pfsense.org/issues/12219

@jimp said in 2.5.2-release still has OpenVPN Site2Site Bug with explicit-exit-notify:

In the meantime, you can always use the Service Watchdog package to restart the service when it has stopped.

Ah didn't think of that. Normally I'm more "solve the problem, don't restart" type of engineer but you're right, if the other side is "wrongdoing" and there's nothing we can do - so be it :/