Suricata

Hello OISF,

We would like to submit a bug report for some odd behavior we have observed with suricata `7.0.8`. To reproduce this bug we went through these steps. First, we setup two interfaces on a linux host, `SFE_0_IN`, and `SFE_0_OUT`. Then we compiled and set up suricata `7.0.8` to run in `af-packet` mode.

When playing the `example.pcap` (attached) with `tcpreplay` on an interface going into suricata, we saw that we sent 38 packets.

ahp % sudo /usr/local/bin/tcpreplay -i SFE_0_IN /home/ahp/attached.pcap
Actual: 38 packets (24607 bytes) sent in 3.11 seconds
Rated: 7894.6 Bps, 0.063 Mbps, 12.19 pps
Flows: 4 flows, 1.28 fps, 38 unique flow packets, 0 unique non-flow packets
Statistics for network device: SFE_0_IN
        Successful packets:        38
        Failed packets:            0
        Truncated packets:         0
        Retried packets (ENOBUFS): 0
        Retried packets (EAGAIN):  0

When we listened on the interface on the other side, we also received 38 packets, definitively showing Suricata did not drop anything -

ahp % sudo tcpdump -i SFE_0_OUT -vvv -w capture_large_header.pcap
tcpdump: listening on SFE_0_OUT, link-type EN10MB (Ethernet), capture size 262144 bytes
^C38 packets captured
38 packets received by filter
0 packets dropped by kernel

We used the following rule, but `any HOME_NET -> EXTERNAL_NET` example would work. The IPs used below were set up in namespaces on the host prior to the test:

drop http 18.180.192.156 any -> 172.31.10.37 any (app-layer-event:http.request_field_too_long; flow:established; msg:"HTTP Dropped - Request too long"; priority:1; sid:2; gid:10000012; rev:1;)

We received the HTTP drop log in the to_client direction, which matches the ones from the repros below.

{
  "timestamp": "2025-12-31T17:58:42.131695+0000",
  "flow_id": 130255501212787,
  "in_iface": "SFE_0_IN",
  "event_type": "alert",
  "src_ip": "18.180.192.156",
  "src_port": 80,
  "dest_ip": "172.31.10.37",
  "dest_port": 50764,
  "proto": "TCP",
  "pkt_src": "stream (flow timeout)",
  "tx_id": 0,
  "alert": {
    "action": "blocked",
    "gid": 10000012,
    "signature_id": 2,
    "rev": 1,
    "signature": "HTTP Dropped - Request too long",
    "category": "",
    "severity": 1
  },
  "http": {
    "http_port": 0,
    "url": "/index.html",
    "http_user_agent": "curl/8.3.0",
    "http_method": "GET",
    "protocol": "HTTP/1.1",
    "length": 0
  },
  "app_proto": "http",
  "direction": "to_client",
  "flow": {
    "pkts_toserver": 19,
    "pkts_toclient": 9,
    "bytes_toserver": 21419,
    "bytes_toclient": 1087,
    "start": "2025-12-31T17:58:24.423543+0000",
    "src_ip": "172.31.10.37",
    "dest_ip": "18.180.192.156",
    "src_port": 50764,
    "dest_port": 80
  }
}

We checked timestamps on the pcap and the log and believe that this log is logging the psuedo-packet that Suricata uses to close the connection because the log comes after the connection closes, which would explain why the pkt_src is "stream (flow timeout)".

Would you all mind looking into this?