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