Re: nf_conntrack.acct has no effect

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tuesday 2009-03-17 15:41, Patrick McHardy wrote:
> Jan Engelhardt wrote:
>> xt_conntrack for example has a nicer effect: once you add a rule that
>> contains it, it will load nf_conntrack_ipv{4,6}, which in turn causes
>> Netfilter to start tracking in the first place.
>>
>> So along the lines, xt_connbytes could pin a module (or perhaps
>> something more light-weight) to ultimately signify
>> "forced-activation"/"deactivation-impossible", much like you cannot
>> remove nf_conntrack while an xt_conntrack-using rule is in place.
>
> It doesn't have to be forced IMO, but yes, the automatic enabling
> should be similar to what xt_conntrack does.
>
>> Then only one thing remains. As for nf_conntrack, once it is loaded,
>> it picks up already-running connections (and loses them as soon
>> as you rmmod it). This is not the case with accounting as far as I
>> have observed yesterday - only new connections get to have (or
>> not to have) an acct structure; existing ones are not modified
>> or picked up like conntrack does.
>
> Thats not possible using ct_extend.
>
I see. It is probably best then to document this behavior in iptables.
To that end, here are two patches, pullable from

	git://dev.medozas.de/iptables master

Jan Engelhardt (2):
      libxt_connbytes: minor manpage adustments
      libxt_connbytes: document nf_ct_acct behavior

Updating 38725a4..71bc61f
Fast forward
 extensions/libxt_connbytes.man |   16 +++++++++++-----
 1 files changed, 11 insertions(+), 5 deletions(-)

# combined-diff 38725a4..71bc61f
diff --git a/extensions/libxt_connbytes.man b/extensions/libxt_connbytes.man
index fc8c141..e475cae 100644
--- a/extensions/libxt_connbytes.man
+++ b/extensions/libxt_connbytes.man
@@ -1,14 +1,20 @@
 Match by how many bytes or packets a connection (or one of the two
 flows constituting the connection) has transferred so far, or by
 average bytes per packet.
-
-The counters are 64bit and are thus not expected to overflow ;)
-
+.PP
+The counters are 64-bit and are thus not expected to overflow ;)
+.PP
 The primary use is to detect long-lived downloads and mark them to be
 scheduled using a lower priority band in traffic control.
-
+.PP
 The transferred bytes per connection can also be viewed through
-/proc/net/ip_conntrack and accessed via ctnetlink
+`conntrack -L` and accessed via ctnetlink.
+.PP
+NOTE that for connections which have no accounting information, the match will
+always return false. The "net.netfilter.nf_conntrack_acct" sysctl flag controls
+whether \fBnew\fP connections will be byte/packet counted. Existing connection
+flows will not be gaining/losing a/the accounting structure when be sysctl flag
+is flipped.
 .TP
 [\fB!\fP] \fB\-\-connbytes\fP \fIfrom\fP[\fB:\fP\fIto\fP]
 match packets from a connection whose packets/bytes/average packet
--
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

[Index of Archives]     [Netfitler Users]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux