[Oisf-users] issues with 2.1- beta3

[Peter Manev]

On Mon, Feb 16, 2015 at 11:05 PM, Russell Fulton
<r.fulton at auckland.ac.nz> wrote:
> Peter
>
> No wonder you are confused — because I am.
>
> A promised I went and did some more systematic testing and found that everything actually works in a straight forward consistent manner (surprise) — the problem was between the chair and the keyboard.
>
> Some how I had the idea that I was getting the detailed startup messages dumped to syslog with just -D.  No, one needs -v whether or not you have -D.  This became apparent as soon as I tried to ‘document’ what was happening.
>
> In future I will refrain from posting late in the afternoon immediately before going home!

:)
m glad you figured it out

>
> Russell
>
>
>> On 16/02/2015, at 10:47 pm, Peter Manev <petermanev at gmail.com> wrote:
>>
>> On Tue, Feb 10, 2015 at 11:40 PM, Russell Fulton
>> <r.fulton at auckland.ac.nz> wrote:
>>>
>>>> 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.
>>>
>>
>> So what you are saying is that you have diff logging "level" when you
>> are using -D (without -v), correct?
>>
>> Makes things as expected - how?What is expected ( sorry might be
>> misunderstanding the point)
>>
>>
>>> 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.
>>
>> I think if it is an ERR it should be there - regardless if it is used
>> with or without the -v option.
>>
>>>
>>> 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?
>>>
>>
>> Is Suri seeing/inspecting traffic in this case?
>>
>>> 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.
>>
>>
>> thanks
>>
>>
>> --
>> Regards,
>> Peter Manev
>



-- 
Regards,
Peter Manev