Suricata

The attached .pcap-file contains a single TCP connection with 100 HTTP requests in it. The client closes TCP connection after the last one.

In order to reproduce the bug, you'll need to enable extended HTTP logging in default suricata.yaml config, and replay the attached dump like this. For some reason I was unable to reproduce it with feeding pcaps to Suricata directly or via dummy interface, though.

tcprewrite --seed=$RANDOM --fixcsum --infile 100reqs.pcap --outfile - | tcpreplay --intf1=lo -

If multiple af-packet processing threads are enabled, there's a chance that Suricata will somehow lose all HTTP responses in a connection. HTTP requests will still be handled, though.

Most of the time, http.log will contain like like these, which is expected.

06/29/2016-21:22:29.476586 localhost [**] /foo [**] <useragent unknown> [**] <no referer> [**] GET [**] HTTP/1.1 [**] 404 [**] 169 bytes [**] 93eb:ad81:93eb:ad81:93eb:ad81:93eb:ad7f:50992 -> 93eb:ad81:93eb:ad81:93eb:ad81:93eb:ad7f:80

But sometimes, Suricata will lose the responses, and http.log will contain the following:

06/29/2016-21:22:30.384542 localhost [**] /foo [**] <useragent unknown> [**] <no referer> [**] GET [**] HTTP/1.1 [**] <no status> [**] 0 bytes [**] 1703:0456:1703:0456:1703:0456:1703:0457:50992 -> 1703:0456:1703:0456:1703:0456:1703:0457:80

There's no reported packet drop on capture.
On my PC the chance of this occuring is about 1 in 50, but can happen as early as after several replays. I have 4 cores, so 4 threads are spawned, but I was able to observe this with two threads as well.