Hello shorewall users,
I''m testing the new Events feature in shorewall 4.5.19 (on Arch Linux)
and noticed there are a few things that seem to be amiss:
- in /usr/share/shorewall/action.IfEvent, line 50, it says second, not
seconds (as is documented in the iptables-extensions man page).
- to use SSH limiting as is described in the example on
http://www.shorewall.net/Events.html, I need to define an additional
SSH_BLACKLIST action in /etc/shorewall/actions or shorewall check will
fail with:
ERROR: Unknown ACTION (SSH_BLACKLIST) /usr/share/shorewall/action.IfEvent
- after I add the SSH_BLACKLIST action I get the following warning when
running shorewall check:
Checking /etc/shorewall/action.SSH_BLACKLIST for chain SSH_BLACKLIST...
WARNING: Log Prefix shortened to "Shorewall:SSH_BLACKLIST:LOG: "
/etc/shorewall/action.SSH_BLACKLIST (line 10)
from /usr/share/shorewall/action.IfEvent (line 138)
from /etc/shorewall/action.SSH_LIMIT (line 14)
from /etc/shorewall/rules (line 37)
- shorewall check validates the configuration, but when I do a shorewall
restart I get the following error:
Running /sbin/iptables-restore...
iptables-restore v1.4.19.1: unknown option "--reap"
Error occurred at line: 85
Try `iptables-restore -h'' or ''iptables-restore
--help'' for more information.
ERROR: iptables-restore Failed. Input is in
/var/lib/shorewall/.iptables-restore-input
Processing /etc/shorewall/stop ...
Processing /etc/shorewall/tcclear ...
Running /sbin/iptables-restore...
IPv4 Forwarding Enabled
Processing /etc/shorewall/stopped ...
/usr/share/shorewall/lib.common: line 113: 9618 Terminated
$SHOREWALL_SHELL $script $options $@
The contents of iptables-restore-input are in the attachment.
Anything I can do to work around or fix this?
Best regards,
Tiemen
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
On 07/25/2013 04:33 AM, Tiemen Ruiten wrote:> Hello shorewall users, > > I''m testing the new Events feature in shorewall 4.5.19 (on Arch Linux) > and noticed there are a few things that seem to be amiss: > > - in /usr/share/shorewall/action.IfEvent, line 50, it says second, not > seconds (as is documented in the iptables-extensions man page).Interestingly enough, ''second'' seems to be accepted, at least by iptables 1.4.15.> > - to use SSH limiting as is described in the example on > http://www.shorewall.net/Events.html, I need to define an additional > SSH_BLACKLIST action in /etc/shorewall/actions or shorewall check will > fail with: > > ERROR: Unknown ACTION (SSH_BLACKLIST) /usr/share/shorewall/action.IfEvent > > - after I add the SSH_BLACKLIST action I get the following warning when > running shorewall check: > > Checking /etc/shorewall/action.SSH_BLACKLIST for chain SSH_BLACKLIST... > WARNING: Log Prefix shortened to "Shorewall:SSH_BLACKLIST:LOG: "You can ignore that -- I used the name ''SSH_BLACKLIST'' because that''s what the original web article used.> /etc/shorewall/action.SSH_BLACKLIST (line 10) > from /usr/share/shorewall/action.IfEvent (line 138) > from /etc/shorewall/action.SSH_LIMIT (line 14) > from /etc/shorewall/rules (line 37) > > > - shorewall check validates the configuration, but when I do a shorewall > restart I get the following error: > > Running /sbin/iptables-restore... > iptables-restore v1.4.19.1: unknown option "--reap" > Error occurred at line: 85 > Try `iptables-restore -h'' or ''iptables-restore --help'' for more information. > ERROR: iptables-restore Failed. Input is in > /var/lib/shorewall/.iptables-restore-input > Processing /etc/shorewall/stop ... > Processing /etc/shorewall/tcclear ... > Running /sbin/iptables-restore... > IPv4 Forwarding Enabled > Processing /etc/shorewall/stopped ... > /usr/share/shorewall/lib.common: line 113: 9618 Terminated > $SHOREWALL_SHELL $script $options $@ > > The contents of iptables-restore-input are in the attachment. > > Anything I can do to work around or fix this?Hmmm -- a similar rule works in my configuration (Debian Wheezy with iptables 1.4.15 + xtables-addons), even with ''second'' rather than ''seconds''. If you correct that typo in /usr/share/shorewall/action.IfEvent, does the problem go away? -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
On 07/25/2013 06:33 AM, Tom Eastep wrote:> On 07/25/2013 04:33 AM, Tiemen Ruiten wrote: >> Hello shorewall users, >> >> I''m testing the new Events feature in shorewall 4.5.19 (on Arch Linux) >> and noticed there are a few things that seem to be amiss: >> >> - in /usr/share/shorewall/action.IfEvent, line 50, it says second, not >> seconds (as is documented in the iptables-extensions man page). > Interestingly enough, ''second'' seems to be accepted, at least by > iptables 1.4.15. >> - to use SSH limiting as is described in the example on >> http://www.shorewall.net/Events.html, I need to define an additional >> SSH_BLACKLIST action in /etc/shorewall/actions or shorewall check will >> fail with: >> >> ERROR: Unknown ACTION (SSH_BLACKLIST) /usr/share/shorewall/action.IfEvent >> >> - after I add the SSH_BLACKLIST action I get the following warning when >> running shorewall check: >> >> Checking /etc/shorewall/action.SSH_BLACKLIST for chain SSH_BLACKLIST... >> WARNING: Log Prefix shortened to "Shorewall:SSH_BLACKLIST:LOG: " > You can ignore that -- I used the name ''SSH_BLACKLIST'' because that''s > what the original web article used. > >> /etc/shorewall/action.SSH_BLACKLIST (line 10) >> from /usr/share/shorewall/action.IfEvent (line 138) >> from /etc/shorewall/action.SSH_LIMIT (line 14) >> from /etc/shorewall/rules (line 37) >> >> >> - shorewall check validates the configuration, but when I do a shorewall >> restart I get the following error: >> >> Running /sbin/iptables-restore... >> iptables-restore v1.4.19.1: unknown option "--reap" >> Error occurred at line: 85 >> Try `iptables-restore -h'' or ''iptables-restore --help'' for more information. >> ERROR: iptables-restore Failed. Input is in >> /var/lib/shorewall/.iptables-restore-input >> Processing /etc/shorewall/stop ... >> Processing /etc/shorewall/tcclear ... >> Running /sbin/iptables-restore... >> IPv4 Forwarding Enabled >> Processing /etc/shorewall/stopped ... >> /usr/share/shorewall/lib.common: line 113: 9618 Terminated >> $SHOREWALL_SHELL $script $options $@ >> >> The contents of iptables-restore-input are in the attachment. >> >> Anything I can do to work around or fix this? > Hmmm -- a similar rule works in my configuration (Debian Wheezy with > iptables 1.4.15 + xtables-addons), even with ''second'' rather than > ''seconds''. If you correct that typo in > /usr/share/shorewall/action.IfEvent, does the problem go away?In fact, your same rule works as expected here (please pardon the HTML -- Thunderbird folds long lines in plain text mode): root@gateway:~/iptables-1.4.15/extensions# iptables -N %IfRecent root@gateway:~/iptables-1.4.15/extensions# iptables -N SSH_BLACKLIST root@gateway:~/iptables-1.4.15/extensions# iptables -A %IfRecent -m recent --rcheck --second 120 --reap --hitcount 5 --name SSH --rsource -j SSH_BLACKLIST root@gateway:~/iptables-1.4.15/extensions# -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
On 07/25/2013 03:33 PM, Tom Eastep wrote:> On 07/25/2013 04:33 AM, Tiemen Ruiten wrote: >> Hello shorewall users, >> >> I''m testing the new Events feature in shorewall 4.5.19 (on Arch >> Linux) and noticed there are a few things that seem to be amiss: >> >> - in /usr/share/shorewall/action.IfEvent, line 50, it says >> second, not seconds (as is documented in the iptables-extensions >> man page). > > Interestingly enough, ''second'' seems to be accepted, at least by > iptables 1.4.15. >> >> - to use SSH limiting as is described in the example on >> http://www.shorewall.net/Events.html, I need to define an >> additional SSH_BLACKLIST action in /etc/shorewall/actions or >> shorewall check will fail with: >> >> ERROR: Unknown ACTION (SSH_BLACKLIST) >> /usr/share/shorewall/action.IfEvent >> >> - after I add the SSH_BLACKLIST action I get the following >> warning when running shorewall check: >> >> Checking /etc/shorewall/action.SSH_BLACKLIST for chain >> SSH_BLACKLIST... WARNING: Log Prefix shortened to >> "Shorewall:SSH_BLACKLIST:LOG: " > > You can ignore that -- I used the name ''SSH_BLACKLIST'' because > that''s what the original web article used. > >> /etc/shorewall/action.SSH_BLACKLIST (line 10) from >> /usr/share/shorewall/action.IfEvent (line 138) from >> /etc/shorewall/action.SSH_LIMIT (line 14) from >> /etc/shorewall/rules (line 37) >> >> >> - shorewall check validates the configuration, but when I do a >> shorewall restart I get the following error: >> >> Running /sbin/iptables-restore... iptables-restore v1.4.19.1: >> unknown option "--reap" Error occurred at line: 85 Try >> `iptables-restore -h'' or ''iptables-restore --help'' for more >> information. ERROR: iptables-restore Failed. Input is in >> /var/lib/shorewall/.iptables-restore-input Processing >> /etc/shorewall/stop ... Processing /etc/shorewall/tcclear ... >> Running /sbin/iptables-restore... IPv4 Forwarding Enabled >> Processing /etc/shorewall/stopped ... >> /usr/share/shorewall/lib.common: line 113: 9618 Terminated >> $SHOREWALL_SHELL $script $options $@ >> >> The contents of iptables-restore-input are in the attachment. >> >> Anything I can do to work around or fix this? > > Hmmm -- a similar rule works in my configuration (Debian Wheezy > with iptables 1.4.15 + xtables-addons), even with ''second'' rather > than ''seconds''. If you correct that typo in > /usr/share/shorewall/action.IfEvent, does the problem go away? >Changing line 101 in /usr/share/shorewall/action.IfEvent from $duration .= ''--reap ''; to $duration .= ''''; I can make shorewall compile, but blacklisting doesn''t seem to work. I corrected the second/seconds type as well. I made multiple attempts to login via SSH, unfortunately nothing was logged and no connection attempts were blocked. Should there be an SSH_COUNTER event defined as well?> -Tom >------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
On 07/25/2013 07:02 AM, Tiemen Ruiten wrote:> On 07/25/2013 03:33 PM, Tom Eastep wrote: >> On 07/25/2013 04:33 AM, Tiemen Ruiten wrote: >>> Hello shorewall users, >>> >>> I''m testing the new Events feature in shorewall 4.5.19 (on Arch >>> Linux) and noticed there are a few things that seem to be amiss: >>> >>> - in /usr/share/shorewall/action.IfEvent, line 50, it says >>> second, not seconds (as is documented in the iptables-extensions >>> man page). >> Interestingly enough, ''second'' seems to be accepted, at least by >> iptables 1.4.15. >>> - to use SSH limiting as is described in the example on >>> http://www.shorewall.net/Events.html, I need to define an >>> additional SSH_BLACKLIST action in /etc/shorewall/actions or >>> shorewall check will fail with: >>> >>> ERROR: Unknown ACTION (SSH_BLACKLIST) >>> /usr/share/shorewall/action.IfEvent >>> >>> - after I add the SSH_BLACKLIST action I get the following >>> warning when running shorewall check: >>> >>> Checking /etc/shorewall/action.SSH_BLACKLIST for chain >>> SSH_BLACKLIST... WARNING: Log Prefix shortened to >>> "Shorewall:SSH_BLACKLIST:LOG: " >> You can ignore that -- I used the name ''SSH_BLACKLIST'' because >> that''s what the original web article used. >> >>> /etc/shorewall/action.SSH_BLACKLIST (line 10) from >>> /usr/share/shorewall/action.IfEvent (line 138) from >>> /etc/shorewall/action.SSH_LIMIT (line 14) from >>> /etc/shorewall/rules (line 37) >>> >>> >>> - shorewall check validates the configuration, but when I do a >>> shorewall restart I get the following error: >>> >>> Running /sbin/iptables-restore... iptables-restore v1.4.19.1: >>> unknown option "--reap" Error occurred at line: 85 Try >>> `iptables-restore -h'' or ''iptables-restore --help'' for more >>>>> -Tom >>>>> >>>> ------------------------------------------------------------------------------ >>>> See everything from the browser to the database with AppDynamics >>>> Get end-to-end visibility with application monitoring from AppDynamics >>>> Isolate bottlenecks and diagnose root cause in seconds. >>>> Start your free trial of AppDynamics Pro today! >>>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Shorewall-users mailing list >>>> Shorewall-users@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/shorewall-users >>> information. ERROR: iptables-restore Failed. Input is in >>> /var/lib/shorewall/.iptables-restore-input Processing >>> /etc/shorewall/stop ... Processing /etc/shorewall/tcclear ... >>> Running /sbin/iptables-restore... IPv4 Forwarding Enabled >>> Processing /etc/shorewall/stopped ... >>> /usr/share/shorewall/lib.common: line 113: 9618 Terminated >>> $SHOREWALL_SHELL $script $options $@ >>> >>> The contents of iptables-restore-input are in the attachment. >>> >>> Anything I can do to work around or fix this? >> Hmmm -- a similar rule works in my configuration (Debian Wheezy >> with iptables 1.4.15 + xtables-addons), even with ''second'' rather >> than ''seconds''. If you correct that typo in >> /usr/share/shorewall/action.IfEvent, does the problem go away? >> > Changing line 101 in /usr/share/shorewall/action.IfEvent > from > $duration .= ''--reap ''; > to > > $duration .= '''';The command is valid as released -- if you have to hack up the code to make it work, there is something wrong with your kit.> > I can make shorewall compile, but blacklisting doesn''t seem to work. I > corrected the second/seconds type as well. > > I made multiple attempts to login via SSH, unfortunately nothing was > logged and no connection attempts were blocked. > > Should there be an SSH_COUNTER event defined as well?Yes. Please forward the output of ''shorewall dump'' collected as described at http://www.shorewall.net/support.htm#guidelines Thanks, -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
On 07/25/2013 04:44 PM, Tom Eastep wrote:> On 07/25/2013 07:02 AM, Tiemen Ruiten wrote: >> On 07/25/2013 03:33 PM, Tom Eastep wrote: >>> On 07/25/2013 04:33 AM, Tiemen Ruiten wrote: >>>> Hello shorewall users, >>>> >>>> I''m testing the new Events feature in shorewall 4.5.19 (on Arch >>>> Linux) and noticed there are a few things that seem to be amiss: >>>> >>>> - in /usr/share/shorewall/action.IfEvent, line 50, it says >>>> second, not seconds (as is documented in the iptables-extensions >>>> man page). >>> Interestingly enough, ''second'' seems to be accepted, at least by >>> iptables 1.4.15. >>>> - to use SSH limiting as is described in the example on >>>> http://www.shorewall.net/Events.html, I need to define an >>>> additional SSH_BLACKLIST action in /etc/shorewall/actions or >>>> shorewall check will fail with: >>>> >>>> ERROR: Unknown ACTION (SSH_BLACKLIST) >>>> /usr/share/shorewall/action.IfEvent >>>> >>>> - after I add the SSH_BLACKLIST action I get the following >>>> warning when running shorewall check: >>>> >>>> Checking /etc/shorewall/action.SSH_BLACKLIST for chain >>>> SSH_BLACKLIST... WARNING: Log Prefix shortened to >>>> "Shorewall:SSH_BLACKLIST:LOG: " >>> You can ignore that -- I used the name ''SSH_BLACKLIST'' because >>> that''s what the original web article used. >>> >>>> /etc/shorewall/action.SSH_BLACKLIST (line 10) from >>>> /usr/share/shorewall/action.IfEvent (line 138) from >>>> /etc/shorewall/action.SSH_LIMIT (line 14) from >>>> /etc/shorewall/rules (line 37) >>>> >>>> >>>> - shorewall check validates the configuration, but when I do a >>>> shorewall restart I get the following error: >>>> >>>> Running /sbin/iptables-restore... iptables-restore v1.4.19.1: >>>> unknown option "--reap" Error occurred at line: 85 Try >>>> `iptables-restore -h'' or ''iptables-restore --help'' for more >>>>>> -Tom >>>>>> >>>>> ------------------------------------------------------------------------------ >>>>> See everything from the browser to the database with AppDynamics >>>>> Get end-to-end visibility with application monitoring from AppDynamics >>>>> Isolate bottlenecks and diagnose root cause in seconds. >>>>> Start your free trial of AppDynamics Pro today! >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk >>>>> _______________________________________________ >>>>> Shorewall-users mailing list >>>>> Shorewall-users@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/shorewall-users >>>> information. ERROR: iptables-restore Failed. Input is in >>>> /var/lib/shorewall/.iptables-restore-input Processing >>>> /etc/shorewall/stop ... Processing /etc/shorewall/tcclear ... >>>> Running /sbin/iptables-restore... IPv4 Forwarding Enabled >>>> Processing /etc/shorewall/stopped ... >>>> /usr/share/shorewall/lib.common: line 113: 9618 Terminated >>>> $SHOREWALL_SHELL $script $options $@ >>>> >>>> The contents of iptables-restore-input are in the attachment. >>>> >>>> Anything I can do to work around or fix this? >>> Hmmm -- a similar rule works in my configuration (Debian Wheezy >>> with iptables 1.4.15 + xtables-addons), even with ''second'' rather >>> than ''seconds''. If you correct that typo in >>> /usr/share/shorewall/action.IfEvent, does the problem go away? >>> >> Changing line 101 in /usr/share/shorewall/action.IfEvent >> from >> $duration .= ''--reap ''; >> to >> >> $duration .= ''''; > > The command is valid as released -- if you have to hack up the code to > make it work, there is something wrong with your kit.I agree. Arch is currently at iptables 1.4.19.1, which doesn''t have support for the --reap option. So what is the proper way to fix this/get this fixed?>> >> I can make shorewall compile, but blacklisting doesn''t seem to work. I >> corrected the second/seconds type as well. >> >> I made multiple attempts to login via SSH, unfortunately nothing was >> logged and no connection attempts were blocked. >> >> Should there be an SSH_COUNTER event defined as well? > > Yes. Please forward the output of ''shorewall dump'' collected as > described at http://www.shorewall.net/support.htm#guidelines >I attached the dump. Thank you for your time!> Thanks, > -Tom > >------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
On 07/25/2013 08:24 AM, Tiemen Ruiten wrote:> On 07/25/2013 04:44 PM, Tom Eastep wrote: >> On 07/25/2013 07:02 AM, Tiemen Ruiten wrote: >> I agree. Arch is currently at iptables 1.4.19.1, which doesn''t have >> support for the --reap option. So what is the proper way to fix >> this/get this fixed?Report a simple test case against iptables 1.4.19.1. ''--reap'' is valid where ''--seconds'' is specified. For what it is worth, the 1.4.15 version of libxt_recent.c is identical to the 1.4.19.1 version, so it is hard to understand why the latter fails. As to the dump output, here are the event contents: SSH src=91.213.195.220 : 3145.677, 3141.175, 3102.787, 3085.985, 3081.069, 3078.482, 885.206, 10.630, 7.493, 3.977 src=212.67.x.y : 305.844, 305.808, 303.253 According to the information at the top of the dump, the firewall was reloaded 1556 seconds before the dump was started. Therefore, the first 6 connection events will not be reflected in the iptables rules counts. They are still there because of your issue with ''--reap''. According to this chain, you need 5 hits in 120 seconds to trigger blacklisting: Chain %IfEvent (1 references) pkts bytes target prot opt in out source destination 0 0 SSH_BLACKLIST all -- * * 0.0.0.0/0 0.0.0.0/0 recent: CHECK seconds: 120 hit_count: 5 name: SSH side: source mask: 255.255.255.255 Neither of the sets of connection events shown above will meet those criteria (given that the first 6 packets aren''t relevant). According to this chain, you need two connection attempts within 3 seconds to trigger a reject: Chain %IfEvent1 (1 references) pkts bytes target prot opt in out source destination 1 60 ~log0 all -- * * 0.0.0.0/0 0.0.0.0/0 [goto] recent: UPDATE seconds: 3 hit_count: 1 name: SSH side: source mask: 255.255.255.255 That rule was triggered Jul 25 17:01:41 SSH_LIMIT:Added:IN=eth0 OUT= SRC=212.67.x.y DST=149.210.n.m LEN=60 TOS=0x00 PREC=0x00 TTL=59 ID=27027 DF PROTO=TCP SPT=14225 DPT=22 WINDOW=14600 RES=0x00 SYN URGP=0 So that attempt was rejected. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
On Jul 25, 2013, at 8:24 AM, Tiemen Ruiten <tiemen@dgr.am> wrote:> > I agree. Arch is currently at iptables 1.4.19.1, which doesn''t have > support for the --reap option. So what is the proper way to fix this/get > this fixed?I figured out the problem and created a patch. but when I went to submit it I found that there is already the same patch in the iptables git repository. Whether or not --reap works is dependent on which kernel version you are running. The Arch iptables maintainer can easily get the patch from Git: http://git.netfilter.org/iptables/commit/?id=8cf6fb833840d794289f2abf04b2c5cade5a37bf -Tom Tom Eastep \ Nothing is foolproof to a Shoreline, \ sufficiently talented fool Washington, USA \ http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
On 07/26/2013 01:19 AM, Tom Eastep wrote:> > On Jul 25, 2013, at 8:24 AM, Tiemen Ruiten <tiemen@dgr.am> wrote: > >> >> I agree. Arch is currently at iptables 1.4.19.1, which doesn''t have >> support for the --reap option. So what is the proper way to fix this/get >> this fixed? > > I figured out the problem and created a patch. but when I went to submit it I found that there is already the same patch in the iptables git repository. Whether or not --reap works is dependent on which kernel version you are running. > > The Arch iptables maintainer can easily get the patch from Git: > > http://git.netfilter.org/iptables/commit/?id=8cf6fb833840d794289f2abf04b2c5cade5a37bfThanks for clearing this up, I will submit a report against iptables in the Arch bugtracker.> > -Tom > > Tom Eastep \ Nothing is foolproof to a > Shoreline, \ sufficiently talented fool > Washington, USA \ > http://shorewall.net \________________________________________________ > >------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk