Suricata 2.0.4 pkg v2.1 Update – Release Notes
-
Any update on PPPoE support?
ThxPPPoE support within Suricata on FreeBSD really needs to come from upstream. Have you posted a bug report to the Suricata Redmine site here: https://redmine.openinfosecfoundation.org/projects/suricata?
Bill
-
Any update on PPPoE support?
ThxPPPoE support within Suricata on FreeBSD really needs to come from upstream. Have you posted a bug report to the Suricata Redmine site here: https://redmine.openinfosecfoundation.org/projects/suricata?
Bill
I will.
Thanks Bill. -
Can't get suricata to start after updating to this version. Tried rebooting, but still no go. Logs aren't helpful, since they don't show any failure. Anyone else having any problems with it?
EDIT: Well that's new. This showed up eventually in the logs:
kernel: pid 28879 (suricata), uid 0: exited on signal 4 (core dumped)EDIT2: Forgot to say that I tested this on i386. Not tested yet on AMD64. Tested uninstalling the package/reinstalling, rebooting, starting by services/interface tab.
EDIT3: Something else that struck me as odd:
Global settings tab> "Live Rule Swap on Update" is NOT checked.
Here's all that's logged in suricata.log:
25/12/2014 – 03:11:24 - <notice>-- This is Suricata version 2.0.4 RELEASE
25/12/2014 -- 03:11:24 - <info>-- CPUs/cores online: 2
25/12/2014 -- 03:11:24 - <info>-- Live rule reloads enabledYes I know it's Christmas. Yes I know it's 03:11am. But notice the live rules reloads enabled. Never payed any attention to it to be honest, until now that it's the last line that gets logged before suricata fails to start. Either the explanation to the global settings checkbox is incorrect, or I checked a checkbox elsewhere but fail to see it (since my brain is basically functioning at 10% of its normal capacity right now) or something isn't going as planned.
Off for a pass-out session, err… sleep.</info></info></notice>
-
@jflsakfja:
Can't get suricata to start after updating to this version. Tried rebooting, but still no go. Logs aren't helpful, since they don't show any failure. Anyone else having any problems with it?
EDIT: Well that's new. This showed up eventually in the logs:
kernel: pid 28879 (suricata), uid 0: exited on signal 4 (core dumped)EDIT2: Forgot to say that I tested this on i386. Not tested yet on AMD64. Tested uninstalling the package/reinstalling, rebooting, starting by services/interface tab.
EDIT3: Something else that struck me as odd:
Global settings tab> "Live Rule Swap on Update" is NOT checked.
Here's all that's logged in suricata.log:
25/12/2014 – 03:11:24 - <notice>-- This is Suricata version 2.0.4 RELEASE
25/12/2014 -- 03:11:24 - <info>-- CPUs/cores online: 2
25/12/2014 -- 03:11:24 - <info>-- Live rule reloads enabledYes I know it's Christmas. Yes I know it's 03:11am. But notice the live rules reloads enabled. Never payed any attention to it to be honest, until now that it's the last line that gets logged before suricata fails to start. Either the explanation to the global settings checkbox is incorrect, or I checked a checkbox elsewhere but fail to see it (since my brain is basically functioning at 10% of its normal capacity right now) or something isn't going as planned.
Off for a pass-out session, err… sleep.</info></info></notice>
Are you running on VMs? Also run this from the command line and post back the output –
suricata --build-infoP.S. – the Live Rule Reloads message is just info showing it is compiled into the binary. It should not be relevant to your core dump issue.
Bill
-
Not running on VMs, running on bare metal. Here's the output:
$ suricata --build-info This is Suricata version 2.0.4 RELEASE Features: IPFW PCAP_SET_BUFF LIBPCAP_VERSION_MAJOR=1 HAVE_PACKET_FANOUT LIBNET1.1 HAVE_HTP_URI_NORMALIZE_HOOK PCRE_JIT HAVE_NSS HAVE_LIBJANSSON SIMD support: SSE_3 Atomic intrisics: none 32-bits, Little-endian architecture GCC version 4.2.2 20070831 prerelease [FreeBSD], C version 199901 compiled with -fstack-protector compiled with _FORTIFY_SOURCE=2 L1 cache line size (CLS)=64 compiled with LibHTP v0.5.15, linked against LibHTP v0.5.15 Suricata Configuration: AF_PACKET support: no PF_RING support: no NFQueue support: no NFLOG support: no IPFW support: yes DAG enabled: no Napatech enabled: no Unix socket enabled: yes Detection enabled: yes libnss support: yes libnspr support: yes libjansson support: yes Prelude support: no PCRE jit: yes LUA support: no libluajit: no libgeoip: yes Non-bundled htp: no Old barnyard2 support: no CUDA enabled: no Suricatasc install: no Unit tests enabled: no Debug output enabled: no Debug validation enabled: no Profiling enabled: no Profiling locks enabled: no Coccinelle / spatch: no Generic build parameters: Installation prefix (--prefix): /usr/pbi/suricata-i386 Configuration directory (--sysconfdir): /usr/pbi/suricata-i386/etc/suricata/ Log directory (--localstatedir) : /var/log/suricata/ Host: i386-portbld-freebsd8.3 GCC binary: cc GCC Protect enabled: yes GCC march native enabled: yes GCC Profile enabled: no -
@jflsakfja:
Not running on VMs, running on bare metal. Here's the output:
$ suricata --build-info This is Suricata version 2.0.4 RELEASE Features: IPFW PCAP_SET_BUFF LIBPCAP_VERSION_MAJOR=1 HAVE_PACKET_FANOUT LIBNET1.1 HAVE_HTP_URI_NORMALIZE_HOOK PCRE_JIT HAVE_NSS HAVE_LIBJANSSON SIMD support: SSE_3 Atomic intrisics: none 32-bits, Little-endian architecture GCC version 4.2.2 20070831 prerelease [FreeBSD], C version 199901 compiled with -fstack-protector compiled with _FORTIFY_SOURCE=2 L1 cache line size (CLS)=64 compiled with LibHTP v0.5.15, linked against LibHTP v0.5.15 Suricata Configuration: AF_PACKET support: no PF_RING support: no NFQueue support: no NFLOG support: no IPFW support: yes DAG enabled: no Napatech enabled: no Unix socket enabled: yes Detection enabled: yes libnss support: yes libnspr support: yes libjansson support: yes Prelude support: no PCRE jit: yes LUA support: no libluajit: no libgeoip: yes Non-bundled htp: no Old barnyard2 support: no CUDA enabled: no Suricatasc install: no Unit tests enabled: no Debug output enabled: no Debug validation enabled: no Profiling enabled: no Profiling locks enabled: no Coccinelle / spatch: no Generic build parameters: Installation prefix (--prefix): /usr/pbi/suricata-i386 Configuration directory (--sysconfdir): /usr/pbi/suricata-i386/etc/suricata/ Log directory (--localstatedir) : /var/log/suricata/ Host: i386-portbld-freebsd8.3 GCC binary: cc GCC Protect enabled: yes GCC march native enabled: yes GCC Profile enabled: noIf you are willing to help troubleshoot a bit, do this and report back –
1. Save the current config so it can be restored later after tests below.
2. Disable all selected rules for an interface (go to CATEGORIES tab and click Unselect All and then Save.).
3. Now try to start the interface and see if it still core dumps. The idea is to see if rules are the problem or something else is going on.
4. If it starts with no rules, try slowly adding some categories back to see if one breaks it.
Report back any suspicious findings along with the system and suricata log entries around the event.
One other question – is your bare metal an Intel or AMD CPU, and which particular model? I'm wondering if this compiler directive is potentially the problem --
GCC march native enabled: yes… it has caused me some issues on virtual machines. When enabled, the directive tells the compiler to optimize the code for the native instruction set and architecture of the CPU on the compiling machine. That's fine if you compile and use the code on the same machine. It's a potential problem if your hardware does not match up well with the hardware of the pfSense Packages Repository builder machine.
Thanks,
Bill -
Sorry for the late response. Fever and computers don't mix.
Disabled all categories, suricata still refusing to start up. Nothing changed in the logs, just the 3 lines posted previously are shown.
This suricata is running on an intel p4 CPU. Who was the guy arguing that you need an i3 to ran suricata again?
EDIT: still the same with pkg version 2.1.2
-
@jflsakfja:
Sorry for the late response. Fever and computers don't mix.
Disabled all categories, suricata still refusing to start up. Nothing changed in the logs, just the 3 lines posted previously are shown.
This suricata is running on an intel p4 CPU. Who was the guy arguing that you need an i3 to ran suricata again?
EDIT: still the same with pkg version 2.1.2
OK, that sort of confirms my suspicion that it is one of the compiler directives at fault. Or more specifically, it's the missing directive to disable a CPU auto-detect feature in the newer versions of the gcc compiler. I'm pretty sure that was included with the 2.0.3 build, but it's not in the 2.0.4 build. I will have to see about getting the pfSense developers to try building a PBI with that disable directive included.
The fact you are trying a P4 is possibly the issue (due to this compiler optimization flag I've been talking about, not the fact a P4 is not enough iron). Just for grins and giggles, do you have an i3, i5 or i7 box to test with? This CPU feature in the compiler detects the CPU in the compiling machine and optimizes the produced machine code for that particular CPU architecture. Since the pfSense PBI package builder servers are not running P4s, the resulting PBI package might include instructions that exists in the architecture of the builder CPU but well may not exist in your P4. I've seen that in my test setup where I compile on a VM on a Xeon host, but then attempt to run the resulting PBI on a VM hosted on an older i7 box. I get an immediate core dump on an illegal instruction. When I compile with that directive I'm talking about disabled, then I have no issues.
Bill
-
Why not diasble it completely?? and spare the fuss??
-
Why not diasble it completely?? and spare the fuss??
In this particular case, I think it "slipped through the cracks". This is something that has to be set within the Makefile used to compile the binary. The goal for binary-dependent packages within pfSense is to track the code base in FreeBSD ports as closely as possible and not have lots of customizations. Such customizations can have negative consequences when there are updates from upstream, but customizations make incorporating them into the pfSense build a ton of work. So we are trying to remove as many as possible from the pfSense package binaries. The only customization at present for the Snort and Suricata packages is the blocking module that works with the pf firewall.
The native Suricata port in the FreeBSD Ports tree does not have the "disable" directive set. It uses the automatic CPU detection feature of the compiler in order to generate optimized machine code for the particular platform you compile and run it on. However, the pfSense package builder case is special because the builders generate PBIs that are expected to run across a small multitude of CPU types (Intel, AMD, 32-bit, 64-bit, P4, Xeon, i7, etc.).
I will work with the pfSense crew to see if we can get the "–disable-gccmarch-native" directive set and then a new set of PBIs built for Suricata.
Bill
-
i3s belong in the "no-no"* category, so no testing for them.
- the flawed "if it aint broken don't fix it/production"**
** machines that are not in use in The Company, but installed by The Company for clients***
*** if those machines were ours, they would be long broken by now ;D
If we can't get a build working on those p4s, then a hardware upgrade is due. I know what it takes to support old/rarely used hardware/software, so I'm not adding to that if I can help it. Besides, I already got 5 years out of a €100 box (including the 2x dual pci-x intels), what else could I ask for? Oh yea, a pair of them in CARP ;D
If only supermicro stopped pushing out motherboards (guess what motherboards those p4s are running on)… This http://www.supermicro.com.tw/products/motherboard/Atom/X10/A1SRM-LN7F-2758.cfm makes me want to shout "shut up and take my money already!"
Since I always work using "the worst case scenario", I'll start planning for the upgrade soon.
- the flawed "if it aint broken don't fix it/production"**
