netfilter.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Beverley <andy@andybev.com>
To: Jan Engelhardt <jengelh@medozas.de>
Cc: Ed W <lists@wildgooses.com>, Netfilter <netfilter@vger.kernel.org>
Subject: Re: High accuracy bandwidth accounting?
Date: Sun, 22 May 2011 22:22:18 +0100	[thread overview]
Message-ID: <1306099338.2741.317.camel@andybev-desktop> (raw)
In-Reply-To: <alpine.LNX.2.01.1105160911240.4397@frira.zrqbmnf.qr>

Sorry, a bit late replying...

On Mon, 2011-05-16 at 09:23 +0200, Jan Engelhardt wrote: 
> On Monday 2011-05-16 08:43, Andrew Beverley wrote:
> >> >
> >> >Yes, it shows the outgoing packets:
> >> >
> >> >udp      17 23 src=10.0.10.206 dst=212.110.185.119 sport=35259 dport=53
> >> >packets=3 bytes=168 [UNREPLIED] src=212.110.185.119 dst=10.0.10.206
> >> >sport=53 dport=35259 packets=0 bytes=0 mark=0 secmark=0 use=2
> >> >
> >> >But it doesn't show the "ICMP port unreachable" packets that are sent in
> >> >reply. The question is: should it show them?
> >
> >Sorry, when I say it doesn't show them, I mean they are not counted.
> 
> They are:
> 
> >The ones in this case are coming in as RELATED.
> >> 
> >> Monitor with conntrack -E for details.
> >> 
> >conntrack -E -d 212.110.185.119 gives:
> >
> >    [NEW] udp      17 30 src=10.0.10.206 dst=212.110.185.119 sport=35676 dport=53 [UNREPLIED] src=212.110.185.119 dst=10.0.10.206 sport=53 dport=35676
> 
> Since it is a new/related CT (with sport=35676), the packets won't be counted
> towards the original ct (sport=35259).

I didn't make myself clear. The 2 different connections (and 2 different
source ports) were 2 separate tests, but exhibiting the same results. 

> 
> >[DESTROY] udp      17 src=10.0.10.206 dst=212.110.185.119 sport=35676 dport=53 [UNREPLIED] src=212.110.185.119 dst=10.0.10.206 sport=53 dport=35676
> 
> I observe that only UNREPLIED ones carry no counters - and that such is a
> minority of CT events - probably hinting to nonresponsive servers.
>  

The server responds, but with "ICMP port unreachable".

> >But conntrack -E -s 212.110.185.119 gives nothing
> 
> No connection was initiated (=packet first seen) from 212.110.185.119.

Correct, but an "ICMP port unreachable" was sent from 212.110.185.119.

To repeat the test:

iptables -A INPUT -p ICMP -m conntrack --ctstate RELATED -j LOG

dig google.com @212.110.185.119

Logged in the system logger:

[354578.512848] IN=wlan0 OUT= MAC=... SRC=212.110.185.119
DST=10.0.10.206 LEN=84 TOS=0x00 PREC=0x00 TTL=54 ID=36992 PROTO=ICMP
TYPE=3 CODE=3 [SRC=10.0.10.206 DST=212.110.185.119 LEN=56 TOS=0x00
PREC=0x00 TTL=53 ID=17592 PROTO=UDP SPT=53163 DPT=53 LEN=36 ] 

The only thing shown in conntrack -E is:

[NEW] udp      17 30 src=10.0.10.206 dst=212.110.185.119 sport=53163
dport=53 [UNREPLIED] src=212.110.185.119 dst=10.0.10.206 sport=53
dport=53163

And conntrack -L | grep 212.110.185.119 shows (in completion):

udp      17 22 src=10.0.10.206 dst=212.110.185.119 sport=53163 dport=53
packets=3 bytes=168 [UNREPLIED] src=212.110.185.119 dst=10.0.10.206
sport=53 dport=53163 packets=0 bytes=0 mark=0 use=1

So, the ICMP packets arrive as RELATED, but are not accounted for
looking at the conntrack accounting.

Andy



  reply	other threads:[~2011-05-22 21:22 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-09 14:12 High accuracy bandwidth accounting? Ed W
2011-05-09 21:45 ` Andrew Beverley
2011-05-09 22:07   ` Ed W
2011-05-09 22:16     ` Andrew Beverley
2011-05-09 22:49   ` Ed W
2011-05-11 14:30   ` Ed W
2011-05-12  0:01     ` Andrew Beverley
2011-05-12 22:17       ` Ed W
2011-05-12 22:27         ` Andrew Beverley
2011-05-09 23:23 ` Ed W
2011-05-14  9:23   ` Andrew Beverley
2011-05-14 13:36     ` Ed W
2011-05-14 16:29       ` Andrew Beverley
2011-05-14 22:33         ` Jan Engelhardt
2011-05-15  7:23           ` Andrew Beverley
2011-05-15  9:08             ` Jan Engelhardt
2011-05-16  6:43               ` Andrew Beverley
2011-05-16  7:23                 ` Jan Engelhardt
2011-05-22 21:22                   ` Andrew Beverley [this message]
2011-05-16 14:35               ` Ed W
2011-05-16 14:59                 ` Jan Engelhardt
2011-05-16 16:53                   ` Ed W
2011-05-14  9:48   ` Marek Kierdelewicz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1306099338.2741.317.camel@andybev-desktop \
    --to=andy@andybev.com \
    --cc=jengelh@medozas.de \
    --cc=lists@wildgooses.com \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).