I haven't thought of a specifically "evil" use for this yet, but it'd be handy to have a timestamped log of TCP flags observed.
It'd add far too much noise to webtraffic.csv (especially as it'll include traffic not included in the file), but if structured carefully it should be fairly easy for the user to merge in if needed (although it'd mean making certain fields multipurpose to increase readability).
We probably don't want to log every time a segment is sent, so much as specific connection events, so
There might be instances where we want to log either PSH or ACKs (the second could be used as an indicator of the first anyway) though.
For example, for a HTTP Keep-alive connection, it'd show us the idle time between the last transmission and the connection being torn down (so we can deduce the client or server idle time depending which side sends the FIN). Once tuned, the same technique could potentially be used to deduce settings on HTTPS connections.
The standard fields should obviously be used, and I think the final report should just contain a human readable version of the flags, so whilst we might extract as
$STANDARD_FIELDS Ack Push Reset Syn FIN
$STANDARD_FIELDS 1 0 0 1 0
We probably want the final report to be more like
If the resulting report were combined with webtraffic.csv by doing something like
cat webtraffic.csv tcpreport.csv | sort > mergedreport.csv
The flags would show up in the FQDN column, which at least makes the CSV easy for a human to scan over, and the limited set of non-fqdn's should make it relatively easy for the file to be parsed by a custom script if needed.