Set pseudo packet datalink to the global one. This fixes the case
where the pcap handle is open with information coming from a
pseudo packet. Without this, we did end up in most cases with
an Ethernet packet being written in a Raw pcap.
As Suricata is not supporting pcap-ng we have to stick with one single
datalink type for the capture if ever we want to do pcap logging.
Assuming this, this patch introduces a function to set the link
type globally. This will be used with pcap conditional logging
to get the logging of TCP segments with the correct link type.
We were missing the first packet when using condition pcap logging
in tag mode as it was not tagged. As a result we were not getting
the stream data triggering the alert in the pcap file.
This patch adds a function to get the current pcap file name that
will be used to current packet. This patch also updates EVE
alerts to add pcap output filename when pcap capture is done in
multi or normal mode.
This patch update the alert mode of pcap logging.
It uses the packet header data added to the TCP segments
to build packets corresponding to the acked data that did trigger
the alert. It then write it to the pcap file before starting to
dump all packet for the flow that did alert.
This patch optionally adds packet header to the TCP segment
and update the for each segment function by changing the
callback.
This patch is based on the work by Scott Jordan <scottfgjordan@gmail.com>
When reloading rules, respect `--set default-rule-path=...` from the
command line if set.
Previously the rule reload would always take the default-rule-path from
the configuration file, even if overrided on the command line.
Issue: #1911
In the unlikely case of AlertQueueExpand failure, we were incrementing
the discarded alerts stats in AlertQueueAppend via the Packet member in the
DetectEngineThreadCtx, which may not be initialized yet.
Bug #5353
Do not mask protocols on both directions with only first packet
For instance :
When the first packet is no valid DNS but on port 53 (a junk request)
second packet (error response from server) does not get checked for DNS
as first packet bit masked away DNS for both directions
Ticket: #2757
kill(0, ...) re-raises the signal to every processes in the process
group which may impact unrelated processes.
Concretely, in our CI pipeline, a segfaulting Suricata process killed
the test driver.
Add a line to the configuration that says which version generated the
configuration file. For example:
# This configuration generated by:
# Suricata 7.0.0-dev
Issue: #4784