Re: High accuracy bandwidth accounting?

[Andrew Beverley <andy@andybev.com>]

On Sun, 2011-05-15 at 11:08 +0200, Jan Engelhardt wrote: 
> On Sunday 2011-05-15 09:23, Andrew Beverley wrote:
> 
> >On Sun, 2011-05-15 at 00:33 +0200, Jan Engelhardt wrote:
> >> On Saturday 2011-05-14 18:29, Andrew Beverley wrote:
> >> 
> >> >On Sat, 2011-05-14 at 14:36 +0100, Ed W wrote:
> >> >
> >> >Okay, I've played around with this myself using a similar scenario. It
> >> >looks to me like the packets *are* making it into the conntrack system.
> >> >
> >> >I tried setting a LOG target to match those packets with a ctstate of
> >> >RELATED:
> >> >
> >> >iptables -A INPUT -p ICMP -m conntrack --ctstate RELATED -j LOG
> >> >
> >> >And they were indeed logged. But there was no visibility of them using
> >> >the conntrack userspace program.
> >> 
> >> Does `conntrack -L` show anything for you at all? 
> >
> >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?
> 
> conntrack -L shows pseudo/NFCT-style connections, not packets.

Sorry, when I say it doesn't show them, I mean they are not counted. The
conntrack entry for that connection only shows a packet count in one
direction. It shows zero in the other direction.

> As for 
> ICMP port unreachable, either its classification is
> - INVALID, in which case there is no CT to show
> - a reply, in which case it is part of the shown CT - and the event 
> monitor will show an UPDATE
> - RELATED, in which case a new CT is shown - and which may disappear 
> shortly after due to a short lifetime - the event monitor should show 
> NEW I think.

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
[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

But conntrack -E -s 212.110.185.119 gives nothing

So they do not seem to be counted anywhere.

> >> There is/was a 
> >> short intermediate time when it would not return anything.
> >
> >Do you mean there was a time when a particular version of conntrack
> >would not return anything?
> 
> Yes, see kernel commit cba85b532e4aabdb97f44c18987d45141fd93faa that 
> (the fix) for details.

I upgraded the kernel to 2.6.38.6 just in case, but the same still
happens.

Thanks,

Andy