Commit Graph

8 Commits (4ccbcc46847e2a70d4d1bc251f3f1f751cfe7df4)

Author SHA1 Message Date
Jason Ish 44388f1b69 src: make include guards more library friendly
Include guards for libraries should use a prefix that is meaningful for
the library to avoid conflicts with other user code. For Suricata, use
SURICATA.

Additionally, remove the pattern of leading and trailing underscores as
these are reserved for the language implementation per the C and C++
standards.
2 years ago
Philippe Antoine 9af0dafbad src: fix some include orders
So as to be able to get include removal right
4 years ago
Victor Julien f6c77dcdd9 pcap/file: minor code cleanups 6 years ago
Victor Julien ae4137937e pcap/file: fix race during pcap processing start
A race condition during the start of pcap file processing could cause
missed alerts and logged events. This race happens between the packet
threads and the flow manager. It was observed on slower hardware, but in
theory could happen on any machine. It required the 'autofp' runmode.

In commit 6f560144c1 ("time: improve offline time handling") the logic
was added to make the flow manager use a minimum of all the packet threads
perception of time.

The race condition was that the flow manager may become active _before_
all of the packet threads have started processing packets and thus setting
their timestamp. The threads that had not yet initialized their timestamp
would not be considered when calculating the minimum.

As a result of this, older packets timestamps would not yet be registered.
This would give the Flow Manager a timestamp too far in the future. While
the FM was running, the packet processing would start and a flow would
be created. This flow would then immediately be considered 'timed out' by
the FM, due to the timestamp too far in the future.

In the observed case, the thread processing packet 1 from the pcap had not
yet started processing while other threads had already started. The FM was
also already active. Due to the timestamps in the pcap this meant that the
time the FM used was about 500 seconds in the future compared to packet 1.

This patch fixes the issue by initializing all of the threads timestamps
with the timestamp value of the first packet. This way the minimum will
always consider this timestamp.
6 years ago
Victor Julien 579cc9f02b const: constify decoder, app-layer, detect funcs 7 years ago
Maurizio Abba 55b14f3721 decode: set pktlen of decode handler to uint32
Change the decode handler signature to increase the size of its decode
handler, from uint16 to uint32. This is necessary to let suricata use
interfaces with mtu > 65535 (ex: lo interface has default size 65536).

It's necessary to change several primitive for Packet manipulation, to
unify the parameter "packet length" whenever we are before IP decoding.

Add tests before calling DecodeIPVX function to avoid a possible
integer overflow over the len parameter.
8 years ago
Danny Browning 2dc6b6ee14 source-pcap-file: delete when done (2417)
https://redmine.openinfosecfoundation.org/issues/2417

Add option to have pcap files deleted after they have been processed.
This option combines well with pcap file continuous and streaming
files to a directory being processed.
8 years ago
Dana Helwig 3ab9120821 source-pcap-file: Pcap Directory Mode (Feature #2222)
https://redmine.openinfosecfoundation.org/issues/2222

Pcap file mode that when passed a directory will process all files in
that directory. If --pcap-file-continuous or continuous option is passed
in json, the directory will be monitored  until the directory is
moved/deleted, suricata is interrupted, or the pcap-interrupt command
is used with unix command socket. Existing file implementation and new
directory implementation has moved from source-pcap-file into
pcap-file-helper and pcap-directory-helper.

Engine state will not reset between files.

Also satisfies:
 * https://redmine.openinfosecfoundation.org/issues/2299
 * https://redmine.openinfosecfoundation.org/issues/724
 * https://redmine.openinfosecfoundation.org/issues/1476

Co-Authors: Dana Helwig <dana.helwig@protectwise.com> and
Danny Browning <danny.browning@protectwise.com>
9 years ago