ANDwatch 2.1 in pfSense 25.11-RELEASE and RAM disk
-
Apparently the MAC Address database and run-time gathered data are stored in /var/db, but the content is never backed up/restored. Therefore, ANDwatch wont't start after reboot.
-
@pfsjap Yes, andwatch is incompatible with ram disk, as is any package that requires long term storage.
Core team is aware of the issue and is considering ways to allow packages to hook into the backup/restore process.
-
So for the time being we should uninstall/reinstall and update the database after every reboot. At least for the time being, until this is addressed?
-
@MBehr2 said in ANDwatch 2.1 in pfSense 25.11-RELEASE and RAM disk:
So for the time being we should uninstall/reinstall and update the database after every reboot. At least for the time being, until this is addressed?
See the release notes for 25.11.1:
Package System¶
- Added: Allow packages to preserve RAM disk data between boots #16624
-
@dennypage I don't know what you are trying to say, but in 25.11.1-RELEASE and with ANDwatch 2.1_1 I still have to run
mkdir /var/db/andwatch; /usr/local/bin/andwatch-update-maafter reboot before ANDwatch will start.
-
@pfsjap I don't use ramdisk myself, but ramdisk package backup is a new general feature in 25.11.1.
Please confirm that the ramdisk for ANDwatch setting is present on your system:
[25.11.1-RELEASE][root@fw]/root: grep ramdisk /usr/local/pkg/andwatch.xml <ramdisk_dir_names>andwatch</ramdisk_dir_names> [25.11.1-RELEASE][root@fw]/root:It should also appear in your config.xml:
[25.11.1-RELEASE][root@fw]/root: grep ramdisk /conf/config.xml <ramdisk_dir_names>nut</ramdisk_dir_names> <ramdisk_dir_names>vnstat</ramdisk_dir_names> <ramdisk_dir_names>andwatch</ramdisk_dir_names> [25.11.1-RELEASE][root@fw]/root: -
@dennypage Those seem to be alright:
[25.11.1-RELEASE][admin@pfSense8200.home.arpa]/root: grep ramdisk /usr/local/pkg/andwatch.xml <ramdisk_dir_names>andwatch</ramdisk_dir_names> [25.11.1-RELEASE][admin@pfSense8200.home.arpa]/root: grep ramdisk /conf/config.xml <ramdisk_dir_names>pfblockerng</ramdisk_dir_names> <ramdisk_dir_names>nut</ramdisk_dir_names> <ramdisk_dir_names>suricata</ramdisk_dir_names> <ramdisk_dir_names>andwatch</ramdisk_dir_names> [25.11.1-RELEASE][admin@pfSense8200.home.arpa]/root:but rebooted just again, and andwatchd won't start from the dashboard. Nothing in the system logs, but there's no restored database:
[25.11.1-RELEASE][admin@pfSense8200.home.arpa]/root: ls -l /var/db/andwatch ls: /var/db/andwatch: No such file or directory [25.11.1-RELEASE][admin@pfSense8200.home.arpa]/root: -
@marcosm Thoughts? Have I missed something?
-
It works for me in 26.03 but it does seem like something is wrong in 25.11.1. I'll take a look.
-
@marcosm Thank you Marcos
-
For reference:
https://redmine.pfsense.org/issues/16724The fix/patch there can be applied to 25.11.1 with the System Patches package.
-
@marcosm Fix confirmed, thank you.
-
@marcosm I'm on 25.11.1 and I updated the system_patches package, but it's not listed in the patches to apply. I already have all the recommended patches installed (Redmine #166688, #166690, #166682, #166610), but I don't see #16724. Did I miss a step to make it show up, or should I create a custom patch entry?
-
-
@dennypage Custom patches looks incredible dangerous, especially for someone who's never done one before.
I wouldn't have a clue as to what fields need to be explicitly filled, and whether it should fetch the code or I should paste it in from the Github repository.
So out of an abundance of caution, I think I'll leave well enough alone, and just recreate the ANDwatch directory and update the database manually before restarting ANDwatch.
-
@MBehr2 like so:

Full patch contents:
diff --git a/src/etc/rc.backup_packages_data.sh b/src/etc/rc.backup_packages_data.sh index e247a2759c..4f2cae122a 100644 --- a/src/etc/rc.backup_packages_data.sh +++ b/src/etc/rc.backup_packages_data.sh @@ -13,7 +13,7 @@ xml_rootobj=$(/usr/local/bin/php -n /usr/local/sbin/read_global_var xml_rootobj pfsense 2>/dev/null) path="${xml_rootobj}/installedpackages/package/ramdisk_dir_names" config=${config:-"/cf/conf/config.xml"} -DIR_NAMES=$(/usr/local/bin/xmllint --xpath "//${path}/text()" "${config}" 2>/dev/null | tr -d '\r\n' | tr -d "'*$\`\"\\") +DIR_NAMES=$(/usr/local/bin/xmllint --xpath "//${path}/text()" "${config}" 2>/dev/null | tr '\r\n' ' ' | tr -d "'*$\`\"\\") result="" for NAME in ${DIR_NAMES}; do -
@dennypage Thanks - worked like a charm, applied and tested with a reboot. All good now.
Was over thinking this and would have pasted the entire 40+ lines of code - even tho only one line changed. Yet another reason not to do what your not sure of LOL
Only difference is my Patch ID has a different hex value. I'm gathering it's because I have other patches installed and the system creates this upon install.
Again, thanks
Privacy Policy · Cookie Policy