The recent kernel has compat layer for iptables. It doesn't have
compat layer for libipq and ip6tables, but ip6tables with
KERNEL_64_USERSPACE_32 is still broken. We should fix kernel instead of
fixing them if and when we want use their 32bit binary with 64bit kernel.

Correcting a chain references increment bug in libiptc.
The bug lies in function iptc_delete_entry() / TC_DELETE_ENTRY. The
problem is the construction of "r" the rule entry, that is used for
comparison. The problem is that the function iptcc_map_target()
increase the target chains references count.

in all major TC_* functions. This is necessary because in certain cases, an error return from a function that doesn't set 'iptc_fn' will conflict with a function-specific error return from one that does, causing TC_STRERROR() to return the wrong error string. This ensures that the right one will be returned.
- Implements a simple reference counter for the netlink socket global variable 'sockfd'; this is necessary for IPTables::IPv4, where multiple tables (filter, nat, mangle, untracked) may be opened at one time. The way libiptc does it in the official version causes previously-opened tables to break such that attempts to commit changes will fail.
- Adds a couple of memset() invocations in TC_COMMIT, based on past analysis with valgrind. It claimed that allocated structure were not being fully initialized, and adding the memset()s corrected this warning.
(Derrik Pates <demon@devrandom.net>)

(ie. without -O) on old kernels where ipt_get_target() was defined "extern inline". These days it's "static inline", and only developers build without -O anyway.
Fix up DUMP_ENTRIES a little, but remove calls: it only dumps the table as loaded, not the changed (cached) table, which is misleading.
Fix TC_DELETE_ENTRY: we need to use iptcc_map_target() before comparing, otherwise "-j DROP" (as an example) doesn't work.

Do the same with TC_DELETE_NUM_ENTRY() when deleting the last rule.
My rule management script does both of these things in certain situations.
Created a file with 50.000 rules which my script converted into
iptables-restore format but inserting each rule with an index instead of
appending like the iptables-save output does. That took a while without this
optimization. Same thing when deleting the 45.000 last rules in that chain,
the script outputs deletes by number starting from the bottom.
Inserting or deleting (by number) in the middle of the chain is still O(n)
where n is the rulenumber where the insert/delete is taking place.

It checked if a rule existed on the position we were inserting to.
Thus inserting into an empty chain didn't work.
And it didn't care about the fact that the first rule in the chain has index 1
the rulenumer we get starts at 0...