async-oneside: test behavior with async-oneside

Ticket: 8269

Since we know the flow is async, we should not wait for the
responses and queue txs, but just process them asap.

diff --git a/tests/bug-8629-async-oneside/README.md b/tests/bug-8629-async-oneside/README.md
new file mode 100644 (file)
index 0000000..638036a
--- /dev/null
+++ b/tests/bug-8629-async-oneside/README.md
@@ -0,0 +1,22 @@
+# Description
+
+Regression test for issue 8629: SMB transactions must not be allowed to grow
+without bound on asynchronous (one-sided) flows.
+
+When Suricata only ever sees one direction of a flow, SMB requests wait forever
+for responses that never arrive. Once the transaction list passes `smb.max-tx`
+the parser stops trying to handle this gracefully and instead raises the
+`too_many_transactions` event and returns an error, which puts the flow's
+app-layer parser into an error state and stops further SMB processing.
+
+The test lowers `smb.max-tx` so the small capture reaches the limit, and checks
+that SMB is parsed up to that point, that the event is raised, and that the flow
+is put into an error state (`app_layer.error.smb.parser`).
+
+# PCAP
+
+A single SMB2/DCERPC session derived from the `dcerpc-smb-test-01` capture,
+reduced to the client->server direction only so it is a genuine one-sided
+capture. It begins with a SYN followed by an ACK from the same host, which is
+how the engine detects an asynchronous stream, so `stream.async-oneside` is
+enabled.

diff --git a/tests/bug-8629-async-oneside/input.pcap b/tests/bug-8629-async-oneside/input.pcap
new file mode 100644 (file)
index 0000000..31b8ee6
Binary files /dev/null and b/tests/bug-8629-async-oneside/input.pcap differ

diff --git a/tests/bug-8629-async-oneside/test.yaml b/tests/bug-8629-async-oneside/test.yaml
new file mode 100644 (file)
index 0000000..cfb2135
--- /dev/null
+++ b/tests/bug-8629-async-oneside/test.yaml
@@ -0,0 +1,34 @@
+requires:
+  min-version: 8.0.6
+
+# One-sided (asynchronous) SMB capture: only the client->server direction is
+# present, as with asymmetric routing or a one-sided tap. Requests pile up
+# waiting for responses that are never seen. When the transaction list passes
+# smb.max-tx the parser puts the flow into an error state instead of trying to
+# handle it gracefully (issue 8629). max-tx is lowered so a small capture
+# reaches the limit.
+args:
+- -k none
+- --set stream.async-oneside=true
+- --set app-layer.protocols.smb.max-tx=3
+
+checks:
+  # SMB is parsed completely
+  - filter:
+      count: 1
+      match:
+        event_type: smb
+        smb.command: SMB2_COMMAND_SESSION_LOGOFF
+
+  # No max-tx anomaly
+  - filter:
+      count: 0
+      match:
+        event_type: anomaly
+
+  # The flow is not in error state
+  - filter:
+      count: 1
+      match:
+        event_type: stats
+        stats.app_layer.error.smb.parser: 0