- moves lib_dir to xtables.c
- introduces struct pfinfo which has protocol family dependent infomations.
- unifies load_ip[6]tables_ko() and moves them as load_xtables_ko()
- introduces xt_{match,match_rule,target,tryload} and replaces
ip[6]t_* with them
- unifies following functions and move them to xtables.c
- find_{match,find_target}
- compatible_revision, compatible_{match,target}_revision
- introduces xtables_register_{match,target} and make
register_{match,target}[6] call them. xtables_register_* register ONLY
matches/targets matched protocol family
Some concepts:
- source compatibility for libip[6]t_xxx.c with warning on compilation
not binary compatibility.
- binary compatibility between 2.4/2.6 kernel and iptables/ip6tables,
of cause.
- xtables is enough to support only one address family at runtime.
Then xtables keeps infomations of only the focused address famiy
in struct afinfo.
(which is what iptables-xml generates)
even though the same iptables is re-generated on conversion.
3. A fix for iptables-xml.c so that combining of consecutive targets of
rules with the same match into one XML rule, will not combine over a
terminating action; i.e. there is no point in converting
-A table -p tcp -j DROP
-A table -p tcp -j MARK --set-mark 25
-A table -p tcp -j RETURN
into one XML rule with multiple actions as they are probably not
logically combined in the mind of the author.
Signed-off by: Sam Liddicott <azez@ufomechanic.net>
Yasuyuki KOZAKAI [Sat, 30 Jun 2007 10:47:57 +0000 (10:47 +0000)]
Removes KERNEL_64_USERSPACE_32
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.
Yasuyuki KOZAKAI [Sun, 24 Jun 2007 08:19:25 +0000 (08:19 +0000)]
Fixes build error of conntrack match because of missing ip_conntrack_tuple.h
in linux 2.6.22. It is not needed because nf_conntrack headers can be used
instead.
Yasuyuki KOZAKAI [Mon, 11 Jun 2007 20:17:34 +0000 (20:17 +0000)]
'-p all' and '-p 0' should be allowed. And actually ip6tables in kernel
allows '! -p xxx' where xxx is extension header. It matches all valid IPv6
packets.
Phil Oester [Mon, 30 Apr 2007 00:01:39 +0000 (00:01 +0000)]
In fixing bug #446 [1], the output for unspecified proto was changed from "all" to "0". This reverts to the original behaviour, and closes bugzilla #543. (Phil Oester)
Patrick McHardy [Wed, 10 Jan 2007 13:56:05 +0000 (13:56 +0000)]
Fix greedy debug grep
From Bugzilla #527:
if you have a kernel with say a '-g' in it, then KERNEL_DIR will include the
'-g' in it, CFLAGS will include the '-g' in it, and then the grep will think you
have -g in your CFLAGS
for example, if you use the grsec or gentoo patchset:
$ uname -r
2.6.19.1-grsec
$ uname -r
2.6.19-gentoo-r2
then your CFLAGS will look like:
-O2 -Wall -Wunused -I"/lib/modules/2.6.19.1-grsec/build"/include -Iinclude/
-DIPTABLES_VERSION=\"1.3.7\"
and the greedy check grep will incorrectly flag this:
egrep -e '-g|-pg|IPTC_DEBUG'
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.
Phil Oester [Thu, 20 Jul 2006 16:59:04 +0000 (16:59 +0000)]
Use gcc to build shared objects (Phil Oester <kernel@linuxace.com>)
As suggested by Dmitry Levin and included in Fedora Core releases,
use gcc instead of ld to link shared objects. Fedora rpm notes
refer to this fixing a plugin problem, but does not offer specifics.
But in any event, 'gcc -dumpspecs' does show gcc will pass a number
of parameters which in theory it thinks are better.
Compile tested both with and without NO_SHARED_LIBS.
Phil Oester [Mon, 10 Jul 2006 04:52:56 +0000 (04:52 +0000)]
iptables: handle cidr notation more sanely (Phil Oester <kernel@linuxace.com>)
At present, a command such as
iptables -A foo -s 10.10/16
will interpret 10.10/16 as 10.0.0.10/16, and after applying the mask end
up with 10.0.0.0/16, which likely isn't what the user intended. Yet
some people do expect 10.10 (without the cidr notation) to end up as
10.0.0.10.
The below patch should satisfy all parties. It zero pads the missing
octets only in the cidr case, leaving the IP untouched otherwise.
Phil Oester [Mon, 3 Jul 2006 18:35:24 +0000 (18:35 +0000)]
ip6tables multiport does not support x:y (Phil Oester <kernel@linuxace.com>)
Update the manpage for ip6tables multiport match to reflect
reality -- it does not (yet) support x:y syntax. I looked at
adding it, but adding revision support to ip6tables seems a
waste at this point, since once xtables support is added to
iptables, this problem will resolve itself.
Cleanup a few compile warnings in latest snapshot:
extensions/libipt_dscp_helper.c:69: warning: 'dscp_to_name' defined but not used
extensions/libipt_sctp.c: In function 'print_chunks':
extensions/libipt_sctp.c:465: warning: value computed is not used
extensions/libipt_sctp.c:477: warning: value computed is not used
projects / thirdparty / iptables.git / log
