nf_conntrack.acct has no effect

nf_conntrack.acct has no effect

[Jan Engelhardt]

Hi,


A forum made me (re)aware of

Mar 15 18:20:25 wild-thing kernel: nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
Mar 15 18:20:25 wild-thing kernel: CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Plase use
Mar 15 18:20:25 wild-thing kernel: nf_conntrack.acct=1 kernel paramater, acct=1 nf_conntrack module option or
Mar 15 18:20:25 wild-thing kernel: sysctl net.netfilter.nf_conntrack_acct=1 to enable it.

which prompted me to look into this a bit in detail. I was wondering
which functionality I would lose on not setting nf_conntrack.acct. To
my surprise, there is no loss of functionality, as the "nf_ct_acct"
in nf_conntrack_acct.c nor /proc/sys/net/netfilter/nf_conntrack_acct
which is the accompanied sysctl file cause the packet or byte
counters to disappear from `conntrack -L` or /proc/net/nf_conntrack.

Should the message be removed? Should the missing check for
nf_ct_acct be included?

Re: nf_conntrack.acct has no effect

[Patrick McHardy]

Jan Engelhardt wrote:
> A forum made me (re)aware of
> 
> Mar 15 18:20:25 wild-thing kernel: nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
> Mar 15 18:20:25 wild-thing kernel: CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Plase use
> Mar 15 18:20:25 wild-thing kernel: nf_conntrack.acct=1 kernel paramater, acct=1 nf_conntrack module option or
> Mar 15 18:20:25 wild-thing kernel: sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
> 
> which prompted me to look into this a bit in detail. I was wondering
> which functionality I would lose on not setting nf_conntrack.acct. To
> my surprise, there is no loss of functionality, as the "nf_ct_acct"
> in nf_conntrack_acct.c nor /proc/sys/net/netfilter/nf_conntrack_acct
> which is the accompanied sysctl file cause the packet or byte
> counters to disappear from `conntrack -L` or /proc/net/nf_conntrack.
> 
> Should the message be removed? Should the missing check for
> nf_ct_acct be included?

Currently the default is set based on the old config option.
When unset, no acct-extend is allocated for *new* conntracks.
The old ones that do have an acct-extend are still displayed.
Does that explain your observation?

Re: nf_conntrack.acct has no effect

[Jan Engelhardt]

On Monday 2009-03-16 17:56, Patrick McHardy wrote:
> Jan Engelhardt wrote:
>> A forum made me (re)aware of
>>
>> Mar 15 18:20:25 wild-thing kernel: nf_conntrack version 0.5.0 (16384 buckets,
>> 65536 max)
>> Mar 15 18:20:25 wild-thing kernel: CONFIG_NF_CT_ACCT is deprecated and will be
>> removed soon. Plase use
>> Mar 15 18:20:25 wild-thing kernel: nf_conntrack.acct=1 kernel paramater,
>> acct=1 nf_conntrack module option or
>> Mar 15 18:20:25 wild-thing kernel: sysctl net.netfilter.nf_conntrack_acct=1 to
>> enable it.
>>
>> which prompted me to look into this a bit in detail. I was wondering
>> which functionality I would lose on not setting nf_conntrack.acct. To
>> my surprise, there is no loss of functionality, as the "nf_ct_acct"
>> in nf_conntrack_acct.c nor /proc/sys/net/netfilter/nf_conntrack_acct
>> which is the accompanied sysctl file cause the packet or byte
>> counters to disappear from `conntrack -L` or /proc/net/nf_conntrack.
>>
>> Should the message be removed? Should the missing check for
>> nf_ct_acct be included?
>
> Currently the default is set based on the old config option.
> When unset, no acct-extend is allocated for *new* conntracks.
> The old ones that do have an acct-extend are still displayed.
> Does that explain your observation?

Absolutely, thanks for the clarification.

Re: nf_conntrack.acct has no effect

[Holger Eitzenberger]

On Mon, Mar 16, 2009 at 05:56:52PM +0100, Patrick McHardy wrote:

> Currently the default is set based on the old config option.
> When unset, no acct-extend is allocated for *new* conntracks.
> The old ones that do have an acct-extend are still displayed.

I think the current implementation is unfortunate, because the
connbytes match auto-selects CONFIG_NF_CT_ACCT, and you end up having
the message always and can't get rid of it other than patching
it out.

Re: nf_conntrack.acct has no effect

[Patrick McHardy]

Holger Eitzenberger wrote:
> On Mon, Mar 16, 2009 at 05:56:52PM +0100, Patrick McHardy wrote:
> 
>> Currently the default is set based on the old config option.
>> When unset, no acct-extend is allocated for *new* conntracks.
>> The old ones that do have an acct-extend are still displayed.
> 
> I think the current implementation is unfortunate, because the
> connbytes match auto-selects CONFIG_NF_CT_ACCT, and you end up having
> the message always and can't get rid of it other than patching
> it out.

Its only a compat option, it will get removed soon. 2.6.30 or 2.6.31
I'd say.

Re: nf_conntrack.acct has no effect

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 831 bytes --]



On Tue, 17 Mar 2009, Patrick McHardy wrote:

> Holger Eitzenberger wrote:
>> On Mon, Mar 16, 2009 at 05:56:52PM +0100, Patrick McHardy wrote:
>> 
>>> Currently the default is set based on the old config option.
>>> When unset, no acct-extend is allocated for *new* conntracks.
>>> The old ones that do have an acct-extend are still displayed.
>> 
>> I think the current implementation is unfortunate, because the
>> connbytes match auto-selects CONFIG_NF_CT_ACCT, and you end up having
>> the message always and can't get rid of it other than patching
>> it out.
>
> Its only a compat option, it will get removed soon. 2.6.30 or 2.6.31
> I'd say.

I have the patch ready. Do you think it is a good moment to push it now, 
so it will be included in 2.6.30, or should I rather wait for 2.6.31?

Best regards,

 			Krzysztof Olędzki

Re: nf_conntrack.acct has no effect

[Patrick McHardy]

Krzysztof Oledzki wrote:
> 
> 
> On Tue, 17 Mar 2009, Patrick McHardy wrote:
> 
>> Holger Eitzenberger wrote:
>>> On Mon, Mar 16, 2009 at 05:56:52PM +0100, Patrick McHardy wrote:
>>>
>>>> Currently the default is set based on the old config option.
>>>> When unset, no acct-extend is allocated for *new* conntracks.
>>>> The old ones that do have an acct-extend are still displayed.
>>>
>>> I think the current implementation is unfortunate, because the
>>> connbytes match auto-selects CONFIG_NF_CT_ACCT, and you end up having
>>> the message always and can't get rid of it other than patching
>>> it out.
>>
>> Its only a compat option, it will get removed soon. 2.6.30 or 2.6.31
>> I'd say.
> 
> I have the patch ready. Do you think it is a good moment to push it now, 
> so it will be included in 2.6.30, or should I rather wait for 2.6.31?

I'd say it has been long enough, but Jan raised a valid point.
We can't use the Kconfig selection anymore once we remove that
option, so we need a replacement to automatically enable counters.

Re: nf_conntrack.acct has no effect

[Patrick McHardy]

Patrick McHardy wrote:
> Krzysztof Oledzki wrote:
>>
>>
>> On Tue, 17 Mar 2009, Patrick McHardy wrote:
>>
>>> Holger Eitzenberger wrote:
>>>> On Mon, Mar 16, 2009 at 05:56:52PM +0100, Patrick McHardy wrote:
>>>>
>>>>> Currently the default is set based on the old config option.
>>>>> When unset, no acct-extend is allocated for *new* conntracks.
>>>>> The old ones that do have an acct-extend are still displayed.
>>>>
>>>> I think the current implementation is unfortunate, because the
>>>> connbytes match auto-selects CONFIG_NF_CT_ACCT, and you end up having
>>>> the message always and can't get rid of it other than patching
>>>> it out.
>>>
>>> Its only a compat option, it will get removed soon. 2.6.30 or 2.6.31
>>> I'd say.
>>
>> I have the patch ready. Do you think it is a good moment to push it 
>> now, so it will be included in 2.6.30, or should I rather wait for 
>> 2.6.31?
> 
> I'd say it has been long enough, but Jan raised a valid point.
> We can't use the Kconfig selection anymore once we remove that
> option, so we need a replacement to automatically enable counters.

Just to clarify: I'm talking about connbytes of course :)

Re: nf_conntrack.acct has no effect

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1327 bytes --]



On Tue, 17 Mar 2009, Patrick McHardy wrote:

> Krzysztof Oledzki wrote:
>> 
>> 
>> On Tue, 17 Mar 2009, Patrick McHardy wrote:
>> 
>>> Holger Eitzenberger wrote:
>>>> On Mon, Mar 16, 2009 at 05:56:52PM +0100, Patrick McHardy wrote:
>>>> 
>>>>> Currently the default is set based on the old config option.
>>>>> When unset, no acct-extend is allocated for *new* conntracks.
>>>>> The old ones that do have an acct-extend are still displayed.
>>>> 
>>>> I think the current implementation is unfortunate, because the
>>>> connbytes match auto-selects CONFIG_NF_CT_ACCT, and you end up having
>>>> the message always and can't get rid of it other than patching
>>>> it out.
>>> 
>>> Its only a compat option, it will get removed soon. 2.6.30 or 2.6.31
>>> I'd say.
>> 
>> I have the patch ready. Do you think it is a good moment to push it now, so 
>> it will be included in 2.6.30, or should I rather wait for 2.6.31?
>
> I'd say it has been long enough, but Jan raised a valid point.
> We can't use the Kconfig selection anymore once we remove that
> option, so we need a replacement to automatically enable counters.

So loading connbytes should enable accounting automatically. Fine, it is 
doable. But how we want to handle it WRT to NS? Should it be enabled in 
all NameSpaces or...?

Best regards,

 				Krzysztof Olędzki

Re: nf_conntrack.acct has no effect

[Patrick McHardy]

Krzysztof Oledzki wrote:
>> I'd say it has been long enough, but Jan raised a valid point.
>> We can't use the Kconfig selection anymore once we remove that
>> option, so we need a replacement to automatically enable counters.
> 
> So loading connbytes should enable accounting automatically. Fine, it is 
> doable. But how we want to handle it WRT to NS? Should it be enabled in 
> all NameSpaces or...?

Just the ones it is actually used in I'd say (i.e. in the checkentry
function for the current namespace).

Re: nf_conntrack.acct has no effect

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 720 bytes --]



On Tue, 17 Mar 2009, Patrick McHardy wrote:

> Krzysztof Oledzki wrote:
>>> I'd say it has been long enough, but Jan raised a valid point.
>>> We can't use the Kconfig selection anymore once we remove that
>>> option, so we need a replacement to automatically enable counters.
>> 
>> So loading connbytes should enable accounting automatically. Fine, it is 
>> doable. But how we want to handle it WRT to NS? Should it be enabled in all 
>> NameSpaces or...?
>
> Just the ones it is actually used in I'd say (i.e. in the checkentry
> function for the current namespace).

OK, but AFAIK modules are not namespace dependly, so why only in actually 
used one? This bugs me a little.

Best regards,

 				Krzysztof Olędzki

Re: nf_conntrack.acct has no effect

[Patrick McHardy]

Krzysztof Oledzki wrote:
> 
> 
> On Tue, 17 Mar 2009, Patrick McHardy wrote:
> 
>> Krzysztof Oledzki wrote:
>>>> I'd say it has been long enough, but Jan raised a valid point.
>>>> We can't use the Kconfig selection anymore once we remove that
>>>> option, so we need a replacement to automatically enable counters.
>>>
>>> So loading connbytes should enable accounting automatically. Fine, it 
>>> is doable. But how we want to handle it WRT to NS? Should it be 
>>> enabled in all NameSpaces or...?
>>
>> Just the ones it is actually used in I'd say (i.e. in the checkentry
>> function for the current namespace).
> 
> OK, but AFAIK modules are not namespace dependly, so why only in 
> actually used one? This bugs me a little.

But using them is namespace dependant.

Re: nf_conntrack.acct has no effect

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1433 bytes --]



On Tue, 17 Mar 2009, Patrick McHardy wrote:

> Krzysztof Oledzki wrote:
>> 
>> 
>> On Tue, 17 Mar 2009, Patrick McHardy wrote:
>> 
>>> Krzysztof Oledzki wrote:
>>>>> I'd say it has been long enough, but Jan raised a valid point.
>>>>> We can't use the Kconfig selection anymore once we remove that
>>>>> option, so we need a replacement to automatically enable counters.
>>>> 
>>>> So loading connbytes should enable accounting automatically. Fine, it is 
>>>> doable. But how we want to handle it WRT to NS? Should it be enabled in 
>>>> all NameSpaces or...?
>>> 
>>> Just the ones it is actually used in I'd say (i.e. in the checkentry
>>> function for the current namespace).
>> 
>> OK, but AFAIK modules are not namespace dependly, so why only in actually 
>> used one? This bugs me a little.
>
> But using them is namespace dependant.

How?

Anyway, how about this:
  sysctl net.netfilter.nf_conntrack_acct=0 -> disable accounting in this NS
  sysctl net.netfilter.nf_conntrack_acct=1 -> enable accounting in this NS
  sysctl net.netfilter.nf_conntrack_acct=-1 -> (default) use global value in this NS

Global value: by default 0 if connbytes is not loaded, 1 if it is.
Global value could be set with nf_conntrack.acct=0/1 (kernel) acct=0/1 
(module) or sysctl (??? how global, NS independent sysctls are named???).

Doubts:
  - should we set global value to 0 when unloading connbytes?

Best regards,

 				Krzysztof Olędzki

Re: nf_conntrack.acct has no effect

[Patrick McHardy]

Krzysztof Oledzki wrote:
> 
> 
> On Tue, 17 Mar 2009, Patrick McHardy wrote:
> 
>> Krzysztof Oledzki wrote:
>>>
>>>
>>> On Tue, 17 Mar 2009, Patrick McHardy wrote:
>>>
>>>> Krzysztof Oledzki wrote:
>>>>>> I'd say it has been long enough, but Jan raised a valid point.
>>>>>> We can't use the Kconfig selection anymore once we remove that
>>>>>> option, so we need a replacement to automatically enable counters.
>>>>>
>>>>> So loading connbytes should enable accounting automatically. Fine, 
>>>>> it is doable. But how we want to handle it WRT to NS? Should it be 
>>>>> enabled in all NameSpaces or...?
>>>>
>>>> Just the ones it is actually used in I'd say (i.e. in the checkentry
>>>> function for the current namespace).
>>>
>>> OK, but AFAIK modules are not namespace dependly, so why only in 
>>> actually used one? This bugs me a little.
>>
>> But using them is namespace dependant.
> 
> How?

The "connbytes" rules exist only in a specific namespace.

> Anyway, how about this:
>  sysctl net.netfilter.nf_conntrack_acct=0 -> disable accounting in this NS
>  sysctl net.netfilter.nf_conntrack_acct=1 -> enable accounting in this NS
>  sysctl net.netfilter.nf_conntrack_acct=-1 -> (default) use global value 
> in this NS
> 
> Global value: by default 0 if connbytes is not loaded, 1 if it is.
> Global value could be set with nf_conntrack.acct=0/1 (kernel) acct=0/1 
> (module) or sysctl (??? how global, NS independent sysctls are named???).
> 
> Doubts:
>  - should we set global value to 0 when unloading connbytes?

Why do anything global at all? Its not needed unless connbytes is used
(or something in userspace, which we can't detect), and that affects
only a single namespace.

Re: nf_conntrack.acct has no effect

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1984 bytes --]



On Tue, 17 Mar 2009, Patrick McHardy wrote:

> Krzysztof Oledzki wrote:
>> 
>> 
>> On Tue, 17 Mar 2009, Patrick McHardy wrote:
>> 
>>> Krzysztof Oledzki wrote:
>>>> 
>>>> 
>>>> On Tue, 17 Mar 2009, Patrick McHardy wrote:
>>>> 
>>>>> Krzysztof Oledzki wrote:
>>>>>>> I'd say it has been long enough, but Jan raised a valid point.
>>>>>>> We can't use the Kconfig selection anymore once we remove that
>>>>>>> option, so we need a replacement to automatically enable counters.
>>>>>> 
>>>>>> So loading connbytes should enable accounting automatically. Fine, it 
>>>>>> is doable. But how we want to handle it WRT to NS? Should it be enabled 
>>>>>> in all NameSpaces or...?
>>>>> 
>>>>> Just the ones it is actually used in I'd say (i.e. in the checkentry
>>>>> function for the current namespace).
>>>> 
>>>> OK, but AFAIK modules are not namespace dependly, so why only in actually 
>>>> used one? This bugs me a little.
>>> 
>>> But using them is namespace dependant.
>> 
>> How?
>
> The "connbytes" rules exist only in a specific namespace.

True, but it migh be too late to enable accounting at that point. What if 
there are already acitive flows?

>> Anyway, how about this:
>>  sysctl net.netfilter.nf_conntrack_acct=0 -> disable accounting in this NS
>>  sysctl net.netfilter.nf_conntrack_acct=1 -> enable accounting in this NS
>>  sysctl net.netfilter.nf_conntrack_acct=-1 -> (default) use global value in 
>> this NS
>> 
>> Global value: by default 0 if connbytes is not loaded, 1 if it is.
>> Global value could be set with nf_conntrack.acct=0/1 (kernel) acct=0/1 
>> (module) or sysctl (??? how global, NS independent sysctls are named???).
>> 
>> Doubts:
>>  - should we set global value to 0 when unloading connbytes?
>
> Why do anything global at all? Its not needed unless connbytes is used
> (or something in userspace, which we can't detect), and that affects
> only a single namespace.

To enable it before the first packet?

Best regards,

 				Krzysztof Olędzki

Re: nf_conntrack.acct has no effect

[Patrick McHardy]

Krzysztof Oledzki wrote:
>> Why do anything global at all? Its not needed unless connbytes is used
>> (or something in userspace, which we can't detect), and that affects
>> only a single namespace.
> 
> To enable it before the first packet?

We can't do that since we don't know whether it will be used at all.
A namespace starting after a different one has already used it will
have it enabled from the beginning. The first one won't however
unless you enable it whenever the module is enabled, at which point
the sysctl becomes useless.

Re: nf_conntrack.acct has no effect

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 690 bytes --]



On Tue, 17 Mar 2009, Holger Eitzenberger wrote:

> On Mon, Mar 16, 2009 at 05:56:52PM +0100, Patrick McHardy wrote:
>
>> Currently the default is set based on the old config option.
>> When unset, no acct-extend is allocated for *new* conntracks.
>> The old ones that do have an acct-extend are still displayed.
>
> I think the current implementation is unfortunate, because the
> connbytes match auto-selects CONFIG_NF_CT_ACCT, and you end up having
> the message always and can't get rid of it other than patching
> it out.

This is not exactly true. CONFIG_NF_CT_ACCT only selects the default 
value, you are still able to disable it with sysctl.

Best regards,

 				Krzysztof Olędzki

Re: nf_conntrack.acct has no effect

[Jan Engelhardt]

On Tuesday 2009-03-17 14:11, Krzysztof Oledzki wrote:
> On Tue, 17 Mar 2009, Holger Eitzenberger wrote:
>> On Mon, Mar 16, 2009 at 05:56:52PM +0100, Patrick McHardy wrote:
>>
>>> Currently the default is set based on the old config option.
>>> When unset, no acct-extend is allocated for *new* conntracks.
>>> The old ones that do have an acct-extend are still displayed.
>>
>> I think the current implementation is unfortunate, because the
>> connbytes match auto-selects CONFIG_NF_CT_ACCT, and you end up having
>> the message always and can't get rid of it other than patching
>> it out.
>
> This is not exactly true. CONFIG_NF_CT_ACCT only selects the default value, you
> are still able to disable it with sysctl.

The implication is that xt_connbytes will not do the right thing
anymore as soon as user accounting is turned off, either by flipping
the sysctl value or deactivating the kconfig option. That is not
good.

Re: nf_conntrack.acct has no effect

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1187 bytes --]



On Tue, 17 Mar 2009, Jan Engelhardt wrote:

>
> On Tuesday 2009-03-17 14:11, Krzysztof Oledzki wrote:
>> On Tue, 17 Mar 2009, Holger Eitzenberger wrote:
>>> On Mon, Mar 16, 2009 at 05:56:52PM +0100, Patrick McHardy wrote:
>>>
>>>> Currently the default is set based on the old config option.
>>>> When unset, no acct-extend is allocated for *new* conntracks.
>>>> The old ones that do have an acct-extend are still displayed.
>>>
>>> I think the current implementation is unfortunate, because the
>>> connbytes match auto-selects CONFIG_NF_CT_ACCT, and you end up having
>>> the message always and can't get rid of it other than patching
>>> it out.
>>
>> This is not exactly true. CONFIG_NF_CT_ACCT only selects the default value, you
>> are still able to disable it with sysctl.
>
> The implication is that xt_connbytes will not do the right thing
> anymore as soon as user accounting is turned off, either by flipping
> the sysctl value or deactivating the kconfig option. That is not
> good.

The sysctl is not going to be removed and you can still set the initial 
value with the proper kernel/module option. I fail to see the problem 
here.

Best regards,

 				Krzysztof Olędzki

Re: nf_conntrack.acct has no effect

[Patrick McHardy]

Krzysztof Oledzki wrote:
>> The implication is that xt_connbytes will not do the right thing
>> anymore as soon as user accounting is turned off, either by flipping
>> the sysctl value or deactivating the kconfig option. That is not
>> good.
> 
> The sysctl is not going to be removed and you can still set the initial 
> value with the proper kernel/module option. I fail to see the problem here.

Its mainly a usability thing. Its not really obvious that the
match will be entirely without effect if you don't set some sysctl.
And since we can assume that anyone using the connbytes match
intends for it to have some effect, we might as well enable it
automatically.

Re: nf_conntrack.acct has no effect

[Jan Engelhardt]

On Tuesday 2009-03-17 14:28, Jan Engelhardt wrote:
>On Tuesday 2009-03-17 14:11, Krzysztof Oledzki wrote:
>> On Tue, 17 Mar 2009, Holger Eitzenberger wrote:
>>> On Mon, Mar 16, 2009 at 05:56:52PM +0100, Patrick McHardy wrote:
>>>
>>>> Currently the default is set based on the old config option.
>>>> When unset, no acct-extend is allocated for *new* conntracks.
>>>> The old ones that do have an acct-extend are still displayed.
>>>
>>> I think the current implementation is unfortunate, because the
>>> connbytes match auto-selects CONFIG_NF_CT_ACCT, and you end up having
>>> the message always and can't get rid of it other than patching
>>> it out.
>>
>> This is not exactly true. CONFIG_NF_CT_ACCT only selects the default value, you
>> are still able to disable it with sysctl.
>
>The implication is that xt_connbytes will not do the right thing
>anymore as soon as user accounting is turned off, either by flipping
>the sysctl value or deactivating the kconfig option. That is not
>good.
>
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.

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.

Re: nf_conntrack.acct has no effect

[Patrick McHardy]

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.

Re: nf_conntrack.acct has no effect

[Jan Engelhardt]

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

Re: nf_conntrack.acct has no effect

[Patrick McHardy]

Jan Engelhardt wrote:
> On Tuesday 2009-03-17 15:41, Patrick McHardy wrote:
>> Jan Engelhardt wrote:
>>> 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

Pulled, thanks Jan,