path: root/libiptc
Commit message (Collapse)AuthorAgeFilesLines
* [PATCH 08/10] Remove old functions, constants/C=EU/ST=EU/CN=Patrick McHardy/emailAddress=kaber@trash.net2008-04-151-1/+2
* [PATCH 05/13] Combine IP{,6}T_LIB_DIR into XTABLES_LIBDIR/C=EU/ST=EU/CN=Patrick McHardy/emailAddress=kaber@trash.net2008-04-131-4/+0
* [PATCH 02/13] Fix all remaining warnings (missing declarations, missing ↵/C=EU/ST=EU/CN=Patrick McHardy/emailAddress=kaber@trash.net2008-04-131-5/+4
| | | | prototypes)
* [PATCH 05/24] Fix -Wshadow warnings and clean up xt_sctp.h/C=EU/ST=EU/CN=Patrick McHardy/emailAddress=kaber@trash.net2008-04-061-27/+22
| | | | | Note: xt_sctp.h is still not merged upstream in the kernel as of this commit. But a refactoring was really needed.
* Retry ruleset dump when kernel returns EAGAIN./C=EU/ST=EU/CN=Patrick McHardy/emailAddress=kaber@trash.net2008-04-021-1/+4
| | | | Bugzilla #104
* Remove obsolete file/C=EU/ST=EU/CN=Patrick McHardy/emailAddress=kaber@trash.net2008-01-201-24/+0
* [PATCH 3/3] Solving scalability issue: for chain list "name" searching./C=EU/ST=EU/CN=Patrick McHardy/emailAddress=kaber@trash.net2008-01-151-4/+414
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Solving scalability issue: for chain list "name" searching. Functions: iptcc_find_label(), iptc_is_chain(). Testing if a chain exist, requires a linearly walk of linked list with chain-names (doing a strcmp(3) in each step). Giving a worst-case runtime of O(n) where n is the number of chains. Why is this important to fix?! If only called once, this should not be a big concern, even-though the string compares are expensive. The performance issue arise with many chains for example; when using "iptables-restore", or when listing all "iptables -nL" rules, or when using CPAN IPTables::libiptc. Having 50k chains, the rule listing, with the command: "./iptables -nL > /dev/null", Without patch it takes approximately 5 minutes, With the patch it takes 0.5 seconds. Listing without patch: real 4m49.426s user 4m37.993s sys 0m0.280s Listing with patch: real 0m0.558s user 0m0.484s sys 0m0.064s How is it solved?! The issue is solved introducing a new data structure, that allow us to do binary search of chain names. Thus, reducing the worst-case runtime to O(log n). Being more specific: The new data structure is called "chain index", which is an array with pointers into the chain list, with CHAIN_INDEX_BUCKET_LEN spacing. This facilitates the ability to speedup chain list searching, by find a more optimal starting points when searching the linked list. The runtime complexity is actually also affected by this "bucket" size concept. Thus, O(log(n/k) + k) where k is CHAIN_INDEX_BUCKET_LEN. A nice property of the chain index, is that the "bucket" list length is max CHAIN_INDEX_BUCKET_LEN (when just build, inserts will change this). Oppose to hashing, where the "bucket" list length can vary a lot. Signed-off-by: Jesper Dangaard Brouer <>
* [PATCH 2/3] Introduce a counter for number of user defined chains./C=EU/ST=EU/CN=Patrick McHardy/emailAddress=kaber@trash.net2008-01-151-1/+7
| | | | | | Introduce a counter for number of user defined chains. Signed-off-by: Jesper Dangaard Brouer <>
* [PATCH 1/3] Inline functions iptcc_is_builtin() and set_changed()./C=EU/ST=EU/CN=Patrick McHardy/emailAddress=kaber@trash.net2008-01-151-2/+2
| | | | | | | The two functions are obvious candidates for inlining. Using gprof(1) shows that they actually affects performance. Signed-off-by: Jesper Dangaard Brouer <>
* [PATCH] More safe chain sorting, improving r7098/C=EU/ST=EU/CN=Patrick McHardy/emailAddress=kaber@trash.net2007-12-121-1/+17
| | | | | | | | | | | | | | | | | This patch is an improvment of r7098 (made by me). Assuring compatibility between 1.4.0 and older versions, regarding chain sorting. Chains from kernel are already sorted, as they are inserted sorted. But there exists an issue when shifting to 1.4.0 from an older version, as old versions allow last created chain to be unsorted. This unsorted chain would survive in 1.4.0, as chains are now only sorted on creation. This patch verifies that chains are sorted, if not it fixes the sorting. Signed-off-by: Jesper Dangaard Brouer <>
* Fix sockfd use accounting for kernels without autoloading/C=EU/ST=EU/CN=Patrick McHardy/emailAddress=kaber@trash.net2007-12-041-4/+0
* [PATCH]: iptables/libiptc perf issue: Sorting chain during pull-out/C=EU/ST=EU/CN=Patrick McHardy/emailAddress=kaber@trash.net2007-11-281-3/+3
| | | | | | | | | | | | | | | | | | | Performance optimize scalability issue: Sorting chain during pull-out give worst-case runtime O(Chains2). When pulling out the blob, every chain name is inserted alphabetically into a linked list (by function iptc_insert_chain()). The problem with this approach is that the chain names delivered in the blob is already sorted (as we push it back to the kernel sorted). This cause chain parsing to always process every element in the chain list and finish with a tail add. Causing worst-case runtime O(C2/2) for alphabetically sorting of chains. The patch solves this by only calling iptc_insert_chain() when creating new chains. Signed-off-by: Jesper Dangaard Brouer <>
* Fix unused function warning/C=EU/ST=EU/CN=Patrick McHardy/emailAddress=kaber@trash.net2007-09-081-2/+1
* Fix more sparse warnings: non-C99 array declaration, incorrect function ↵/C=EU/ST=EU/CN=Patrick McHardy/emailAddress=kaber@trash.net2007-09-081-8/+8
| | | | prototypes
* [PATCH]: Remove last vestiges of NFC (Peter Riley <>)/C=EU/ST=EU/CN=Patrick McHardy/emailAddress=kaber@trash.net2007-09-022-12/+4
* Removes KERNEL_64_USERSPACE_32/C=JP/ST=JP/CN=Yasuyuki Kozakai/emailAddress=yasuyuki@netfilter.org2007-06-301-16/+0
| | | | | | | 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.
* [PATCH]: iptables -Z clears the per-rule counters, but not the chain policy ↵/C=DE/ST=Berlin/L=Berlin/O=Netfilter Project/OU=Development/CN=kaber/emailAddress=kaber@netfilter.org2006-08-221-0/+3
| | | | | | counters (Andy Gay <>)
* [PATCH] BUG: libiptc chain references bug (Jesper Brouer <>)/C=DE/ST=Berlin/L=Berlin/O=Netfilter Project/OU=Development/CN=kaber/emailAddress=kaber@netfilter.org2006-07-201-0/+8
| | | | | | | | | 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.
* [PATCH] libiptc symbols clash (Phil Oester <>)/C=DE/ST=Berlin/L=Berlin/O=Netfilter Project/OU=Development/CN=kaber/emailAddress=kaber@netfilter.org2006-07-052-0/+4
| | | | | As reported by Dmitry Levin, the TC_NUM_RULES and TC_GET_RULE exports clash. His patch below, resolving bug #456
* Don't overwrite errno with return value of setsockopt (which is -1 on error)./C=DE/ST=Berlin/L=Berlin/O=Netfilter Project/OU=Development/CN=kaber/emailAddress=kaber@netfilter.org2006-04-221-6/+2
| | | | Fixes "Unknown error 4294967295" message (bugzilla #460).
* Revert incorrect fix for "Unknown error 4294967295" problem/C=DE/ST=Berlin/L=Berlin/O=Netfilter Project/OU=Development/CN=kaber/emailAddress=kaber@netfilter.org2006-04-221-2/+0
* When entering an invalid command (such as iptables -A INPUT -j MARK --set-mark/C=DE/ST=Berlin/L=Berlin/O=Netfilter Project/OU=Development/CN=laforge/emailAddress=laforge@netfilter.org2006-04-211-0/+2
| | | | 1), the error message "Unknown error 4294967295" is displayed; (Closes: #460)
* don't install libiptc.a/C=DE/ST=Berlin/L=Berlin/O=Netfilter Project/OU=Development/CN=laforge/emailAddress=laforge@netfilter.org2006-02-091-1/+2
* - Fix memory leak in TC_COMMIT() (Markus Sundberg)/C=DE/ST=Berlin/L=Berlin/O=Netfilter Project/OU=Development/CN=laforge/emailAddress=laforge@netfilter.org2005-11-121-23/+25
| | | | | - Cleanup error path of TC_COMMIT() - Correctly propagate errors of setsockopt to calling function
* _really_ sort only user defined chains (Robert de Barth ↵/C=DE/ST=Berlin/L=Berlin/O=Netfilter Project/OU=Development/CN=laforge/emailAddress=laforge@netfilter.org2005-07-311-1/+1
| | | | <>
* get rid of numerous gcc-4 warnings/C=DE/ST=Berlin/L=Berlin/O=Netfilter Project/OU=Development/CN=laforge/emailAddress=laforge@netfilter.org2005-07-191-2/+2
* fix deletion of targets where kernel size != userspace size (Pablo Neira)/C=DE/ST=Berlin/L=Berlin/O=Netfilter Project/OU=Development/CN=laforge/emailAddress=laforge@netfilter.org2005-06-232-0/+2
* Restore chain order (Olaf Rempel <>)/C=DE/ST=Berlin/L=Berlin/O=Netfilter Project/OU=Development/CN=kaber/emailAddress=kaber@netfilter.org2005-03-041-4/+7
* Kill NFC_* stuff in iptables (Pablo Neira <>)/C=DE/ST=Berlin/L=Berlin/O=Netfilter Project/OU=Development/CN=kaber/emailAddress=kaber@netfilter.org2005-02-142-22/+0
| | | | Fixes build with conntrack event patch for 2.6
* Revert the recent addition of memset()'s to TC_COMMIT. One of them is bogus ↵/C=DE/ST=Berlin/L=Berlin/O=Netfilter Project/OU=Development/CN=gandalf/emailAddress=gandalf@netfilter.org2005-02-041-3/+0
| | | | | | and the other one needs more investigation to why valgrind is complaining. Noticed and reverted by Phil Oester.
* re-implement alphabetic sorting to not confuse users who upgrade to 1.3.0/C=DE/ST=Berlin/L=Berlin/O=Netfilter Project/OU=Development/CN=laforge/emailAddress=laforge@netfilter.org2005-02-011-7/+18
* - Sets the 'iptc_fn' global variable to the pointer to the current functions ↵/C=DE/ST=Berlin/L=Berlin/O=Netfilter Project/OU=Development/CN=laforge/emailAddress=laforge@netfilter.org2005-02-011-13/+36
| | | | | | | | 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 <>)
* Extension revision number support (if kernel supports the getsockopts)./C=DE/ST=Berlin/L=Berlin/O=Netfilter Project/OU=Development/CN=rusty/emailAddress=rusty@netfilter.org2005-01-031-2/+2
| | | | | Enhance MARK match with second revision. Committed in anticipation of the kernel patch being applied.
* Stupid typo that meant we didn't compare target data when doing ↵/C=DE/ST=Berlin/L=Berlin/O=Netfilter Project/OU=Development/CN=rusty/emailAddress=rusty@netfilter.org2004-12-291-1/+1
| | | | delete-by-matching-rule (found by nfsim test).
* Implement some optimization for finding rules to replace in TC_REPLACE_ENTRY./C=DE/ST=Berlin/L=Berlin/O=Netfilter Project/OU=Development/CN=gandalf/emailAddress=gandalf@netfilter.org2004-12-181-2/+9
| | | | Stolen from TC_DELETE_NUM_ENTRY.
* Make "is_same" test basics and entries only: targets are generic./C=DE/ST=Berlin/L=Berlin/O=Netfilter Project/OU=Development/CN=rusty/emailAddress=rusty@netfilter.org2004-12-163-70/+72
| | | | | | | Make target testing aware of different kinds of rules. Change reverse logic: target_different now target_same. Set type to MODULE in iptcc_map_target. Add testcase for this.
* Remove GET_TARGET() define: this was for compiling iptables for debugging ↵/C=DE/ST=Berlin/L=Berlin/O=Netfilter Project/OU=Development/CN=rusty/emailAddress=rusty@netfilter.org2004-12-161-37/+25
| | | | | | | (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.
* Search backwards when inserting/deleting in/from the top half of the rules ↵/C=DE/ST=Berlin/L=Berlin/O=Netfilter Project/OU=Development/CN=gandalf/emailAddress=gandalf@netfilter.org2004-10-241-12/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in a chain. before: insert 50k rules without any previous rules real 0m1.314s user 0m1.184s sys 0m0.123s insert 50k with one already existing rule real 2m38.052s user 2m37.296s sys 0m0.353s insert 50k rules in the middle of 20k already existing rules real 2m43.831s user 2m43.005s sys 0m0.414s delete rule #70000 10k times with 100k rules real 1m37.990s user 1m37.247s sys 0m0.500s after: insert 50k without any previous rules real 0m1.315s user 0m1.184s sys 0m0.125s insert 50k with one already existing rule real 0m1.313s user 0m1.189s sys 0m0.119s insert 50k rules in the middle of 20k already existing rules real 0m8.550s user 0m8.327s sys 0m0.197s delete rule #70000 10k times with 100k rules real 0m35.566s user 0m35.062s sys 0m0.416s
* Replace O(n) with O(1) when TC_INSERT_ENTRY() inserts an entry at the end.gandalf2004-09-231-8/+23
| | | | | | | | | | | | | | 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.
* Spelling error.gandalf2004-09-231-2/+2
* Fix returnvalue of TC_BUILTIN()gandalf2004-09-231-2/+2
| | | | | All jumps to nonexisting chains were believed to be jumps to builtin chains, that's bad as it made it impossible to add rules with external targets.
* Make sure to zero all the memory we allocate for the new table.gandalf2004-09-221-2/+2
| | | | | Makes flushing of chains containing more than a few entries work without potentially oopsing the kernel.
* Make TC_DELETE_ENTRY() and TC_DELETE_NUM_ENTRY() actually do something practicalgandalf2004-09-221-1/+5
* Fix two more rulenumber off by 1 errorsgandalf2004-09-221-3/+3
* Insertion of rules with -I was broken.gandalf2004-09-221-5/+15
| | | | | | | 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...
* Fix rule countinggandalf2004-09-221-1/+3
* Fix listing of module targets.gandalf2004-09-221-1/+4
| | | | | | Type was only set for standard targets. Harald: please review.
* fix segfault from memory allocation: handle->entries is actualy struct ↵laforge2004-09-191-2/+3
| | | | ipt_get_entries plus the size
* add delete by matching-rule to libiptc2 (still untested)laforge2004-08-301-67/+19
* complete libiptc rewrite. Time to load 10k rules goes down from 2.20 ↵laforge2004-08-295-918/+1973
| | | | minutes to 1.255 seconds (!). Might still contain bugs, use with caution.