A last word: Captcp is not optimized to analyze huge PCAP files with millions of TCP connections. Captcp is primary designed and optimized to analyze one TCP connection/flow. If you have a really large PCAP file (say 1 GB and larger) you can use tcpslit to separate TCP connections before. Under normal circumstances this is not required.
Captcp syntax is similar to git or perf:
<module-args> pcap-file. To get a overview over all
arguments for a given submodule you can call
--help. Another similarity for all modules is the verbose mode:
captcp module --verbose <debug | info | warning |
A fundamental concept of Captcp are Connections and Flows. Connections
are bidirectional between two TCP endpoints. A connection consist of
two flows - flows are unidirectional. It can happened that a connection
consist of only one flow because the recorded duration was to short or
packets are missing - but this is an exception. Via
statistic <pcapfile> all connections and flows of a PCAP
file can be displayed. The numbering (e.g. 1, 2, 3, for a connection and
1.1, 1.2, 2.1, 2.2, 3.1, 3.2) is consistent across all captcp modules. So
often you start by identifying the relevant connection (or flow) and
limit the analysis for these connection (or flow).
Attention: if you capture traffic nowadays you may not capture real wire data! Current network adapters support offloading capabilities. It is wise to disable all offloading capabilities if you want a realistic behaviour if you trace traffic from the sender machine.
You will note these effects if you realize more TCP ACK packets then Data packets or when the data size is larger then the Maximum Segment Size.
ethtool -K ethN rx off tx off sg off tso off