All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.