[Oisf-users] issues with 2.1- beta3

[Russell Fulton]

> On 11/02/2015, at 2:20 am, Peter Manev <petermanev at gmail.com> wrote:
> 
>> 
>> to syslog:
>> 
>> Feb 10 14:23:39 secmontst01 suricata: 10/2/2015 -- 14:23:39 - <Notice> - This is Suricata version 2.1beta3 RELEASE
>> Feb 10 14:23:47 secmontst01 suricata: 10/2/2015 -- 14:23:47 - <Warning> - [ERRCODE: SC_ERR_EVENT_ENGINE(210)] - can't suppress sid 2006435, gid 1: unknown rule
>> Feb 10 14:23:48 secmontst01 suricata: 10/2/2015 -- 14:23:48 - <Notice> - all 16 packet processing threads, 4 management threads initialized, engine started.
>> 
> 
> I see a normal star up process here - "engine started" (except for the
> sid 2006435 not loading for some reason of course)

That is expected.  At the moment I have one threshold.config which I share between all my sensors.  Since I run different rulesets on different sensors there are entries in threshold.conf for rules that are not loaded. Customising the file for each sensor would be painful so I put up with the messages ;)

Ah! when starting without -D it seems I need -v to get detail logs written to syslog??  This printed errors relating to pcap capture (new feature for me ;) disabling pcap capture makes things behave as expected.

The issue with the pcap was that the path to the capture dir is screwed up??  Oh, I see it is relative — even it you specify an absolute path!

OK, removing the prefix from the path fixes things and we appear to be flying and whats more we have pcap files :)

Possible issues:

1/  I am puzzled as to why I got no errors (or any detailed logging) to syslog until I added -v on the command line when starting without -D.

logging:
  default-log-level: notice
...
  - syslog:
      enabled: yes  # +++                                                                                                                                                 
      facility: local5
      format: "[%i] <%%d> -- "   # +++                                                                                                                                     
2/ having the pcap writing fail silently stopped suri from processing packets.
3/ when processing filename parameters it might be a good idea to check for leading / and either issue a warning or treat it as an absolute path.

Russell



> 
> How do you mean "hangs"? Not inspecting traffic, are the logs being
> populated/counters increased?

Suri clocks up CPU but only very slowly as if it isnt seeing any traffic which is born out by the stats.   What is really odd is that I need -9 to kill it?

top shows:

19514 sensors   20   0 3408m 2.2g 1.2g S  103  6.9   1135:47 Suricata-Main                                                                                                           
2978 sensors   20   0 2479m 1.7g  504 S   58  5.3  60064:41 argus                                                                                                                   


it has modest usage on two cpus.