On Debian Linux systems conntrack uses the /proc/net/nf_conntrack device. This
device may not be available in other Linux variants (e.g., Ubuntu). Sebastian
Monte provided information about how conntrack can be used in those cases. See
README.no_nf_conntrack for a description of his findings.

Conntrack byte counts add the sizes of the IP headers (usually 20 bytes) to
the byte counts. So, icmp packets are usually reported as having size 84, 
even though ping etc reports the payload (64 bytes). Since the actual size of
the IP headers cannot be determined from conntrack's output, the sizes
reported via natlog's conntrack mode are as reported, and are therefore not
corrected for IP header lengths.

Example conntrack lines: 
The 'maybe' entries appear if the command
 
     $ echo 1 > /proc/sys/net/netfilter/nf_conntrack_acct

 has been issued before starting natlog.

[1338987414.52626 ]      [NEW] tcp      6 120 SYN_SENT 
     src=192.168.1.4     dst=129.125.14.80   sport=59783 dport=22  [UNREPLIED] 
     src=129.125.14.80   dst=129.125.100.246 sport=22    dport=59783

[1387190223.487711]      [DESTROY] tcp  6                
     src=192.168.17.21   dst=192.87.23.111   sport=50029 dport=443
     packets=7 bytes=450     <-- maybe
     src=192.87.23.111   dst=129.125.100.246 sport=443   dport=50029 
     packets=5 bytes=1679    <-- maybe
     [ASSURED] 


[1515751941.057688]     [NEW] tcp      6 120 SYN_SENT 
    src=192.168.17.6    dst=129.125.3.162   sport=49590 dport=22    [UNREPLIED] 
    src=129.125.3.162   dst=192.168.8.17    sport=22    dport=49590

[1515752071.886964] [DESTROY] tcp      6 
    src=192.168.17.6    dst=129.125.3.162   sport=49590 dport=22 
    packets=29  bytes=4840 
    src=129.125.3.162   dst=192.168.8.17    sport=22    dport=49590 
    packets=30  bytes=5132  [ASSURED]

With conntrack records the source port and unique port combinations (1st line)
are unique and are used as the key.

-------------------------------------------------------------------------------

[1387190207.172139]      [NEW] udp      17 30
     src=10.4.0.6        dst=129.125.4.6       sport=42998 dport=53 [UNREPLIED]
     src=129.125.4.6     dst=129.125.100.246   sport=53    dport=42998

[1387190187.423829]      [DESTROY] udp      17
     src=10.4.0.6        dst=216.239.34.10     sport=60840 dport=53
     packets=1 bytes=138     <-- maybe
     src=216.239.34.10   dst=129.125.100.246   sport=53    dport=60840
     packets=1 bytes=524     <-- maybe


 Note that the tcp and udp lines are identically organized 

With conntrack records the source port and unique port combinations (1st line)
are unique and are used as the key.

-------------------------------------------------------------------------------



[1387190207.153486]      [NEW] icmp 1 30             
     src=192.168.17.7    dst=129.125.3.162     type=8 code=0 id=7016 [UNREPLIED]  
     src=129.125.3.162   dst=129.125.100.246   type=0 code=0 id=7016 

[1387190237.151720]      [DESTROY] icmp 1
     src=192.168.17.7    dst=129.125.3.162     type=8 code=0 id=7016
     packets=1 bytes=84      <-- maybe
     src=129.125.3.162   dst=129.125.100.246   type=0 code=0 id=7016
     packets=1 bytes=84      <-- maybe


With conntrack records the IDs are unique and are used as the key.

-------------------------------------------------------------------------------









