Suricata

I believe bug #1433 can still be observed as of recent Suricata version.

The attached .pcap-file contains a HTTP session with two request-response pairs.
The conversation goes as follows:

• (omitted)
• Client: ACK for previous response, (request)
• Server: ACK, (response)
• Server: FIN, ACK -- the server initiates TCP close as soon as response it sent, which is actually somewhat rare in HTTP
• Client: FIN, ACK
• Server: ACK

I've cloned both Suricata and libhtp directly from Git, and can reliably reproduce it.

In order to do this, 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 2reqs.pcap --outfile - | tcpreplay --intf1=lo -

Additionally, you should lower af-packet thread count to one to avoid another possible bug where both responses will be lost. I'll report that one once I have reliable test case for it (unless it's actually the same bug as this one).

06/29/2016-20:50:01.383552 localhost [**] /foo [**] <useragent unknown> [**] <no referer> [**] GET [**] HTTP/1.1 [**] 404 [**] 169 bytes [**] 382b:8f6c:382b:8f6c:382b:8f6c:382b:8f6d:43762 -> 382b:8f6c:382b:8f6c:382b:8f6c:382b:8f6d:80
06/29/2016-20:50:01.394696 localhost [**] /foo [**] <useragent unknown> [**] <no referer> [**] GET [**] HTTP/1.1 [**] <no status> [**] 0 bytes [**] 382b:8f6c:382b:8f6c:382b:8f6c:382b:8f6d:43762 -> 382b:8f6c:382b:8f6c:382b:8f6c:382b:8f6d:80

Notice that Suricata is missing the response. There's no status and no response body size for the second request.