Tim Gardner [Mon, 10 Aug 2015 15:25:20 +0000 (17:25 +0200)]
build: support for Linux 4.2
xt_DNETMAP.c: In function "dnetmap_prefix_destroy":
xt_DNETMAP.c:185:2: error: implicit declaration of function
"remove_proc_entry" [-Werror=implicit-function-declaration]
remove_proc_entry(p->proc_str_data, dnetmap_net->xt_dnetmap);
Neal P. Murphy [Thu, 4 Jun 2015 22:04:42 +0000 (18:04 -0400)]
xt_ACCOUNT: make counters 64-bit wide
The Smoothwall Express traffic stats collector (traffiClogger) does
not handle counter rollovers well and does not perform read&flush.
(Yes, the code is somewhat aged.) To change it to perform read&flush
is non-trivial. Then, it occurred to me that it might be easier to
change ipt_ACCOUNT in xtables-addons to use 64-bit counters,
considering it was designed around single kernel pages.
The following submission counts to at least 100 GB, produces no
obvious kernel gripes, and adjacent counters do not seem to interfere
with each other. Yes, it uses more memory, but RAM costs much less
than bugs that grown out of complex software.
The theory:
- Use two kernel pages for the counters for each group of 256
addresses.
- Change counters to 64-bit.
- Change to __get_free_pages/free_pages, using order=2
(two consecutive pages), and zero both pages.
- Change "%u" to "%llu" as needed.
- Everything else pretty much stays the same.
I also changed tmpbuf to two pages (Justin Case's idea), but I
do not know if that's really necessary.
Adam Butcher [Wed, 3 Sep 2014 13:23:29 +0000 (13:23 +0000)]
xt_pknock: fix pknock in UDP SPA mode
When the PK_CRYPTO pre-processor flag got removed in v1.47.1-2-g66f213e, one of the removal cases was misapplied; the body
of an "#ifndef PK_CRYPTO" was left in rather than the whole section
being removed.
Adam Butcher [Wed, 3 Sep 2014 13:23:29 +0000 (13:23 +0000)]
src: work with typeof
Although not officially supported, we have found that the
xtables-addons modules we are interested in work fine on 3.0.4 with a
slight non-invasive mod to compat_xtables.h.
Jan Engelhardt [Sat, 8 Jun 2013 13:09:43 +0000 (15:09 +0200)]
extensions: resolve compile error when CONFIG_UIDGID_STRICT_TYPE_CHECKS=y
xt_DNETMAP.c: In function "dnetmap_tg_check":
xt_DNETMAP.c:331:16: error: incompatible types when assigning to
type "kuid_t" from type "unsigned int"
xt_DNETMAP.c:332:16: error: incompatible types when assigning to
type "kgid_t" from type "unsigned int"
xt_DNETMAP.c:344:16: error: incompatible types when assigning to
type "kuid_t" from type "unsigned int"
xt_DNETMAP.c:345:16: error: incompatible types when assigning to
type "kgid_t" from type "unsigned int"
xt_condition.c: In function "condition_mt_check":
xt_condition.c:158:24: error: incompatible types when assigning to
type "kuid_t" from type "unsigned int"
xt_condition.c:159:24: error: incompatible types when assigning to
type "kgid_t" from type "unsigned int"
xt_quota2.c: In function "q2_get_counter":
xt_quota2.c:134:18: error: incompatible types when assigning to type
"kuid_t" from type "unsigned int"
xt_quota2.c:135:18: error: incompatible types when assigning to type
"kgid_t" from type "unsigned int"
Dmitry Smirnov [Sun, 2 Jun 2013 08:15:18 +0000 (18:15 +1000)]
build: only scan manpages in extensions/
When using quilt to apply some patch to manpages, files named
libxt_*.man can appear within $srcdir/.pc which will be found by our
find(1) call. Limit the search to $srcdir/extensions to avoid this.
Dmitry Popov [Sun, 5 May 2013 18:05:04 +0000 (20:05 +0200)]
xt_RAWNAT: skb writable part might not include whole L4 header (IPv4 case)
Consider TCP/IPv4 packet with IP options: sizeof(*iph) + sizeof(struct
tcphdr) is not enough to include tcp checksum. It may hurt if this
packet is fragmented.
Therefore, we should use iph->ihl * 4 instead of sizeof(*iph).
Jan Engelhardt [Mon, 12 Nov 2012 18:03:51 +0000 (19:03 +0100)]
Xtables-addons 2.0
I have been thinking quite a while when to drop support for old
versions. The changes in Linux kernel 3.7 in nf_nat prompted me to
make the cut here, to throw out most of the backwards-compatibility
code and start mostly blank. As future kernels will be released and
supported, no doubt will new code to work with those releases be
added.
If you run with an older kernel, continue to use the Xtables-addons
1.x series.
projects / thirdparty / xtables-addons.git / log
