Refactor pcap file deletion to use a single delete-when-done option
with three values instead of separate boolean options:
- false (default): No deletion
- true: Always delete files
- "non-alerts": Delete only files with no alerts
Also account for alerts produced by pseudo packets (flow timeout / shutdown flush):
- Introduce small capture hooks and invoke on pseudo-packet creation so the
capture layer can retain references and observe alerts emitted after the last
live packet
- Call the hook from both TmThreadDisableReceiveThreads and TmThreadDrainPacketThreads
Key changes:
- Replace should_delete/delete_non_alerts_only bools with enum
- Move alert counter from global to per-file PcapFileFileVars
- Relocate alert counting from PacketAlertFinalize to pcap module
- Ensure thread safety for both single and continuous pcap modes
- Add unit tests for configuration parsing and pseudo-packet alert path
The --pcap-file-delete command line option overrides YAML config
and forces "always delete" mode for backward compatibility.
Documentation updated to reflect the new three-value configuration.
Fixes OISF#7786
The Rust build in rust.yml was just an AlmaLinux 9 build with some extra
checks. Instead, use an existing AlmaLinux 9 build in builds.yml, make
it use Rustup (there are other AlmaLinux 9 builds that use the RPM), and
add the checks.
Saves us one build in CI.
This should cause the following warning to error out:
runmode-pfring.c: In function 'OldParsePfringConfig':
runmode-pfring.c:118:17: error: implicit declaration of function 'StringParseUnt16'; did you mean 'StringParseInt16'? [-Wimplicit-function-declaration]
118 | if (StringParseUnt16(&pfconf->threads, 10, 0, threadsstr) < 0) {
| ^~~~~~~~~~~~~~~~
| StringParseInt16
Ticket: #8271
Bindgen the Rust bindings to the C JsonBuilder API along with the rest
of the Rust bindings to C. Breaking it out was probably the wrong
idea.
This should make it easier, and more correct to bindgen C functions
that use SCJsonBuilder types.
It's not possible to use all the functions and macros from the ffi crate
in the main Suricata crate, as there are conditionals around when
running in test mode, and "cargo test" doesn't propagate the "cfg(test)"
to test crates.
Which for now means duplicating the macros and some functions.
A plugin can now create a "Plugin" struct with Rust strings. The
`into_raw` method converts it to a raw pointer suitable for returning
during plugin registration.
Mostly a copy of Suricata core's logging wrappers into the ffi crate.
These are not yet used by Suricata-core as they do require the
Suricata library to be available, which is not the case with tests. And
the `cfg(test)` parameter is not passed through to sub-crates.
However, this does allow a plugin (or library) to call the logging
macros without depending on the "suricata" crate.
Ticket: #7666
This crate is for Rust wrappers around the -sys crate which includes
only raw bindings. This is the place to add nice wrappers around those
bindings, however it should remain clear of dependencies on the main
Suricata core crates.
Ticket: #7666
There is an unfortunate side-affect that one has to read
output-eve-bindgen.h for the documentation on this type, however, I
think we can resolve that in time.
As output-eve-bindgen.h exists to support bindgen, its odd to see
other Suricata C files using it. Instead Suricata C code should import
"output-eve.h", which itself includes "output-eve-bindgen.h", only
broken out to support the external tool bindgen.
Adding the directory "install" to EXTRA_DIST, actually triggers make
to run "make install", which is not what we want. Instead, avoid this
magic keyword and list the files in the install directory
individually.
If the user doesn't have permission to install files to the prefix,
like "/usr", then "make dist" can fail. Worse, even they do have
permission to write into the prefix, a "make dist" will install files
there when it shouldn't.
Ticket: #8279
Replace duplicated SCFree() calls in error paths with a single
cleanup label using goto pattern. This reduces code duplication
and ensures consistent resource cleanup.
Additional improvements:
- Fix misleading error message when xstats table size changes
between calls (was passing positive value to rte_strerror)
- Use unsigned int for length/index to match DPDK API semantics
- Initialize xstats_names to NULL at declaration for safe cleanup
- Added "not supported" case when the first call to xstats_get returns 0
Ticket: 8273
... to account for midstream sessions.
Commit 497394e removed inspection of app-proto txs for packets
without an established TCP connection. But this meant that the
first packet seen in a session pick mid-stream could go without
inspection (previous bug 5510 seemed to point towards this behavior,
too).
If a flow has more packets, the stream will be inspected as part of
the upcoming packets and this would go unnoticed. In a single-packet
flow, however, the inspection for the packed would be skipped. Although
this might not affect alerts -- as they could be processed as part of
the flow timeout logic, the actual traffic could be evaded in IPS, in
case of a drop rule.
From the above, the most visible scenario is when there is only one packet on the flow,
as then the engine doesn't have "more time" to pick-up real-packets to
inspect for that given flow. But certain tests show that this can also
happen for more than one packet scenarios: there will be one less drop
event, or traffic from a packet that should have been already dropped
will be logged.
This led to the possibility of a real packet not being blocked, in IPS,
or matched against rules, as the corresponding portion of the stream
was only inspected later, as part of the stream/flow-timeout logic.
To ensure that we correctly flag the first packet seen for a given mid-stream
session, we must check for the session state and existance *after* we
have dealt with TCP flags and state.
Related to
Bug #5510
As part of
Bug #5180
During initialization, the engine reports how many rules were loaded, as
well as which types. Pkt-only or stream-pkt rules would cause a "hole"
in such stats, as they're not counted.
Previously we were boxing a u8 and returning it as a pointer to a
boolean. While this is probably not an issue itself, the value 2 was
allowed to be converted to a boolean, which is undefined behavior in
Rust.
