Hi Michael, On Sat, Feb 23, 2013 at 08:57:37PM +0000, Michael Zintakis wrote: > As part of my daily job, I am currently trying to expand the > functionality of the 4 netfilter components dealing with accounting: > nfacct (executable), nfnetlink_acct (userspace library), nfacct > (kernel part) and iptables match (kernel+userspace). > > I need to be able to pre-select the number formatting of "bytes" and > "packets" for each registered nfacct name using additional option in > the nfacct iptables match (called --nfacct-fmt). Each registered > nfacct name would have different formatting depending on the amount > of traffic and also other factors. This formatting is going to be > used mainly by invoking nfacct (executable) as plain text (in other > words as "nfacct list"). > > What I currently implemented is add an additional property to nfacct > struct (uint16_t fmt), storing the format to be used for "bytes" and > "packets" for each registered name. The higher 8 bits of that number > contain the format to be used for "packets", the lower 8 bits - for > "bytes". Could you develop some example usage of your extension? > I was able to successfully modify the kernel part (nfacct), nfacct > (the executable) and libnfnetlink_act userspace library to > accommodate the above change, but I am currently struggling with > modifying the nfacct match in iptables. > > The problem arises when new nfacct match is used against old version > of the nfacct iptables match in the kernel. It all stems from > "struct xt_nfacct_match_info", which I need to expand in order to > include the new option, but since this struct is part of > kernel-headers, I am unable to do that, so I thought to ask for a > bit of advice on this list! > > One possible solution for me is to add a new pair of parse and print > functions, as well as add another element to the nfacct_match array > defined in libxt_nfacct.c to accommodate this new functionality and > then use these newly-defined functions to possibly communicate with > the kernel part to propagate/retrieve the new uint16_t fmt property > value via nfnetlink. > > This approach seems to me a bit overly complex so I thought to ask - > is this the "usual" way of dealing with such scenarios or is there > another, simpler (or better) alternative? Thank you! Yes, this is how our (limited) revision infrastructure works at this moment. -- 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
