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 :/

@jimp thanks jim

Normally you would not edit files in that way on the firewall directly.

Many of us work in one of the following ways:

Edit remotely by loading and saving over ssh or scp which is supported by many popular editors Edit a file in a local copy of the Git repository and then copy the edited file to the firewall by scp Edit a file in a local copy of the Git repository and then load the file in Diagnostics > Edit File and paste the new content Making minor/simple on the firewall directly changes using vi, ee, or Diagnostics > Edit File without extra steps

Thanks for the hint!

@gabacho4 said in Way to track outstanding issues with 21.05 development for testing and verification?:

@jegr this the reason I apologized in advance! 😁 Thanks for steering me too the right place.

No offense taken :) It just happened I got the same question in the german subforum so knew where to link to right away ;)

@Gertjan

That can be seconds, minutes, or even days later.
The date and time of the error is known : 16-May-2021 18:27:29

While the date is known, as presented by the given error, it doesn't present why this condition was given. For instance a long string or invalid string char or possibly mem exceeded error.

I still missunder stood the question ? That can happen. Do you have more information ?

It seems that way. I was asking how to proceed to report the bug, contrary to received a work around on how to do something that anyone with basic system knowledge can accomplished.

You asked for it : a part of the diagnose is : you issued a command that had more then 500 Mbytes of text output.
Look at the line 174 of that file : the output of the command you entered is redirected in a file, and the quantity of that output overflows 500+ Mbytes.
PHP goes belly up.

Thanks, this is very helpful and what I was looking for. An explanation of what cause a mem exhaustion is what I was looking for.

There is no way of knowing how many bytes a (unknown) shell command produces upfront. So there is no safety net.

Is it possible to check mem utilization and recycle the input to it? Or, perhaps, create a dynamic mem allocation instead of statically assigned?
Unfortunately, PHP is not exactly my cup of tea.

Actually : there is one :

fd6e67a7-54cd-4357-9df0-84b464eda1e0-image.png

😊

As amusing this might look, this is not exactly a checkpoint.
The heading won't prevent the form from crashing!! 😖
Define advance user!!

True.
A GUI type of interface will never totally replace the usage of a command line interface.
The console access (or SSH access) always exist, for that reason.
Mac OS still has one, as Windows 10.

Totally in agreement 1000%.

Btw : what did you do on that "Diagnostics > Command Prompt" ?

That is the million $$ question. The CLI is used instead of the diag page.
Is there a way to trace back the commands ran on the given date?

I'm not a Netgate employee or a pfSense coder, just a pfSense user like you.

Understood!

Thank you for all the info provided.

Bump!