On Wed, 2009-04-15 at 10:11 +0200, Thomas Jarosch wrote: > Hi Jan, > > On Tuesday, 14. April 2009 18:10:54 Jan Engelhardt wrote: > > guess I just forward this to you, as I do not want to touch ACCOUNT > > just yet. > > As you already mentioned, I'm not sure it would be a good idea > to include it as the kernel patch extends the kernel<->user space socket > operations in include/linux/netfilter_ipv4/ip_tables.h. I noticed this too, and the question for me is, do you really need do things this way? Because that's really the only thing that requires a kernel patch in your module. Ipset for instance doesn't anymore, but I guess they've been "assigned" a permanent socket option number.... if that could happen for your module: problem solved. > "ipt_account" is another story as it works differently. > The lastest patch seems to be for 2.6.19 / iptables 1.3.5, > though there is some recent activity on the project homepage. > > I'm still surprised how many people are using ipt_ACCOUNT, > somehow it is magnetic to ISPs in central and eastern europe :-) One reason springs to mind, apart from the obvious "they were there first" reason: 64 bit counters... your module only uses 32 bit counters which is not really great if you all you want to do account traffic at an ISP, because if you've got a fully loaded 100 Mbps-Port your counters will overflow every 5 minutes, so one needs to write software that can extract and adding up the accounting data by querying your module very often (I just did that for a future project ;). Also the other ipt_account allows saving and restoring the accounting state, thereby allowing you to deal with crashes and reboots. But as you say, ipt_account is not really supported anymore, so.... BTW, if you plan to add 64bit counters and maybe also IPv6 capability I'd be very much willing to help ;) -- 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