Wrong PCAP processing for TCP connections

[stamparm]

Again me :)

Problematic block is here

So, TCP connections are recognized by first packet seen, where this can be a problem in lots of specific situations (TCP out of order packets, SYN missing, late PCAP recording because of slow start or similar). In our case, SYN packet is just not there, while the response SYN-ACK is considered as the initial connection attempt, making CAPE results having mixed source and destination.

So, I have couple of ideas on my mind, but I would not like to propose something too complicated for your taste. As you are already using dpkt it shouldn't be a too much hustle to check some flags.

For example, if first packet is for unknown connection, maybe to check whether it has SYN set and treat packet as you do it now, while in case of SYN-ACK to reverse the order dst<->src in your connection table. It can be even more complicated that this, but not sure if it is too much

[doomedraven]

hello, PR maybe your idea? :)

[stamparm]

best heuristics I could come with:

*** 757,762 ****
--- 757,765 ----
                              (dst, dport, src, sport) in self.tcp_connections_seen
                              or (src, sport, dst, dport) in self.tcp_connections_seen
                          ):
+                             if tcp.flags != dpkt.tcp.TH_SYN:
+                                 if dport > sport:
+                                     src, sport, dst, dport = dst, dport, src, sport
                              self.tcp_connections.append((src, sport, dst, dport, offset, ts - first_ts))
                              self.tcp_connections_seen.add((src, sport, dst, dport))
                          self.alive_hosts[dst, dport] = True

[doomedraven]

thanks, lets see if someone can test it too, as those months im pretty busy