Connection tracking packet accounting off by one

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello list,

Whilst analyzing network log files I detected that the NFCT destroy
event reported number of packets is off by one under some circumstances.
I used full-packet-captures of an intermediate switch as ground
truth.

My first guest would be that additional SYN-ACK packet (total out
bytes is 52+40=90 -- SYN-ACK + ACK-FIN) is not accounted under
some circumstances. Is there something known about this for current
Debian Buster kernel Linux version 4.19.0-1 (2018-12-22)?

It is also strange that 5 incoming packets are recorded, including
two completely correct ACK for the previously sent SYN-ACK (according
to my TCP protocol knowledge). Those ACKs seem to be accounted
but ignored by the server. The reason for this is unclear to me,
there were no DROPs reported at server-addr during that period
of time, no resource starvation, ... I will check more closely
on this.

The machine at client-addr is currently not reported to be a
malicious scanner, so quite likely the behaviour is not triggered
on purpose but maybe by unexpected packet timing when processed
on a single core machine.


The captured data:

This is the destroy event at server-addr (listening server), reporting
two outgoing packets:

[DESTROY] ORIG: SRC=client-addr DST=server-addr PROTO=TCP SPT=52785 DPT=443 PKTS=5 BYTES=224 , REPLY: SRC=server-addr DST=client-addr PROTO=TCP SPT=443 DPT=52785 PKTS=2 BYTES=92


These packets were captured on an intermediate router:

04:43:52.642988 IP (tos 0x20, ttl 108, id 22953, offset 0, flags [DF], proto TCP (6), length 52)
    client-addr.52785 > server-addr.443: Flags [S], cksum 0x163b (correct), seq 3773798411, win 64240, options [mss 1420,nop,wscale 8,nop,nop,sackOK], length 0

# First outgoing:
04:43:52.644359 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    server-addr.443 > client-addr.52785: Flags [S.], cksum 0x154b (incorrect -> 0xbd74), seq 3540127342, ack 3773798412, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 5], length 0

04:43:52.914848 IP (tos 0x20, ttl 108, id 22958, offset 0, flags [DF], proto TCP (6), length 40)
    client-addr.52785 > server-addr.443: Flags [.], cksum 0x6f51 (correct), seq 3773798412, ack 3540127343, win 260, length 0

# Second outgoing:
04:44:24.127525 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    server-addr.443 > client-addr.52785: Flags [S.], cksum 0x154b (incorrect -> 0xbd74), seq 3540127342, ack 3773798412, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 5], length 0

04:44:24.671018 IP (tos 0x20, ttl 108, id 22965, offset 0, flags [DF], proto TCP (6), length 52)
    client-addr.52785 > server-addr.443: Flags [.], cksum 0x7657 (correct), seq 3773798412, ack 3540127343, win 260, options [nop,nop,sack 1 {3540127342:3540127343}], length 0

04:44:35.585596 IP (tos 0x20, ttl 108, id 22970, offset 0, flags [DF], proto TCP (6), length 40)
    client-addr.52785 > server-addr.443: Flags [F.], cksum 0x6f50 (correct), seq 3773798412, ack 3540127343, win 260, length 0

# Third outgoing:
04:44:35.586032 IP (tos 0x0, ttl 64, id 24359, offset 0, flags [DF], proto TCP (6), length 40)
    server-addr.443 > client-addr.52785: Flags [F.], cksum 0x153f (incorrect -> 0x6cc2), seq 3540127343, ack 3773798413, win 913, length 0

04:44:35.857099 IP (tos 0x20, ttl 108, id 22971, offset 0, flags [DF], proto TCP (6), length 40)
    client-addr.52785 > server-addr.443: Flags [.], cksum 0x6f4f (correct), seq 3773798413, ack 3540127344, win 260, length 0




[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux