[Oisf-users] Suricata Error on Rule Reload
Eric Urban
eurban at umn.edu
Fri May 31 20:59:39 UTC 2019
Hello again Andreas,
I got around to finally filing this one today as well :) It is still
happening after we upgraded to 4.1.4. See
https://redmine.openinfosecfoundation.org/issues/3004.
Thank you,
Eric
On Tue, Apr 30, 2019 at 3:58 PM Andreas Herz <andi at geekosphere.org> wrote:
> Hi Eric,
>
> could you track this with those details in our redmine issue tracker?
>
> And double check if it's happenning with 4.1.4 as well :)
>
> On 26/04/19 at 13:06, Eric Urban wrote:
> > We are currently testing Suricata 4.1.3. Whenever we perform a rule
> > reload, we get the error SC_ERR_PCAP_DISPATCH with an error code of -2.
> > Here is the output from suricata.log:
> >
> >
> {"timestamp":"2019-04-26T10:07:54.238852-0500","log_level":"Error","event_type":"engine","engine":{"error_code":20,"error":"SC_ERR_PCAP_DISPATCH","message":"error
> > code -2 "}}
> >
> {"timestamp":"2019-04-26T10:07:54.664296-0500","log_level":"Info","event_type":"engine","engine":{"message":"cleaning
> > up signature grouping structure... complete"}}
> >
> {"timestamp":"2019-04-26T10:07:54.665821-0500","log_level":"Notice","event_type":"engine","engine":{"message":"rule
> > reload complete"}}
> >
> > We do not get this error in 4.0.6. I am not sure at this point whether
> > this is a non-issue or if it does in fact affect alerting?
> >
> > I believe this error is coming from source-pcap.c on line 269 (
> >
> https://github.com/OISF/suricata/blob/7f38ffc8bcfa3bca793eb3be41f112634b48de2a/src/source-pcap.c#L269
> ),
> > since we aren't loading a pcap file in this case and that is mostly where
> > else this error is thrown.
> >
> > There is a pcap_dispatch call above this one (line 265) and the
> conditional
> > on line 267 to enter the trigger for this error checks that the return
> from
> > pcap_dispatch is < 0. The PCAP_ERROR_BREAK (-2) code would be handled on
> > line 272 once inside of here. There is a pcap_breakloop() call (line 226)
> > inside PcapCallbackLoop which is called on line 266, but I believe this
> may
> > be the result of the change for 4.1.3 in
> >
> https://github.com/OISF/suricata/commit/bb26e6216e5190d841529c0ecb1292b9a358ed54#diff-2079412a59d37868318fc953aeddef52
> > where
> > ReceivePcapBreakLoop was created for PktAcqBreakLoop. So possibly in
> > tm-threads.c at
> >
> https://github.com/OISF/suricata/blob/d6903e70c1b653984ca95f8808755efbc6a9ece4/src/tm-threads.c#L1610
> > ?
> >
> > Does this seem right or am I on the wrong track? If that is how the
> error
> > occurs, then I believe we would be losing a half second (at least) of
> > traffic visibility due to the reconnect on line 277 of source-pcap.c.
> >
> > I am curious if anyone else using pcap capture method running 4.1.3 or
> > other versions has experienced this?
> >
> > --
> > Eric Urban
> > University Information Security | Office of Information Technology |
> > it.umn.edu
> > University of Minnesota | umn.edu
> > eurban at umn.edu
>
> > _______________________________________________
> > Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
> > Site: http://suricata-ids.org | Support:
> http://suricata-ids.org/support/
> > List:
> https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
> >
> > Conference: https://suricon.net
> > Trainings: https://suricata-ids.org/training/
>
>
> --
> Andreas Herz
> _______________________________________________
> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
> Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/
> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>
> Conference: https://suricon.net
> Trainings: https://suricata-ids.org/training/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20190531/31439c12/attachment-0001.html>
More information about the Oisf-users
mailing list