| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Can build both static and dynamic at the same time
- iptables-static will be a multi-binary, semi-static
(link against libc but w/o dynamic plugins)
- Always build IPv6 modules
- consider INSTALL
Signed-off-by: Jan Engelhardt <jengelh@computergmbh.de>
|
|
|
|
|
| |
- check for malloc() return value in merge_opts()
- check for merge_opts() return value
|
|
|
|
| |
Signed-off-by: Patrick McHardy <kaber@trash.net>
|
|
|
|
| |
Signed-off-by: Patrick McHardy <kaber@trash.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <hawk@comx.dk>
|
|
|
|
|
|
| |
Introduce a counter for number of user defined chains.
Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
|
|
|
|
|
|
|
| |
The two functions are obvious candidates for inlining.
Using gprof(1) shows that they actually affects performance.
Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes the problem that the CONNMARK mask value
has been set to 0 whenever the CONNMARK target options were
not the last options to be processed.
It initalizes the mask value rather than setting it for
each parse.
Signed-off-by: Peter Warasin <peter@endian.com>
|
| |
|
|
|
|
|
|
|
|
| |
if NO_SHARED_LIBS is defined, then iptables shouldnt even include dlfcn.h.
otherwise you hit a build failure when using toolchains that do not provide
dlfcn.h because they do not support shared objects.
Signed-Off-By: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
|
|
| |
Remove our own definitions of the Linux types and use <linux/types.h>
instead. libiptc needs it too, or otherwise will choke on union
nf_inet_addr.
Signed-off-by: Jan Engelhardt <jengelh@computergmbh.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <hawk@comx.dk>
|
| |
|
|
|
|
|
|
|
| |
When running as a user iptables can't determine the highest supported
revision and exits. Assume all revision are supported in case we get
a EPERM. If the user is not showing the help text but trying to add
new rules he'll get EPERM later anyway.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
libxt_u32.man already exists.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <hawk@comx.dk>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
iptables prints the mask as a prefix length if it is valid;
This patch makes iptables-save do the same.
Also, iptables-save will always print "/32" in the "-s addr/32"
case now. This reduces the amount of code external parsing scripts
need to provide to properly parse iptables-save output.
ip6tables-save already does the right thing, so no change there.
Signed-off-by: Jan Engelhardt <jengelh@computergmbh.de>
|
|
|
|
|
|
|
| |
Rename libipt_{time,u32}.man to libxt_{time,u32}.man to go
in line with the C files.
Signed-off-by: Jan Engelhardt <jengelh@computergmbh.de>
|
|
|
|
|
|
| |
Fix a typo in call to check_inverse().
Signed-off-by: Jan Engelhardt <jengelh@computergmbh.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixing a make/compile issue with iptables, release candidate 1.4.0rc1,
which has existed since SVN changeset 6920. This patch adds ip_tables.h
and ip6_tables.h, and updates x_tables.h, taken from Linus'es git tree.
Changeset 6920 added the include file x_tables.h from kernel source, but
didn't add ip_tables.h and ip6_tables.h.
At some point (Tue Nov 14 19:48:48 2006, by Yasuyuki Kozakai) these
kernel headers where changed, which actually removes certain
depencencies from ip_tables.h and ip6_tables.h to x_tables.h.
If compiling will fail, with old kernel headers (ip_tables.h and
ip6_tables.h) available in systems include path, because they depend on
certaine defines in x_tables.h with is missing in the version in SVN.
Jesper Brouer <jdb@comx.dk>
|