| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
This patch changes the NETMAP target extension (IPv6 side) to use
the xtables_ip6mask_to_cidr available in libxtables.
As a side effect, we get rid of the libip6tc dependency.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
|
|
|
|
|
|
|
| |
There is an issue on TC_INIT retry path:
In error case, TC_FREE is called and close sockfd.
The retry does not reopen then always fail.
The proposing patch reopens sockfd in retry patch.
Signed-off-by: Miguel GAIO <miguel.gaio@efixo.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By default, Unix-like systems leak file descriptors after fork/exec
call. I think this seem to result in SELinux spotting a strange AVC
log messages according to what I can find on the web.
Fedora 18 iptables source includes this change.
Maciej says:
"iptables does potentially fork/exec modprobe to load modules.
That can cause a selinux 'domain'/'role'/whatever-it-is-called crossing.
You can do automated inspection of what gets carried across such
privilege changes and any unexpected open file descriptors flag
problems, patches like this cut down on the noise."
Signed-off-by: Maciej enczykowski <maze@google.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
|
|
|
|
| |
Fixed a memory leak in the dry run path of function delete_entry().
Signed-off-by: Franz Flasch <franz.flasch@frequentis.com>
Signed-off-by: Christian Engelmayer <christian.engelmayer@frequentis.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
|
|
|
|
| |
Fixed a memory leak in the error path of function cache_add_entry().
Signed-off-by: Franz Flasch <franz.flasch@frequentis.com>
Signed-off-by: Christian Engelmayer <christian.engelmayer@frequentis.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
|
|
|
|
|
| |
This reverts commit d65702c5c5bbab0ef12298386fa4098c72584e6c.
This is breaking my iptables scripts:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables: Incompatible with this kernel.
|
|
|
|
| |
Jan Engelhardt showed no objections to this patch.
|
|\ |
|
| |
| |
| |
| | |
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Command used:
git grep -f <(pcregrep -hior
'(?<=#define\s)IP6?(T_\w+)(?=\s+X\1)' include/)
and then fix all occurrences.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
|
| |
| |
| |
| |
| |
| |
| | |
No real API/ABI change incurred, since the definition of the structs'
types is not visible anyhow.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
|
| |
| |
| |
| | |
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
|
| |
| |
| |
| | |
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
CC libip4tc.lo
In file included from libip4tc.c:118:0:
libiptc.c:70:8: error: redefinition of "struct xt_error_target"
../include/linux/netfilter/x_tables.h:69:8: note: originally defined here
Remove libiptc's duplicate definition and substitute names.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
|
|/
|
|
| |
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libiptc.c:407: dead_error_condition: On this path, the condition
"res > 0" cannot be false.
libiptc.c:396: at_least: After this line, the value of "res" is at
least 1.
libiptc.c:393: equality_cond: Condition "res == 0" is evaluated as
false.
libiptc.c:396: new_values: Noticing condition "res < 0".
libiptc.c:425: new_values: Noticing condition "res < 0".
libiptc.c:407: new_values: Noticing condition "res > 0".
libiptc.c:435: dead_error_line: Execution cannot reach this statement
"return list_pos;".
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
|
|
|
|
|
|
|
|
|
|
| |
These got lost on commit v1.4.11-12-g5c8f5b6.
Note: When /usr/include/libiptc/libiptc.h exists, this error is
masked away :-/ (IMO, #include-with-quotes "foo.h" should not
search system dirs...)
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
|
|
|
|
| |
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gcc-4.6 has a new warning, -Wunused-but-set-variable, which flags
no-op code.
CC libiptc/libip4tc.lo
In file included from libiptc/libip4tc.c:118:0:
libiptc/libiptc.c: In function "iptcc_chain_index_delete_chain":
libiptc/libiptc.c:611:32: warning: variable "index_ptr2" set but not used
libiptc/libiptc.c: In function "alloc_handle":
libiptc/libiptc.c:1282:9: warning: variable "len" set but not used
CC libiptc/libip6tc.lo
In file included from libiptc/libip6tc.c:113:0:
libiptc/libiptc.c: In function "iptcc_chain_index_delete_chain":
libiptc/libiptc.c:611:32: warning: variable "index_ptr2" set but not used
libiptc/libiptc.c: In function "alloc_handle":
libiptc/libiptc.c:1282:9: warning: variable "len" set but not used
CC xtables_multi-iptables-xml.o
iptables-xml.c: In function "do_rule_part":
iptables-xml.c:376:8: warning: variable "thisChain" set but not used
CC xtables_multi-ip6tables.o
ip6tables.c: In function "print_firewall":
ip6tables.c:552:10: warning: variable "flags" set but not used
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
|
|
|
|
| |
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is often useful to check whether a specific rule is already present
in a chain without actually modifying the iptables config.
Services like fail2ban usually employ techniques like grepping through
the output of "iptables -L" which is quite error prone.
This patch adds a new operation -C to the iptables command which
mostly works like -D; it can detect and indicate the existence of the
specified rule by modifying the exit code. The new operation
TC_CHECK_ENTRY uses the same code as the -D operation, whose functions
got a dry-run parameter appended.
Signed-off-by: Stefan Tomanek <stefan.tomanek@wertarbyte.de>
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
|
|
|
|
|
|
| |
"u_int" was a non-standardized extension predating C99 on some platforms.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
|
|
|
|
|
|
|
|
|
| |
Change dump_entry() signature defined in libip4tc.c to match prototype
declared in libiptc.c and another static dump_entry() function defined
in libip6tc.c. This function is not a part of the public libiptc API.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Patrick McHardy <kaber@trash.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a ruleset that does not reset any chain policies/counters, such as
*filter
COMMIT
is sourced by iptables-restore, the previous policy and counters
(i.e. the ones read from the kernel) are reused. The counter skew
offsetting is wrong however, causing the read value to be readded to
the kernel value. This manifests itself in practice by the counter
value almost doubling everytime iptables-restore is called.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In file included from libiptc/libip4tc.c:117:0:
libiptc/libiptc.c: In function ‘__iptcc_p_del_policy’:
libiptc/libiptc.c:826:4: warning: dereferencing type-punned pointer will break
strict-aliasing rules
libiptc/libiptc.c: In function ‘iptc_get_target’:
libiptc/libiptc.c:1650:4: warning: dereferencing type-punned pointer will break
strict-aliasing rules
libiptc/libip4tc.c: In function ‘dump_entry’:
libiptc/libip4tc.c:157:3: warning: dereferencing type-punned pointer will break
strict-aliasing rules
CC libiptc/libip6tc.lo
In file included from libiptc/libip6tc.c:112:0:
libiptc/libiptc.c: In function ‘__iptcc_p_del_policy’:
libiptc/libiptc.c:826:4: warning: dereferencing type-punned pointer will break
strict-aliasing rules
libiptc/libiptc.c: In function ‘ip6tc_get_target’:
libiptc/libiptc.c:1650:4: warning: dereferencing type-punned pointer will break
strict-aliasing rules
libiptc/libip6tc.c: In function ‘dump_entry’:
libiptc/libip6tc.c:188:3: warning: dereferencing type-punned pointer will break
strict-aliasing rules
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix the two warnings in libiptc.c:
CC libiptc/libip4tc.lo
libiptc/libiptc.c:1570:1: warning: ‘iptc_num_rules’ defined but not used
libiptc/libiptc.c:1586:1: warning: ‘iptc_get_rule’ defined but not used
CC libiptc/libip6tc.lo
libiptc/libiptc.c:1570:1: warning: ‘ip6tc_num_rules’ defined but not used
libiptc/libiptc.c:1586:1: warning: ‘ip6tc_get_rule’ defined but not used
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
|
|
|
|
|
|
|
|
| |
Add notes about my scalability work on the library libiptc.
This should make in more obvious who to complain to.
Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
Signed-off-by: Patrick McHardy <kaber@trash.net>
|
|
|
|
|
|
|
| |
Cleanup whitespaces while going through the code.
Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
Signed-off-by: Patrick McHardy <kaber@trash.net>
|
|
|
|
|
|
|
|
|
| |
Chain renaming (TC_RENAME_CHAIN) can result in an unsorted
chain list. That breaks the requirement of the binary search
done in iptcc_bsearch_chain_index().
Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
Signed-off-by: Patrick McHardy <kaber@trash.net>
|
|
|
|
|
|
|
|
| |
iptc_insert_chain is too big to get inlined and so it generates
a warning while compiling.
Signed-off-by: Christoph Paasch <christoph.paasch@gmail.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
|
|
|
|
|
|
|
|
| |
Some libc implementations such as µClibc return NULL on malloc(0).
They are free to do that per C standard.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Signeed-off-by: Patrick McHardy <kaber@trash.net>
|
|
|
|
|
|
|
| |
Get away from this singleton.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Signed-off-by: Patrick McHardy <kaber@trash.net>
|
|
|
|
|
| |
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Signed-off-by: Patrick McHardy <kaber@trash.net>
|
|
|
|
|
| |
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Signed-off-by: Patrick McHardy <kaber@trash.net>
|
|
|
|
|
| |
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Signed-off-by: Patrick McHardy <kaber@trash.net>
|
|
|
|
|
|
|
|
|
|
|
| |
Don't you hate it when iptc_handle_t *x actually is a double-indirection
struct iptc_handle **? This also shows the broken constness model, since
"const iptc_handle_t x" = "iptc_handle_t const x" =
"struct iptc_handle *const x", which is like no const at all.
Lots of things to do then.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Signed-off-by: Patrick McHardy <kaber@trash.net>
|
|
|
|
|
|
|
| |
Chains _are_ sorted, binary search depend on it!
Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
Signed-off-by: Patrick McHardy <kaber@trash.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Finding jump chains is slow O(Chain*Rules).
The problem:
is that the chain list is searched lineary for each rule with a jump
target. The problem lies in the "second pass" (of function
parse_table) where the userchain jump targets are found. For each
rule "R" with a IPTCC_R_JUMP target, function
iptcc_find_chain_by_offset() searches through the chains "C" in the
chain list (worst-case hitting the last one).
The solution:
in this patch is to speed up iptcc_find_chain_by_offset() by using
binary search. Reducing complexity from O(C) to O(log C).
Implementation:
Its possible to use the same bsearch algorithm and data structure
(chain_index), as used for chain name searching.
How is that possible:
One has to realize that the chains are both sorted by name and
offsets, this is because the chains are already sorted in the ruleset
from the kernel.
Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
Signed-off-by: Patrick McHardy <kaber@trash.net>
|
|
|
|
|
|
|
|
| |
Minor bugfix, an extra check is needed if the tail element is a
builtin chain, as builtin chains are not sorted.
Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
Signed-off-by: Patrick McHardy <kaber@trash.net>
|
|
|
|
| |
Signed-off-by: Patrick McHardy <kaber@trash.net>
|
|
|
|
|
|
|
| |
Spotted by Khem Raj <raj.khem@gmail.com>
Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>
Signed-off-by: Patrick McHardy <kaber@trash.net>
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Note: xt_sctp.h is still not merged upstream in the kernel as of
this commit. But a refactoring was really needed.
|
|
|
|
| |
Bugzilla #104
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|