Bug #708

Flow vars issue in pcap file mode

Added by Eric Leblond almost 7 years ago. Updated 4 months ago.

Target version:
Affected Versions:


The following signatures should allow to detect non HTTP traffic on port 80:

alert http any any -> any any (msg: "Set flag_http"; \
flowbits: set, flag_http;\
noalert; \
sid:6; rev:1;)
alert tcp any any -> any 80 (msg: "Increment flag"; \
flowint: cnt, +, 1; \
flowbits: isnotset, flag_http; \
noalert; \
sid: 7; rev:1;)
alert tcp any any -> any 80 (msg: "Non HTTP on port 80"; \
flowint: cnt, >, 5; \
flowbits: isnotset, flag_http; \
flowbits: set, flag_http;\
sid: 8; rev:1;)

On some systems (FC14 dual core) this is not working correctly with alert firing for both attached files.
This should not alert:

suricata -S not-http-port-80.rules -r 80-http.pcap

This should alert once:

suricata -S not-http-port-80.rules -r 80-no-http.pcap

On the faulty systems, switching to runmode single by adding --runmode=single on command line fixes the issue.


80-http.pcap (244 KB) 80-http.pcap Eric Leblond, 01/12/2013 05:14 AM
80-no-http.pcap (1.04 KB) 80-no-http.pcap Eric Leblond, 01/12/2013 05:14 AM
not-http-port-80.rules (405 Bytes) not-http-port-80.rules Eric Leblond, 01/12/2013 05:14 AM



Updated by Anoop Saldanha almost 7 years ago

  • Assignee set to Anoop Saldanha

Updated by Anoop Saldanha almost 7 years ago

would the above set of rules work? As in sig 7 will be run for every packet heading in the port 80 direction, which means all the syn retransmissions as well, which is why you are seeing alerts for 80-http.pcap as well. You can see a fair bit of FPs.

Unable to reproduce the single vs autofp thing you are noticing. See an alert. I have an update to the engine, which might be a fix, but single vs autofp in this case should virtually be the same thing. Let me check in some detail next.

On an unrelated note, we should probably support

alert !<protocol> ....

which should be more reliable.


Updated by Anoop Saldanha almost 7 years ago

unable to reproduce single vs autofp thing.

Btw, a feature update patch related to the code corresponding to the bug(but not related to the bug itself).


Updated by Victor Julien about 6 years ago

  • Target version set to TBD

Updated by Andreas Herz about 3 years ago

I can reproduce it but in the first case I receive

6/9/2016 -- 23:57:31 - <Warning> - [ERRCODE: SC_ERR_INVALID_CHECKSUM(11)] - 1/1th of packets have an invalid checksum, consider setting pcap-file.checksum-checks variable to no or use '-k none' option on command line.

So when I start it with "-k none" the alert won't trigger. So still a bug or working as expected in that case?


Updated by Andreas Herz about 3 years ago

  • Assignee changed from Anoop Saldanha to OISF Dev

Updated by Victor Julien over 1 year ago

Without -k none the stream engine rejects the packets and packets are inspected differently. In the normal case they are inspected after reassembly, so a bit later.


Updated by Andreas Herz 4 months ago

So with -k none the alert should trigger, right?

Also available in: Atom PDF