Jason Ish [Tue, 7 Jul 2026 21:41:24 +0000 (15:41 -0600)]
tests: add smtp pipelined post-DATA regression test
Add a firewall SMTP fixture where a second MAIL FROM is sent before the
previous DATA completion reply. The checks require the second message to
be logged as a distinct transaction with its own sender and recipient.
Jason Ish [Fri, 3 Jul 2026 20:03:13 +0000 (14:03 -0600)]
tests: update very small MIME SMTP packet
This very-small-input MIME fixture still logs the same decoded message,
but the SMTP transaction event now waits for response-side completion.
The event therefore moves from packet 14 to packet 15.
Update only the tx 0 SMTP event pcap_cnt while keeping the HELO-only
timeout transaction assertion unchanged.
Jason Ish [Fri, 3 Jul 2026 20:02:59 +0000 (14:02 -0600)]
tests: update small remainder MIME SMTP packet
The small-remainder MIME input still decodes into the same SMTP
transaction fields. Because SMTP transaction logging now waits for the
server response progress to complete, the tx 0 SMTP event appears on
packet 15 instead of packet 14.
Adjust only the primary SMTP event pcap_cnt; the HELO-only timeout
transaction check stays unchanged.
Jason Ish [Fri, 3 Jul 2026 20:02:43 +0000 (14:02 -0600)]
tests: update MIME removed-space SMTP packet
The MIME parser still produces the same decoded message for this
removed-space input. With SMTP transaction completion now tied to the
response progress state, the SMTP event is emitted one packet later.
Move the tx 0 SMTP event pcap_cnt from 14 to 15 and leave the timeout
transaction check unchanged.
Jason Ish [Fri, 3 Jul 2026 20:02:30 +0000 (14:02 -0600)]
tests: update odd MIME length SMTP packet
The odd-length MIME message is decoded into the same SMTP transaction
fields, but the transaction event is delayed until the server response
completes the SMTP progress state. That moves the tx 0 SMTP event from
packet 14 to packet 15.
Keep the existing decoded-message assertions and adjust only the event
packet number.
Jason Ish [Fri, 3 Jul 2026 20:02:15 +0000 (14:02 -0600)]
tests: update short filename SMTP packet
This attachment fixture still emits the same fileinfo and decoded
filename data. After SMTP transaction completion became response-gated,
the SMTP transaction event for tx 0 is logged on packet 15 instead of
packet 14.
Update only the SMTP event pcap_cnt; the fileinfo packet and attachment
assertions remain unchanged.
Jason Ish [Fri, 3 Jul 2026 20:01:58 +0000 (14:01 -0600)]
tests: update long filename SMTP packet
The long-filename anomaly still fires on the server packet where it is
parsed, and the fileinfo event remains on packet 15. The SMTP
transaction event now also lands on packet 15 because transaction
logging waits for response-side completion after DATA.
Adjust only the SMTP event pcap_cnt for the parsed attachment
transaction, leaving the anomaly and fileinfo expectations intact.
Jason Ish [Fri, 3 Jul 2026 20:01:27 +0000 (14:01 -0600)]
tests: update MIME URL SMTP packet
The URL-bearing MIME transaction is still decoded correctly, but SMTP
transaction logging now waits for the server response completion state.
That moves the SMTP event containing email.url from packet 14 to packet
15.
Update only the transaction event pcap_cnt; the expected decoded URL and
envelope fields are unchanged.
Jason Ish [Fri, 3 Jul 2026 20:01:14 +0000 (14:01 -0600)]
tests: update MIME line SMTP packet
The SMTP transaction for this line-parsing MIME fixture is complete only
after the server response progress reaches complete. The decoded message
fields are unchanged, but the SMTP event is emitted one packet later.
Move the tx 0 SMTP event pcap_cnt from 14 to 15 and leave the timeout
HELO transaction check as-is.
Jason Ish [Fri, 3 Jul 2026 20:00:59 +0000 (14:00 -0600)]
tests: update second full MIME SMTP packet
The parsed MIME email transaction is now logged after the SMTP response
completion state is seen. In this fixture that moves the tx 0 SMTP event
from packet 14 to packet 15 without changing the parsed envelope or
email fields.
Update only the SMTP event pcap_cnt so the test reflects the new
transaction-completion timing.
Jason Ish [Fri, 3 Jul 2026 20:00:46 +0000 (14:00 -0600)]
tests: update full MIME message SMTP packet
SMTP transaction logging now waits for the response-side completion
state instead of logging when the client finishes DATA. This MIME test
still parses the same message content, but the SMTP event for tx 0 is
emitted one packet later.
Move only the SMTP transaction event pcap_cnt from 14 to 15; the
helo-only timeout transaction expectation is unchanged.
Jason Ish [Fri, 3 Jul 2026 19:51:21 +0000 (13:51 -0600)]
tests: update email subject smtp log packet
The email subject content is still detected while request DATA is
inspected on packet 13. After the SMTP progress-state change, the
transaction is not logged until the server response completes the
response-side progress, so the SMTP event with the parsed Subject header
now appears on packet 14.
Keep the alert timing assertion intact and update only the SMTP
transaction event pcap_cnt.
Jason Ish [Fri, 3 Jul 2026 19:51:02 +0000 (13:51 -0600)]
tests: update email message-id smtp log packet
The SMTP message-id rule still alerts as soon as request-side DATA
inspection completes on packet 13. With transaction completion now gated
by the later response progress state, the SMTP transaction event
containing the parsed Message-ID is logged on packet 14.
Adjust only the SMTP event pcap_cnt expectation so the test continues to
assert the split between detection timing and transaction logging.
Jason Ish [Fri, 3 Jul 2026 19:50:45 +0000 (13:50 -0600)]
tests: update email date smtp log packet
SMTP transactions now complete only after both the request and response
progress states reach complete. The date rule still alerts on packet 13
when the request data is inspected, but the SMTP event carrying the
parsed Date header is emitted on the following server response packet.
Keep the alert check at packet 13 and move only the SMTP event
expectation to packet 14.
Jason Ish [Fri, 3 Jul 2026 19:02:31 +0000 (13:02 -0600)]
tests: fix smtp test for progress changes
This test now shows the previously commented out invalid reply as we
don't complete the tx at end of client data, but instead on the server
response. And this server response at end of data is considered invalid
and is now logged as such.
Jason Ish [Fri, 3 Jul 2026 18:16:32 +0000 (12:16 -0600)]
tests: update smtp-file-data-01 for tx progress changes
The SMTP TX now completes after the server response from DATA, not when
the client sends end of data. So the pcap_cnt for this test is now 91
instead of 89.
Jason Ish [Fri, 3 Jul 2026 18:11:46 +0000 (12:11 -0600)]
tests: update smtp-file-data-02 for tx progress changes
The SMTP TX now completes after the server response from DATA, not when
the client sends end of data. So the pcap_cnt for this test is now 53
instead of 51.
detect: verify app-layer-protocol pipe-separated value list
Add suricata-verify coverage for the app-layer-protocol keyword's
pipe-separated value list and its matching behaviour:
- multi-value and negated (NOR) matching, the unknown-window idiom, and the
firewall default-policy boundary
- default AppProtoEquals() equivalences (dns matches a doh2 flow) and the
exact option (dns,exact does not match doh2; http,exact rejected at load)
- engine-analysis JSON output of the effective match set
- prefilter accepted for a single-value rule, rejected for a multi-value rule
- rejection of duplicate/overlapping negated keywords
We stop the parsing to avoid getting quadratic complexity
by having one TCP chunk creating many transactions, and the limit
being enforced only for non-complete txs while we iterate the
complete list of transactions
Jeff Lucovsky [Tue, 9 Jun 2026 14:00:49 +0000 (10:00 -0400)]
tests: add DHCP single-direction transaction tests for bug 8621
DHCP is a stateless parser where each datagram is its own standalone,
single-direction transaction. Verify that a request/reply exchange alerts
once per datagram rather than once per direction, and that directional
rules only match the transaction for their own direction.
bug-8621-01 checks a generic dhcp rule fires exactly once on the request
and once on the reply. bug-8621-02 checks a flow:to_server rule only
matches the request and a flow:to_client rule only matches the reply.
Philippe Antoine [Thu, 18 Jun 2026 11:37:46 +0000 (13:37 +0200)]
ftp: fix test for ftp.reply_received
Ticket: 8659
This test relied on the behavior that we put the parser into
error when having RETR after an invalid PASV
but we can see that every request has a response, even if the
response to the invalid RETR is
550 Failed to open file
Jeff Lucovsky [Sat, 28 Mar 2026 14:28:54 +0000 (10:28 -0400)]
test/xor: add tests for inline variable key and offset syntax
Add 15 test cases for the 'extract <nbytes> <offset>' inline variable key
syntax and the optional 'offset' parameter of the xor transform.
Positive tests:
01 - 1-byte var key at body offset 0, XOR from offset 1; 1 alert
02 - same as 01, content absent in decoded data; 0 alerts
03 - 4-byte var key at body offset 0, XOR from offset 4; 1 alert
06 - extra whitespace in offset syntax accepted; 1 alert
10 - xor preceded by content keyword on same buffer; 1 alert
12 - two rules with different var key locations both alert;
verifies independent buffer per key location
13 - var key location beyond buffer end; transform skips, 0 alerts
14 - var key on http.uri buffer; verifies transform is not limited
to http.request_body; 1 alert
15 - static key and variable key rules on the same buffer both alert;
verifies independent transforms for each key type; 2 alerts
16 - ensure that buffer is not transformed in place.
Error tests (rule load failures, exit code 1):
04 - extract 0 0 (zero nbytes)
05 - extract 1 (missing offset)
07 - offset with non-numeric value
08 - offset without comma or key
09 - offset with empty value before comma
11 - empty quoted hex key
Jason Ish [Wed, 10 Jun 2026 22:53:57 +0000 (16:53 -0600)]
ftp: add active and passive data tests
Some observations:
- On the data channel, ftpdata_command:retr matches in the to_client
direction, for passive and active.
- On the data channel, ftpdata_command:stor matches in the to_server
direction. This matches the direction of the file, but it is the
client that send the STOR request. Does this make sense?
- On the data channel, file_data matches in the direction of the TCP
connection to differs for active and passive mode. This almost seems
counter intuitive to how ftpdata_command works. But a direction is not
required here so I'm not sure it matters much to rule writers.
pcap-file-stdin: read pcap from stdin via /dev/stdin
Feed a one packet pcap into Suricata via /dev/stdin to exercise the
non-seekable file handling fix in OISF/suricata#15384 for Bug #8464.
Without the fix InitPcapFile calls setvbuf on the FILE underlying the
pcap handle after libpcap has already consumed the pcap header, glibc
cannot recover on a non-seekable fd, the first pcap_next_ex returns
-1, and no packets are decoded.
The test overrides the default invocation with a command that pipes
input.pcap into Suricata reading from /dev/stdin. The rule alerts on
a deterministic content match in the TCP payload, and the check
asserts that exactly one alert with sid 1 lands in eve. On the pre
fix code the run produces zero alerts and the test fails. On the
fixed code one alert is observed and the test passes.