From: Ed W <lists@wildgooses.com>
To: Andrew Beverley <andy@andybev.com>
Cc: Netfilter <netfilter@vger.kernel.org>
Subject: Re: High accuracy bandwidth accounting?
Date: Sat, 14 May 2011 14:36:00 +0100 [thread overview]
Message-ID: <4DCE8540.4060909@wildgooses.com> (raw)
In-Reply-To: <1305365024.1921.475.camel@andybev-desktop>
>> I have been experimenting with logging conntrack flows using ulogd2. However,
>> the numbers aren't stacking up against a simple iptables accounting rule...
>> Is there an expectation that nf_conntrack should log every single byte in/out?
>>
>> An example seems to be to cause a name lookup via dnsmasq. For whatever reason
>> this does two simultaneous dns requests to both configured dns servers. One
>> reply comes back slightly quicker than the other and the slower reply appears
>> to cause a local ICMP unreachable response to be generated. Everything is
>> logged *except* the data for the ICMP unreachable response?
>>
>> So tcpdump gives me (note sizes are payload, add 28 to compare with conntrack):
>>
>> 22:23:40.151666 IP 10.141.36.76.25630 > 8.8.4.4.53: 11049+ AAAA? www.yahoo.co.uk. (33)
>> 22:23:40.151993 IP 10.141.36.76.25630 > 8.8.8.8.53: 11049+ AAAA? www.yahoo.co.uk. (33)
>> 22:23:40.850776 IP 8.8.4.4.53 > 10.141.36.76.25630: 11049 3/1/0 CNAME rc.yahoo.com., CNAME rc.g01.yahoodns.net., CNAME any-rc.a01.yahoodns.net. (178)
>> 22:23:41.014108 IP 8.8.8.8.53 > 10.141.36.76.25630: 11049 3/1/0 CNAME rc.yahoo.com., CNAME rc.g01.yahoodns.net., CNAME any-rc.a01.yahoodns.net. (178)
>>
>> 22:23:41.014217 IP 10.141.36.76 > 8.8.8.8: ICMP 10.141.36.76 udp port 25630 unreachable, length 214
>>
>> 22:23:41.401743 IP 10.141.36.76.10248 > 8.8.4.4.53: 25285+ A? www.yahoo.co.uk. (33)
>> 22:23:41.764124 IP 8.8.4.4.53 > 10.141.36.76.10248: 25285 4/0/0 CNAME rc.yahoo.com., CNAME rc.g01.yahoodns.net., CNAME any-rc.a01.yahoodns.net., A 77.238.178.122 (133)
>>
>>
>> However, conntrack gives me:
>>
>> May 9 22:24:10 localhost [DESTROY] ORIG: SRC=10.141.36.76 DST=8.8.4.4 PROTO=UDP SPT=25630 DPT=53 PKTS=1 BYTES=61 , REPLY: SRC=8.8.4.4 DST=10.141.36.76 PROTO=UDP SPT=53 DPT=25630 PKTS=1 BYTES=206
>> May 9 22:24:10 localhost [DESTROY] ORIG: SRC=10.141.36.76 DST=8.8.8.8 PROTO=UDP SPT=25630 DPT=53 PKTS=1 BYTES=61 , REPLY: SRC=8.8.8.8 DST=10.141.36.76 PROTO=UDP SPT=53 DPT=25630 PKTS=1 BYTES=206
>> May 9 22:24:11 localhost [DESTROY] ORIG: SRC=10.141.36.76 DST=8.8.4.4 PROTO=UDP SPT=10248 DPT=53 PKTS=1 BYTES=61 , REPLY: SRC=8.8.4.4 DST=10.141.36.76 PROTO=UDP SPT=53 DPT=10248 PKTS=1 BYTES=161
>>
>>
>> Basically it's missing any count for the packet with tcpdump timestamp: 22:23:41.014217 - ie the port unreachable response? This is confirmed by looking at the iptables counts
>
> Have you tried investigating whether the ICMP packets in question are
> making it into any of the conntrack system? Maybe by using the userspace
> program, or my using the conntrack match extension in iptables?
I think that these UDP packets are completely missing the entire
conntrack system?
I am using ulogd2 to dump all the connections and the ones above are all
that I see. Therefore either there is a bug in ulogd2 which isn't
spitting out this connection or conntrack completely misses this packet?
(arguably whether should it be applied to this connection or not mind?)
I think you are leaning towards confirming this is unexpected and could
be reported as a "bug"? I wrote up the above on the -devel list but
didn't attract any comments so far
It would be interesting to hear if this is a "bug" or expected?
Cheers
Ed W
next prev parent reply other threads:[~2011-05-14 13:36 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 [this message]
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
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=4DCE8540.4060909@wildgooses.com \
--to=lists@wildgooses.com \
--cc=andy@andybev.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.