system info:
NAME=“Ubuntu”
VERSION=“20.04.5 LTS (Focal Fossa)”
suricata info:
This is Suricata version 7.0.5 RELEASE
pcap info:
flow-http.log:
But it can be played back normally
tcpreplay --intf1=p5p1 111111.pcap
From the above, we can see that /libhttp::request_uri_not_seen appears in the http flow log, and it is normal through tcpreplay
I’ve encountered this a long time ago when replaying using a multi-queue nic:
Do you get a the problem also when suri reads the original pcap directly?
It won’t happen, how can I solve this problem?
Try to reproduce it if you create a dummy0 interface in Linux, replay the traffic towards that and attach Suricata to that one. It should help to narrow it down if it’s directly related to the NIC.
How to reproduce? In my experience, 1: something wrong makes reassemble-gaps, means losted packets in app layer, that will make uri not seen. 2: multi queue lets response packet come before request, libhtp will remain a hole for request in req-res pair, to verify, replay pcap in single mode.
The problem happened again and I found out that my machine was single-queued：
suricata log:
I read the package via tcpreplay and suricata -r and the url is correct, I’m confused
@Andreas_Herz @vjulien @antsknows
Can you help me, please 
Can you reproduce it with a .pcap and when you read it via -r into Suricata?
It’s normal for me to read pcap with -r
{“timestamp”:“2024-11-06T15:10:30.899552+0800”,“flow_id”:657080548679629,“in_iface”:“p2p2”,“event_type”:“http”,“src_ip”:“192.168.94.21”,“src_port”:28699,“dest_ip”:“162.219.133.11”,“dest_port”:8008,“proto”:“TCP”,“pkt_src”:“stream (flow timeout)”,“tx_id”:0,“http”:{"http
_port":0,“url”:“/libhtp::request_uri_not_seen”,“http_content_type”:“image/jpeg”,“status”:200,“length”:5561}}
The problem reappears with a stream (flow timeout) prompt
Can you provide the pcap so we can try to reproduce it as well?
