Snort won't start after upgrade to 21.02 on SG-3100
-
I've been using Snort for quite some time on my SG-3100, but after I upgraded to 21.02, the Snort service crashes immediately upon starting. I've uninstalled and re-installed the package and it made no difference. I configured another interface and it has exactly the same behavior.
The last things I see in the logs are:
Feb 18 19:21:06 hostname snort[5625]: Commencing packet processing (pid=5625)
Feb 18 19:21:13 hostname kernel: pid 5625 (snort), jid 0, uid 0: exited on signal 10Not sure what else to do at this point.
-
i am experiencing the same issue
-
Signal 10 means the executing binary attempted a non-aligned memory access. This issue is unique to the ARM processor used in the SG-3100 appliance. It is actually caused by the ARM compiler choosing to use a speedier, but not always backwards compatible, binary instruction for loading data into a CPU register.
Been through this multiple times. The issue becomes one of finger-pointing between developers of old software such as Snort and the writers of modern compilers such as
llvm
used to compile ARM machine code on FreeBSD. While the root issue is the incorrect use of unsafe type-casting by the C source code in Snort, the practical case is that every Intel CPU on the planet (all x86 and x86-64 chips) will auto-fixup non-aligned memory access and never skip a beat nor will they abort the executing code. True there is a slight speed penalty for the auto-fixup, but it's a fair trade-off when compared to just aborting the running program.The writers of the ARM compiler (and the ARM chip developers) decided to not always implement auto-fixup like Intel chips. Instead, when a piece of old C code attempts to access something in memory not on word-aligned boundaries, the ARM CPU will throw a bus error and abort the running code. While this is the "proper" thing to do, it really throws a monkey wrench in things because the same code works just fine on Intel hardware.
So where does that leave us? Stuck with a situation where certain older code (like Snort and sometimes Suricata and other popular pfSense packages) works just fine on Intel hardware but will randomly crash and burn with Signal 10 errors on the ARM hardware used in some of the Netgate appliances. Because the ARM market is so small, and the amount of work required to fix the legacy code is so large, none of the upstream maintainers (meaning the Snort folks) are really interested in investing the time to fix the old C source code. So that's it. You are basically stuck with Snort and some other packages not working correctly on ARM hardware when compiled with the
llvm
compiler tools.There was a workaround in place in the older pfSense packages repository that caused the ARM versions of Snort to be compiled with debugging enabled. This stopped the
llvm
compiler from choosing that "non-optimal" register load instruction. Perhaps that setting did not get migrated to the new 21.02 package repo compiler ??My advice, for what it's worth- either abandon Snort and Suricata on ARM hardware; or abandon the ARM hardware and run Snort and Suricata on Intel CPU platforms.
-
After the Intel Atom problems I had with my SG-2220, I "upgraded" to the SG-3100. It looks like most of Netgate's low-end line is now ARM processors at this point. While a quick glance at the product specs didn't mention Snort specifically, it did mention IDS/IPS as a supported feature.
I've been fairly unhappy with the SG-3100 as I've had an issue with it randomly rebooting for a while now. (Which seems to be somewhat common) This is really putting the nail in that coffin if ARM can't support software I'd like to have running on my gateway. I'm paying for a Snort subscription which I can't use right now and Snort rules are commonly distributed in various netdefense communities.
This is unfortunate if the ARM architectures can't really be supported then.
-
@rsm4 said in Snort won't start after upgrade to 21.02 on SG-3100:
After the Intel Atom problems I had with my SG-2220, I "upgraded" to the SG-3100. It looks like most of Netgate's low-end line is now ARM processors at this point. While a quick glance at the product specs didn't mention Snort specifically, it did mention IDS/IPS as a supported feature.
I've been fairly unhappy with the SG-3100 as I've had an issue with it randomly rebooting for a while now. (Which seems to be somewhat common) This is really putting the nail in that coffin if ARM can't support software I'd like to have running on my gateway. I'm paying for a Snort subscription which I can't use right now and Snort rules are commonly distributed in various netdefense communities.
This is unfortunate if the ARM architectures can't really be supported then.
The ARM architecture has been a bit of a bear due to this
llvm
compiler thing and non-aligned memory access. That particular bad practice (non-aligned memory accesses) is typical in a lot of older software written in C, but because Intel CPUs always just fixed it for you on the fly, nobody changed the poorly written C source code. That's why we have the problem today on ARM hardware.I personally have only used Intel hardware, and will always continue to do so for my own use. However, I am maintaining an SG-3100 at our church. But it is only a plain-vanilla firewall. There are no installed packages on it. And in the role of plain firewall, it works great.
I should also add that I do have a Netgate appliance for my own use, but it is the SG-5100 unit which is an Intel platform.
-
Thanks for the info. It's possible this is related to a current issue with the SG-3100. I've created a bug report here to keep track:
https://redmine.pfsense.org/issues/11466 -
@marcos-ng Yes it is
Feb 18 18:04:29 Scimitar kernel: pid 84003 (php), jid 0, uid 0: exited on signal 11 (core dumped) Feb 18 18:04:37 Scimitar kernel: pid 348 (php-fpm), jid 0, uid 0: exited on signal 11 (core dumped) Feb 18 18:14:07 Scimitar kernel: pid 34972 (php), jid 0, uid 0: exited on signal 11 (core dumped) Feb 18 18:23:14 Scimitar kernel: pid 357 (php-fpm), jid 0, uid 0: exited on signal 11 (core dumped) Feb 18 18:53:01 Scimitar kernel: pid 678 (php-fpm), jid 0, uid 0: exited on signal 11 (core dumped) Feb 18 18:55:08 Scimitar kernel: pid 94252 (php), jid 0, uid 0: exited on signal 11 (core dumped) Feb 18 18:57:27 Scimitar kernel: pid 357 (php-fpm), jid 0, uid 0: exited on signal 11 (core dumped) Feb 18 22:30:53 Scimitar kernel: pid 760 (php-fpm), jid 0, uid 0: exited on signal 11 (core dumped) Feb 19 09:41:30 Scimitar kernel: pid 678 (php-fpm), jid 0, uid 0: exited on signal 11 (core dumped) Feb 19 09:52:18 Scimitar kernel: pid 7881 (php), jid 0, uid 0: exited on signal 11 (core dumped)
-
@marcos-ng said in Snort won't start after upgrade to 21.02 on SG-3100:
Thanks for the info. It's possible this is related to a current issue with the SG-3100. I've created a bug report here to keep track:
https://redmine.pfsense.org/issues/11466No, not likely related. Signal 10 Bus Error aborts are caused by non-word aligned access to memory. A Signal 11 is a conventional memory segmentation fault where a program attempted to access a memory region it was not authorized to access.
I am very familiar with the Snort issue on SG-3100 and SG-1000 hardware as I debugged and identified the cause shortly after the SG-3100 was introduced. As I stated, there previously was a partial workaround in place by compiling the Snort and Suricata packages with debugging enabled to prevent the
llvm
compiler from using the specific binary instructions that do not perform auto-fixup for non-aligned access. Either that workaround has ceased to function in FreeBSD-12.2, or the package compiler switch was toggled off. I suspect it may be the former, though.P.S. -- I am the volunteer developer and maintainer for the Snort and Suricata packages on pfSense, so I know them both intimately.
-
Thank you for the input and all of the hard work! :)
It sounds like sig 10 is its own regression then, and sig 11 being the one possibly related to the issue linked on the redmine entry.
-
Just to be clear this issue affects Suricata also?
-
@teamits said in Snort won't start after upgrade to 21.02 on SG-3100:
Just to be clear this issue affects Suricata also?
Yes, it likely can. No direct reports yet, but I would not be surprised. Especially in the case of the PHP code that is causing the Signal 11 segfault in PHP. That code is identical in the two packages. And it's not really the code itself that is the problem. It's the PHP engine underneath that is crashing. The same GUI code is used in all of the pfSense images (CE and pfSense+, and for all hardware platforms such as aarch64, x86-64 and arm. So if the upper-level GUI code was faulty, you would expect it to fail on all the platforms. That's not the case. It is only failing on the ARM 32-bit platform.
-
Yeah, I saw your posts in other threads, after mine. Sure sounds like PHP. Unfortunately that presumably means it's on someone upstream to fix it which means a 21.02p2. Good sleuthing.
-
Just for some analytics on Snort and PHp crashes, I ran a Splunk query against my syslogs from the router going back 30 days to see what was logged:
2021-02-18T14:02:43.000-0500,Feb 18 14:02:43 kernel: pid 46827 (snort) uid 0: exited on signal 10 2021-02-18T14:07:54.000-0500,Feb 18 14:07:54 kernel: pid 56899 (snort) uid 0: exited on signal 10 2021-02-18T14:10:04.000-0500,Feb 18 14:10:04 kernel: pid 21583 (snort) uid 0: exited on signal 10 2021-02-18T14:13:13.000-0500,Feb 18 14:13:13 kernel: pid 78778 (php-cgi) uid 0: exited on signal 11 (core dumped) 2021-02-18T14:18:38.000-0500,Feb 18 14:18:38 kernel: pid 1154 (snort) uid 0: exited on signal 10 2021-02-18T14:23:24.000-0500,Feb 18 14:23:24 kernel: pid 75058 (snort) uid 0: exited on signal 10 2021-02-18T14:26:01.000-0500,Feb 18 14:26:01 kernel: pid 26020 (snort) uid 0: exited on signal 10 2021-02-18T14:26:30.000-0500,Feb 18 14:26:30 kernel: pid 97052 (snort) uid 0: exited on signal 10 2021-02-18T14:29:12.000-0500,Feb 18 14:29:12 kernel: pid 84487 (snort) uid 0: exited on signal 10 2021-02-18T14:53:13.000-0500,Feb 18 14:53:13 kernel: pid 63165 (snort) uid 0: exited on signal 10 2021-02-18T14:55:54.000-0500,Feb 18 14:55:54 kernel: pid 64348 (snort) uid 0: exited on signal 10 2021-02-18T15:04:04.000-0500,Feb 18 15:04:04 kernel: pid 17533 (php-fpm) uid 0: exited on signal 11 (core dumped) 2021-02-18T15:05:49.000-0500,Feb 18 15:05:49 kernel: pid 9318 (snort) uid 0: exited on signal 10 2021-02-18T15:11:43.000-0500,Feb 18 15:11:43 kernel: pid 65338 (snort) uid 0: exited on signal 10 2021-02-18T15:22:04.000-0500,Feb 18 15:22:04 kernel: pid 24027 (snort) uid 0: exited on signal 10 2021-02-18T19:21:13.000-0500,Feb 18 19:21:13 kernel: pid 5625 (snort) uid 0: exited on signal 10 2021-02-20T10:22:02.000-0500,Feb 20 10:22:02 kernel: pid 42369 (php-cgi) uid 0: exited on signal 11 (core dumped) 2021-02-20T10:24:28.000-0500,Feb 20 10:24:28 kernel: pid 74738 (snort) uid 0: exited on signal 10 2021-02-21T16:06:59.000-0500,Feb 21 16:06:59 kernel: pid 30776 (snort) uid 0: exited on signal 10 2021-02-21T16:38:27.000-0500,Feb 21 16:38:27 kernel: pid 75666 (snort) uid 0: exited on signal 10 2021-02-21T19:28:30.000-0500,Feb 21 19:28:30 kernel: pid 67353 (snort) uid 0: exited on signal 10 2021-02-21T19:43:31.000-0500,Feb 21 19:43:31 kernel: pid 86017 (snort) uid 0: exited on signal 10 2021-02-21T19:48:33.000-0500,Feb 21 19:48:33 kernel: pid 81269 (snort) uid 0: exited on signal 10 2021-02-24T01:36:24.000-0500,Feb 24 01:36:24 kernel: pid 81513 (snort) uid 0: exited on signal 11 2021-02-24T01:36:26.000-0500,Feb 24 01:36:26 kernel: pid 62078 (snort) uid 0: exited on signal 11 2021-02-25T22:28:10.000-0500,Feb 25 22:28:10 kernel: pid 78826 (php-fpm) uid 0: exited on signal 11 (core dumped) 2021-02-25T22:29:59.000-0500,Feb 25 22:29:59 kernel: pid 73568 (php-fpm) uid 0: exited on signal 11 (core dumped) 2021-02-25T22:34:50.000-0500,Feb 25 22:34:50 kernel: pid 77758 (php-fpm) uid 0: exited on signal 11 (core dumped) 2021-02-25T22:35:09.000-0500,Feb 25 22:35:09 kernel: pid 28596 (snort) uid 0: exited on signal 11 2021-02-25T22:35:11.000-0500,Feb 25 22:35:11 kernel: pid 28801 (snort) uid 0: exited on signal 11 2021-02-25T23:15:01.000-0500,Feb 25 23:15:01 kernel: pid 60474 (snort) uid 0: exited on signal 10 2021-02-26T07:15:01.000-0500,Feb 26 07:15:01 kernel: pid 32892 (snort) uid 0: exited on signal 10 2021-02-27T09:24:14.000-0500,Feb 27 09:24:14 kernel: pid 45195 (snort) uid 0: exited on signal 10 2021-02-28T10:15:01.000-0500,Feb 28 10:15:01 kernel: pid 53195 (snort) uid 0: exited on signal 10 2021-02-28T21:12:07.000-0500,Feb 28 21:12:07 kernel: pid 21339 (snort) uid 0: exited on signal 10
Feb 18 was the day I upgraded my SG-3100, so, as expected, no crashes were occurring prior to that. (I can go back further--there were no crashes in the last 180 days)
Also, it's not clear to me that the PHP and Snort crashes are related. I have a few PHP crashes and some seem coincident with Snort, but Snort definitely crashes without PHP crashing.
My SG-3100 is removed from service so now I can start Snort and it won't crash until later. Incidentally, the pfBlockerNG update will almost always cause it to crash. This could be because Snort has traffic to scan at this point. (Traffic to the WebConfigurator doesn't count? Perhaps because it is SSL?)
-
is there a fix for this in the hopper? and when should we expect it? i had to rollback to 2.4.5p1 thus i am still waiting for the fix
-
Im having the same problem aswell, SG-3100 on 21.02-p1. Snort is not visible anymore. I managed to uninstall it the package but when trying to reinstall it it just hangs on "Please wait while the update system initializes". Is it possible to revert to 2.4.5? And if so, how can I do this? It seems there is no official rollback feature that I can use to perform a rollback.
-
@styxl said in Snort won't start after upgrade to 21.02 on SG-3100:
is there a fix for this in the hopper
I'm not a dev but if the issue is with PHP then it could go all the way back to Zend to find and fix it. And then it would presumably be in a p2 patch. I'm not optimistic it will be "soon."
@rek0n I haven't done this myself but this seems like the right path:
- get a copy of the 2.4.5 installer from Netgate (go.netgate.com)
- install 2.4.5
- set to Previous Stable Version in System/Update (to install 2.4.5 packages not 2.5)
- install desired packages
- restore configuration
- double check Previous Stable Version is still set
-
@teamits It seems that since I do not have an active subscription, so I am unable to create a ticket. I tried searching ftp repositories, and discovered that there are community releases, but these seem all to be amd64. Since I have the SG-3100 that is on arm64 Im wondering where I could obtain the SG-3100 arm64 2.4.5 image..
-
There have been no news as of yet. To roll back, you may create an account and request the previous stable version. A support subscription is not required.
-
You can follow the status of the bug here: https://redmine.pfsense.org/issues/11466.
As you can see in the notes, I worked on finding the bug as far as I could go. The issue is within PHP itself, and appears limited to the 32-bit ARM processor in the SG-3100. I say this because the identically same PHP code runs without issue on 64-bit ARM hardware such as the SG-1100 and also on all Intel hardware. PHP crashing is why Snort won't start.
-
It is sad we are being forced to choose between security/stability and access. The SG-3100 is a good viable product and a lot of Small to Medium Enterprises use it. I am still surprised that Netgate is yet to patch this knowing a lot of their SG-3100 installs are using SNORT as an IPS/IDS. Personally i chose to rollback and wait until a patch is published but one of my peers decided to ditch the SG-3100 and buy an SG-5100.... unfortunately i dont have that kind of money.
-
@styxl said in Snort won't start after upgrade to 21.02 on SG-3100:
Netgate is yet to patch this
But that's the thing, if it's a PHP problem Netgate may have to wait for Zend to fix it? Zend tends to update once a month and the March 4 update just came out. Plus if it's a compilation bug and not a code bug I would think that makes it harder. And if a new PHP is included in a 21.2-p2 then Netgate would presumably need to test all of pfSense before release. (I don't have any inside knowledge of this, I'm just connecting dots.)
-
I too have run into this issue. I spent too much time trying to get this to work before coming across this post. Netgate should flag the upgrade and caution Snort users that it will break their setup. Does anyone have any idea when this will be fixed? I don't want have to pull out the SG-3100 out of my environment. I think it's a great product.
Thanks
-
Having the same issue, as I understood from the bug report it seems to be more of an PHP issue now. Too bad Netgate did not warn us before upgrading.
-
For the PHP crashes, try the patch to disable PHP PCRE JIT on #11466 Note 32.
You can install the System Patches package and then create an entry for the patch URL
https://redmine.pfsense.org/attachments/download/3707/patch-disable-pcrejit-arm.diff
to apply the fix.Then run console menu options 16 and 11 to restart PHP and the GUI, or reboot.
-
@jimp I have applied the patch and will begin testing. I use Suricata, OPENVPN, and PfBlockerNG so hopefully this fixes things and we can mark it solved.
-
This post is deleted! -
This sounds like it fixes the PHP issue, but what about the Snort issue? These are two separate problems on the SG-3100. PHP is crashing, but also, on my SG-3100, Snort starts and then Snort core dumps when it starts looking at traffic.
I applied the diff above and restarted PHP and the GUI. I no longer see the PHP errors (in the few hours since I have applied it), but I still see Snort crashing:
"Jun 12 10:21:42 sg3100 kernel: pid 92832 (snort), jid 0, uid 0: exited on signal 10"
My SG-2220 (Intel-based) of course is working fine with Snort.
-
@rsm4 said in Snort won't start after upgrade to 21.02 on SG-3100:
This sounds like it fixes the PHP issue, but what about the Snort issue? These are two separate problems on the SG-3100. PHP is crashing, but also, on my SG-3100, Snort starts and then Snort core dumps when it starts looking at traffic.
I applied the diff above and restarted PHP and the GUI. I no longer see the PHP errors (in the few hours since I have applied it), but I still see Snort crashing:
"Jun 12 10:21:42 sg3100 kernel: pid 92832 (snort), jid 0, uid 0: exited on signal 10"
My SG-2220 (Intel-based) of course is working fine with Snort.
Snort on the SG-3100 is likely never going to be 100% fixed. The Signal 10 error is due to choices made by the compiler used for 32-bit ARM processors. The compiler is choosing to use a pair of memory load/store opcodes that do not perform automatic fixup of non-aligned memory access. This happens in the Snort binary due to the way certain data structures are packed in memory and then later accessed via pointers with casting. Intel and AMD processors (along with the 64-bit ARM models) perform the auto-fixup always, and thus the memory alignment hardware bus error (Signal 10 error) is avoided with that hardware.
That means the flaky Snort binary code works fine on all Intel and AMD hardware, and lots of other 64-bit stuff as well. There is thus zero incentive for the Snort team to spend the time and energy required to refactor the Snort binary code so that it works in the edge case with 32-bit ARM hardware. Ergo, I don't see the Signal 10 errors on SG-3100 boxes ever getting fixed.
If Snort won't run for you on that hardware, either change hardware, or abandon Snort. Those are really the only two options.
-
@bmeeks said in Snort won't start after upgrade to 21.02 on SG-3100:
or abandon Snort
You’ve probably answered/posted this, but does that apply to Suricata also? That’s probably the easiest pivot and I don’t think we’ve had problems with it on 3100s.
-
@steveits said in Snort won't start after upgrade to 21.02 on SG-3100:
@bmeeks said in Snort won't start after upgrade to 21.02 on SG-3100:
or abandon Snort
You’ve probably answered/posted this, but does that apply to Suricata also? That’s probably the easiest pivot and I don’t think we’ve had problems with it on 3100s.
If Suricata starts throwing Signal 10 errors, then yes, it would be likely unfixed. The most recent PHP patch fixed (or rather worked around) another ARM 32-bit problem with the regular expression engine in PHP. That problem caused Signal 11 (segmentation fault) errors in PHP which then crashed the Suricata PHP code. Signal 10 errors are memory bus hardware errors caused by non-aligned memory access (that is, attempting to access memory locations at addresses not word-aligned).
This is just me speaking and my personal opinion, but the 32-bit ARM platform should never have happened. The compiler tools for it (in FreeBSD, at least) seem ill-suited to compiling some legacy C-code, because they choose to use CPU opcodes that do not perform auto-fixup on non-aligned memory access. There are many legacy C-code programs that do just that (attempt non-aligned memory access). True, these are technically "errors" on the part of the programmer, but as I've stated before, all Intel and AMD hardware automatically fixes these non-aligned access attempts and the binary executable just rolls along (albeit, with a very slightly reduced efficiency due to the auto-fixup). So there is really no incentive for the code to be fixed as it works just fine on all other hardware.
The 32-bit ARM hardware, though, will generate a hardware fault when non-aligned access is attempted with two of its opcodes. The thing that chaps me is every opcode executed by the ARMv7 chip in the SG-3100 will perform auto-fixup of non-aligned access save just two of them, and those two are the ones the compiler chooses to use for some memory operations unless you disable all optimizations. This is what causes the Signal 10 errors in Snort (and possibly Suricata as well). The errors in the C code are not easy to fix, because they are caused by packed data structures, and changing the "packing" very likely will have unintended consequences all over the C code. In short, it ain't an easy fix at all!
Lastly, there is another large looming problem with Suricata on ARM 32-bit applicances. The version is currently 4.1.9 and it is not going to be updated. That's because Suricata versions 5 and higher require Rust, and Rust does not exist for the 32-bit ARM platform.
The SG-3100 is a fine firewall appliance when used as just a firewall. It has problems, though, with certain packages including Snort, Suricata and possibly others. Part of the reason is the more limited RAM, but another is the quirkiness of the 32-bit ARM compiler.
-
Thanks for the info. If I understand correctly, this should be avoided with the patch at:
https://github.com/pfsense/FreeBSD-ports/blob/devel/security/snort/files/patch-pfSense-ARM317.diffHowever, I'm not entirely sure how to verify if that patch is being applied correctly or not.
@rsm4
Are you still getting the signal 10 after rebooting the firewall? -
@marcos-ng said in Snort won't start after upgrade to 21.02 on SG-3100:
@rsm4
Are you still getting the signal 10 after rebooting the firewall?Yes. I just rebooted the firewall and this is how it showed in the logs:
Jun 13 17:03:09 fw snort[96250]: Commencing packet processing (pid=96250)
Jun 13 17:03:36 fw kernel: pid 96250 (snort), jid 0, uid 0: exited on signal 10It automatically started snort on bootup and then it crashed with the signal 10 almost 30 seconds after it started processing packets.
I'm not seeing any PHP crashes since applying the patch diff, but Snort is still broken.
-
@rsm4 Suricata is also having a lot of issues I would avoid.
-
All I can't pinpoint exactly whats wrong but the packages I am having trouble with on the SG-3100 in 21.05 with the patch applied are
- suricata
- pfblockerng-dev
It seems they both stop working without much of an error message other than stopped. Unfortunately my time for troubleshooting has come to an end. And I need to return this connection to production w/o things breaking every 2 or 3 days.
I would really like some insight into what the DEVs are using to test AND what is the recommended HW for small sites. 5100 seems like overkill but we need something that is going to be supported and not dropped after 3 or so years. Juniper/cisco make great firewall only routers, I was led to believe that the SG-3100 could do more than that. But it appears thats going away.
So in small sites what is the recommended HW that devs are testing for?
-
@steveits said in Snort won't start after upgrade to 21.02 on SG-3100:
@styxl said in Snort won't start after upgrade to 21.02 on SG-3100:
is there a fix for this in the hopper
I'm not a dev but if the issue is with PHP then it could go all the way back to Zend to find and fix it. And then it would presumably be in a p2 patch. I'm not optimistic it will be "soon."
@rek0n I haven't done this myself but this seems like the right path:
- get a copy of the 2.4.5 installer from Netgate (go.netgate.com)
- install 2.4.5
- set to Previous Stable Version in System/Update (to install 2.4.5 packages not 2.5)
- install desired packages
- restore configuration
- double check Previous Stable Version is still set
We just bought 2 x SG-3100 with 21.02 how we get the stable version ?
Because snort and suricata dont work and we can't use 2 x SG-3100 without IDS/IPS in our datacenter. -
@hichem 100% honesty. If you just bought them I would return them for the sg-5100. Otherwise you will need to downgrade to 2.4.5p1 by putting a ticket to support. But netgate doesn't seem to be interested in fixing this issue... Currently we are sitting at around 5 months with one patch.
-
@hichem said in Snort won't start after upgrade to 21.02 on SG-3100:
how we get the stable version
Open a ticket per the message you quoted. There is no support contract needed to get the firmware.
@s0m3f00l said in Snort won't start after upgrade to 21.02 on SG-3100:
around 5 months with one patch
For the PHP issue you mean? They've had 21.02-p1 and 21.02.2, and 21.5. I am of the opinion it's lucky Netgate found a way to work around the PHP bug without PHP/Zend fixing it in code.
@s0m3f00l said in Snort won't start after upgrade to 21.02 on SG-3100:
what is the recommended HW for small sites
What bandwidth do you have? If it's low enough the 2100 should be OK otherwise there is a jump to the 5100.
Another option would be any x64 hardware with multiple NICs and the pfSense CE version.
-
For the PHP issue you mean? They've had 21.02-p1 and 21.02.2, and 21.5. I am of the opinion it's lucky Netgate found a way to work around the PHP bug without PHP/Zend fixing it in code.
The first patch for SG-3100 was in 21.05 I am subscribed to the bugs on redmine and I saw it rollout. But honestly I do understand that the underlying issue maybe PHP or some obscure code in the compiler. I just don't see it as my issue. The problem in truth is that I and many others need SNORT/Suricata. The PHP breaks that. I appreciate that you seem to have repaired PHP? But Suricata and Snort (after testing) still appear to be broken for about 4 months now. Even more distressing is, after testing I cannot easily rollback as the old software packages appear to have moved on at this point and the newer ones have issue on the old software.
What bandwidth do you have? If it's low enough the 2100 should be OK otherwise there is a jump to the 5100.
Bursting to 1 Gig overnight as I said in the other thread. But again I think there is miscommunication here @steveits
The real question is what HW is being developed on so I can avoid any issue like this in the future. Is it the ARM64? AMD64? ARM32? SG-5100? Third party Hardware? If you tell me what is being developed for I would be more than happy to buy it. The SG-3100 I bought in 2018 is just a firewall now. I could have gone in the USG direction if I had known that we were losing support. And deprecating the old packages so they cannot be installed. I appreciate that you are trying to help, but I do not want to have to change platforms this quickly in the future. -
@s0m3f00l Oh I understand, we have primarily sold the 3100 to clients, and have one in use ourselves. We haven't tried to upgrade any of those to 21.x yet. We've sold a few 2100s since their introduction last fall, and it would be great if there was a 4100 but that doesn't exist.
These issues are all specific to the 3100 which is a 32 bit ARM CPU. I think the discontinued SG-1000 was also 32 bit (?) but the rest are either 64 bit ARM or Intel.
The issue I think (and I'm not a dev just a customer/partner) is the 32 bit ARM CPU is not in wide usage so is basically an edge case for the people developing FreeBSD and these other projects. As bmeeks pointed out there are compiler issues which is coming from the FreeBSD developers, and if they don't dedicate time to fixing it then it's not really something Netgate can fix. The PHP bug is new and apparently tied to the JIT (just in time) precompiler for PCRE (regular expression engine), and since it's coming from Zend/PHP they need to allocate resources to test on it. Likewise the newer Suricata changed languages to Rust which no one's ported to 32 bit ARM.
The 64 bit ARM (specific to Netgate hardware) and 64 bit Intel/AMD (Netgate or third party) are all fine. If you want to look at third party hardware, FreeBSD 12.2 will have a compatibility list somewhere, but offhand I'd say Intel NICs are widely recommended here and the rest is probably not of any significant concern.
-
@steveits said in Snort won't start after upgrade to 21.02 on SG-3100:
@hichem said in Snort won't start after upgrade to 21.02 on SG-3100:
how we get the stable version
Open a ticket per the message you quoted. There is no support contract needed to get the firmware.
I find only this url : https://netgate.myfreshworks.com/login?redirect_uri=https%3A%2F%2Fnetgate.myfreshworks.com%2F
But can't create account for opening ticket.