On 21.07.2011 10:43, Ed W wrote: > On 21/07/2011 07:16, Patrick McHardy wrote: >> It's expected behaviour since ICMP packets related to an existing >> connection don't refresh the connection and are not accounted. >> I don't have an opinion on whether they should be accounted, I >> guess you could argue both ways. > > Thanks for the feedback. > > I guess I was hoping that conntrack could be used for accurate bandwidth > accounting, however, it seems to ignore this type of packet, so it's > count is going to deviate from a simple interface byte counter? Yes, but it's going to do that anyways since there are also packets which can't be tracked, invalid packets, etc. Also conntrack doesn't account for link layer headers and only for IPv4/v6 packets. > I don't see the argument for *not* counting the bytes from the ICMP > packet though? Surely the goal of conntrack is that everything is > scooped into some connection? It seems like in this case conntrack > labels this packet as belonging to the connection, BUT doesn't update > the packet or byte counts - this seems like a half and half situation? Well, you could just as well argue that someone is only interested in the amount of bytes/packets which were actually transfered within a connection. Since you mentioned interface counters, we also don't account for ARP requests triggered by a connection. I agree that it would be good to account for these packet *somewhere*. > Thanks for replying - interested to hear the arguments against > refreshing byte counts given that conntrack has already marked it as > related? Well, basically the related ICMP packets bypass protocol related tracking, which is of course correct since they obviously shouldn't be handled by f.i. TCP tracking, but this is where the accounting happens. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
