Strange log entry after update
-
Hi,
I get this when Snort is updating:
"\tFailed to extract a rules-update archive. Some snort rules might still be out-of-date. Make sure there is enough free disk space and try again. Tar file:/tmp/snort_rules_up/snortrules-snapshot-29190.tar.gz\n Installation of Snort Subscriber rules completed."
but all rules are correctly up to date! (and there is plenty of free disk space)
Confused,
fireodo -
That message comes via a return code from the
execsystem call to theuntarbinary when unpacking the rules tarball. It expects a zero value to indicate success. Perhaps for some reason the function on your box is returning something non-zero. Typically the error is from not having enough disk space, especially on a RAM disk setup.Be aware that even when the rules update fails, Snort always cleans up behind itself. So looking at available free disk space AFTER the rules update job does not tell you anything about the state of space DURING the rules update job. You want at least 256 MB of free space, and perhaps more if you a number of enabled rule sets.
-
@bmeeks said in Strange log entry after update:
ypically the error is from not having enough disk space, especially on a RAM disk setup.
Strange - I dont have a RAM-Disk setup, the free Disk Space is about 9,8GB ... RAM is 8GB
(In the past I have the "signal 10/11" exits now this strange error - I guess my machine is the Snort fright
) -
@fireodo said in Strange log entry after update:
@bmeeks said in Strange log entry after update:
ypically the error is from not having enough disk space, especially on a RAM disk setup.
Strange - I dont have a RAM-Disk setup, the free Disk Space is about 9,8GB ... RAM is 8GB
(In the past I have the "signal 10/11" exits now this strange error - I guess my machine is the Snort fright
)Signal 10 is a bus alignment fault. That has only happened on ARM hardware in the past. What type of pfSense hardware do you have? Is it a Netgate appliance, and if so, is it an SG-1000 or an SG-3100? The Signal 10 faults only happened on 32-bit ARM hardware, and the SG-1000 and SG-3100 are the only two 32-bit ARM platforms Netgate has to my knowledge.
-
@bmeeks said in Strange log entry after update:
What type of pfSense hardware do you have?
Its Intel hardware (see signature) now and was AMD in the past (APU2).
We had a long discussion concerning that and the conclusion was that it must be something special in my environment that is causing that. So I have to live with it ... and as far everything is working like expected ... its OK.Nice Weekend,
fireodo -
@fireodo said in Strange log entry after update:
@bmeeks said in Strange log entry after update:
What type of pfSense hardware do you have?
Its Intel hardware (see signature) now and was AMD in the past (APU2).
We had a long discussion concerning that and the conclusion was that it must be something special in my environment that is causing that. So I have to live with it ... and as far everything is working like expected ... its OK.Nice Weekend,
fireodoSignal 10 on Intel/AMD hardware is very unusual. On ARM hardware, especially the 32-bit stuff, not uncommon. But on Intel/AMD it is exceedingly rare. That error means a program tried to access memory across a non-word aligned boundary. But what makes that unusual is the default for Intel/AMD processors is for the CPU to automatically fix-up that access by turning it into a series of sequential memory accesses and then bit-shifting the result to produce the correct value. That setting might be customizable, though in the CPU using its control registers. Never checked on that capability in the Intel chips. I know the ARM chips have a control register to enable or disable that feature on a limited basis.
-
I started a reinstall of Snort and in the log I found this line - maybe that has something to do with the untar command returning something non zero:
"Installing Snort Subscriber ruleset...tar: so_rules/precompiled/FreeBSD-12/x86-64/2.9.19.0: Not found in archive"
and now tons of (with diverse SIDs):
Encoded Rule Plugin SID: 58807, GID: 3 not registered properly. Disabling this rule.
Encoded Rule Plugin SID: 54601, GID: 3 not registered properly. Disabling this rule.
etc...(Disabling IPS Policy makes this entries disappearing - obviously this error is IPS Policy related)
-
@fireodo said in Strange log entry after update:
I started a reinstall of Snort and in the log I found this line - maybe that has something to do with the untar command returning something non zero:
"Installing Snort Subscriber ruleset...tar: so_rules/precompiled/FreeBSD-12/x86-64/2.9.19.0: Not found in archive"
and now tons of (with diverse SIDs):
Encoded Rule Plugin SID: 58807, GID: 3 not registered properly. Disabling this rule.
Encoded Rule Plugin SID: 54601, GID: 3 not registered properly. Disabling this rule.
etc...(Disabling IPS Policy makes this entries disappearing - obviously this error is IPS Policy related)
Well, I know where that error is coming from. It may not be correctable. I will have to investigate.
The Shared Object (SO) rules are precompiled binary modules. They are actually written in the C programming language and compiled like a binary executable. They are compiled for a particular version of FreeBSD and a few other operating systems. Since pfSense is now up to FreeBSD 12.3 STABLE, it is possible there are no SO modules compatible with the new FreeBSD version.
Update: I don't see an easy fix for this until pfSense moves to the FreeBSD 13 branch. The only precompiled SO rules in the new Snort rules package are compiled for FreeBSD 13. I will investigate to see if changing the rules update process in the Snort package to work around this is possible.
-
@bmeeks said in Strange log entry after update:
Well, I know where that error is coming from. It may not be correctable. I will have to investigate.
Aha, good to know its not something specifically for my system ...
The Shared Object (SO) rules are precompiled binary modules. They are actually written in the C programming language and compiled like a binary executable. They are compiled for a particular version of FreeBSD and a few other operating systems. Since pfSense is now up to FreeBSD 12.3 STABLE, it is possible there are no SO modules compatible with the new FreeBSD version.
Thats what I also thought but I am no specialist ...
As I investigated I found this error "Failed to extract a rules-update archive." began early at begin of the month of march 2022 (the last update without error was 25.02.2022 and the first with error was 02.03.2022)
My update to pfsense 2.6.0 was on 14.02.2022. -
@fireodo said in Strange log entry after update:
As I investigated I found this error "Failed to extract a rules-update archive." began early at begin of the month of march 2022 (the last update without error was 25.02.2022 and the first with error was 02.03.2022)
My update to pfsense 2.6.0 was on 14.02.2022.That's probably when they changed the directory name in the rules tarball from FreeBSD 12 to FreeBSD 13. It's named "FreeBSD-13" now. I'm testing some solutions.
-
@bmeeks said in Strange log entry after update:
It's named "FreeBSD-13" now
Hope the rules are not compiled only for FreeBSD 13 ...
I'm testing some solutions.
Oh, many thanks!
-
I've created a Redmine Issue to track this: https://redmine.pfsense.org/issues/12979. I assigned it to myself. I'm working on the fix and will submit a Pull Request for the pfSense to review and merge in the very near future. Thank you for the report.
-
@bmeeks said in Strange log entry after update:
Thank you for the report.
You're welcome - and thank you for your work!
Kind regards,
fireodo -
I have posted a Pull Request to the pfSense Packages GitHub repo to address this issue. Here is a link to the request: https://github.com/pfsense/FreeBSD-ports/pull/1149. I've sent the pfSense developer team an email asking for an expedited review and merge.
-
@bmeeks said in Strange log entry after update:
I have posted a Pull Request to the pfSense Packages GitHub repo to address this issue. Here is a link to the request: https://github.com/pfsense/FreeBSD-ports/pull/1149. I've sent the pfSense developer team an email asking for an expedited review and merge.
Thank you!
PS. I can confirm it works! :-) -
The fix for the issue reported in this thread has been merged into Snort package version 4.1.5_2. This build should show up in the 2.6.0 CE and pfSense Plus 22.01 package repos as an available update shortly. The new version will appear in the DEVEL tree after the next snapshot rebuild happens there (likely overnight).
-
Hi Bill,
the error returned this morning but I can see any directory name change in the recent snapshot archive snortrules-snapshot-29190.tar.gz (like the FreeBSD-13 change). Needles to say that I dont have change anything in Snort since the last update and there is plenty of free disk space (df -h = zroot/tmp zfs 9.8G 396K 9.8G 0% /tmp).
"[Snort] Failed to extract a rules-update archive. Some snort rules might still be out-of-date. Make sure there is enough free disk space and try again. Tar file:/tmp/snort_rules_up/snortrules-snapshot-29190.tar.gz"
Is there a possibility to start a update with more detailed log output to see whats the real problem? Because this error message is identic whit the one when the Snort Team has changed the denomination of the directory (FreeBSD-12 -> FreeBSD-13).Kind regards,
fireodo -
Hello,
Does anybody else can confirm this?
("[Snort] Failed to extract a rules-update archive. Some snort rules might still be out-of-date. Make sure there is enough free disk space and try again. Tar file:/tmp/snort_rules_up/snortrules-snapshot-29190.tar.gz")Thanks,
fireodo -
@fireodo said in Strange log entry after update:
Hello,
Does anybody else can confirm this?
("[Snort] Failed to extract a rules-update archive. Some snort rules might still be out-of-date. Make sure there is enough free disk space and try again. Tar file:/tmp/snort_rules_up/snortrules-snapshot-29190.tar.gz")Thanks,
fireodoI confirmed it. The Snort VRT has changed part of the pathname inside the tarball. They changed
x86_64tox86-64in part of the path.Here is a quick fix while I work on submitting a Pull Request to update the package.
Use your favorite text editor for Unix and edit the following file at the lines shown. Making a backup copy of the file prior to editing is recommended!
/usr/local/pkg/snort/snort_check_for_rule_updates/phpFind lines 631 and 632 in the file. They look like this:
if(snort_untar("xzf", "{$tmpfname}/{$snort_filename}", "{$tmpfname}", "so_rules/precompiled/{$freebsd_version_so}/x86_64/{$snort_version}/")) { snort_copy("{$tmpfname}/so_rules/precompiled/{$freebsd_version_so}/x86_64/{$snort_version}/*.so", "{$snortlibdir}/snort_dynamicrules/");Change the two instances of
x86_64tox86-64(one per line) and save the change. -
@bmeeks said in Strange log entry after update:
They changed x86_64 to x86-64 in part of the path.
Oha - my bad - that I have overlooked! Thanks a lot!
