@networknotwork This one : /conf/config.xml

@mako pfSense (Firewall won't do it) But maybe a Proxy like squid would - (I think squid is installable on pfSense) /Bingo

@alroute said in 3rd Party Hardware Request: I'm guessing Netgate doesn't want to price the 2100 down at home user prices because it might lose small business revenue and the same for access points which I'm guessing are universal to all. Perhaps you can't simply make it any cheaper without loosing money? Because all electronics prices have gone through the roof and nothing got cheaper at all? There's a reason why consumer/SOHO electronics is cheap, while more flexible hardware and software is not. That's not something to do with "they don't want to make it cheaper" or "they don't like their software running on toasters". It's just that no one wants to pay for that. You can't just throw the software on cheap SOHO hardware and hope it will work just because "it's also an ARM SOC/CPU". There are vastly different ARM SOCs and they have licenses etc. for accessing their tools and drivers etc. Why is Netgate running espressobin-like hardware on those SG1100-3100? Because it's mostly the same SOC and was (guessing) relatively easy to adapt FreeBSDs ARM branch on it. We can see how "identical normal x86/64 hardware" runs every day. They aren't the same just because they may have the same NIC and CPU in it. Developing on different hardware is far more complex than "just throw it on and have a look at it". Otherwise one could simple extract the installer from e.g. a SG1100 and throw it on a Raspi4 (won't work - different ARM SOC) or on a smartphone perhaps? Those are ARM, too? Nope. Not that easy. And the menhours that go into such things as developing and testing on new hardware is what makes things time consuming and expensive to ensure the stuff is actually running quite nicely when you try to install/update it. Add to that, that many hardware vendors for WiFi, SOCs (Quallcom for ARM etc.) like to have "binary blobs" in their drivers that may only work on Linux or have problems to get them to run on FreeBSD - or even incompatible licenses to BSD/Apache Licenses? Those are just the problems on top of it. Have you seen 08/15 SOHO hardware with more then 1-2y firmware support? I found them very rare. Mostly the have have a few updates and are then abandoned for the next bigger better version. Also because of ever evolving HW standards of WiFi and such, most SOHO routers tend to get switched out around 2ys. Firewall hardware normally lasts way longer than that in my experience in our company (not Netgate BTW). @alroute said in 3rd Party Hardware Request: I noted from the Netgate Website that youa re intending to provide support for Pfsense to be used on 3rd party routers. Actually don't know where you found that. I only know of "supporting 3rd party hardware" and with that they are only talking about compatible (x64 Intel/amd) 3rd party hardware router boxes or barebones that you can buy/build yourself. I found nowhere they state, that they plan to run on 3rd party routers as an alternative firmware like OpenWRT or DD-WRT or Tomato. That's - AFAIK - far outside the project scope. Cheers \jens

looks good thanks.

@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.