* bug in iptables-restore and "recent" module
@ 2015-02-15 12:31 richard lucassen
2015-02-15 23:08 ` Pascal Hambourg
0 siblings, 1 reply; 8+ messages in thread
From: richard lucassen @ 2015-02-15 12:31 UTC (permalink / raw)
To: netfilter
When using the "recent" module and when the hitcount max (defaults to
20) is violated, "iptables-restore" is testing the file OK, but fails
on loading the filter table:
The file "iptables.save" contains the rule (note: "--hitcount 21"
exceeds the default max of 20):
-A INPUT -m state --state NEW -p tcp --dport 443 -m recent --update
--name https --seconds 50 --hitcount 21 -j REJECT
The -t option (test file) shows an OK:
# iptables-restore -t < iptables.save
# echo $?
0
But:
# iptables-restore < iptables.save
iptables-restore: line 180 failed
On line 180 there is the "COMMIT" of the filter table.
Distro: Debian testing
# iptables --version
iptables v1.4.21
R.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.
+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
+------------------------------------------------------------------+
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: bug in iptables-restore and "recent" module
2015-02-15 12:31 bug in iptables-restore and "recent" module richard lucassen
@ 2015-02-15 23:08 ` Pascal Hambourg
2015-02-16 22:53 ` richard lucassen
0 siblings, 1 reply; 8+ messages in thread
From: Pascal Hambourg @ 2015-02-15 23:08 UTC (permalink / raw)
To: netfilter
richard lucassen a écrit :
> When using the "recent" module and when the hitcount max (defaults to
> 20) is violated, "iptables-restore" is testing the file OK, but fails
> on loading the filter table:
>
> The file "iptables.save" contains the rule (note: "--hitcount 21"
> exceeds the default max of 20):
>
> -A INPUT -m state --state NEW -p tcp --dport 443 -m recent --update
> --name https --seconds 50 --hitcount 21 -j REJECT
>
> The -t option (test file) shows an OK:
> But:
>
> # iptables-restore < iptables.save
> iptables-restore: line 180 failed
>
> On line 180 there is the "COMMIT" of the filter table.
That sounds like expected behaviour. Where's the bug ?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: bug in iptables-restore and "recent" module
2015-02-15 23:08 ` Pascal Hambourg
@ 2015-02-16 22:53 ` richard lucassen
2015-02-17 8:52 ` Pascal Hambourg
0 siblings, 1 reply; 8+ messages in thread
From: richard lucassen @ 2015-02-16 22:53 UTC (permalink / raw)
To: netfilter; +Cc: Pascal Hambourg
On Mon, 16 Feb 2015 00:08:41 +0100
Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
> > On line 180 there is the "COMMIT" of the filter table.
>
> That sounds like expected behaviour. Where's the bug ?
I'd say in iptables-restore. Apparently the -t (test) does not notice
that there is a problem while the real iptables-restore does.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.
+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
+------------------------------------------------------------------+
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: bug in iptables-restore and "recent" module
2015-02-16 22:53 ` richard lucassen
@ 2015-02-17 8:52 ` Pascal Hambourg
2015-02-17 11:12 ` Dennis Jacobfeuerborn
2015-02-20 21:05 ` richard lucassen
0 siblings, 2 replies; 8+ messages in thread
From: Pascal Hambourg @ 2015-02-17 8:52 UTC (permalink / raw)
To: netfilter
richard lucassen a écrit :
> On Mon, 16 Feb 2015 00:08:41 +0100
> Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
>
>>> On line 180 there is the "COMMIT" of the filter table.
>> That sounds like expected behaviour. Where's the bug ?
>
> I'd say in iptables-restore. Apparently the -t (test) does not notice
> that there is a problem while the real iptables-restore does.
Sorry, my question was not clear enough. Let me rephrase.
As -t does not commit the tables to the kernel, I do not expect it to
detect errors related to the kernel configuration. So I do not see any
bug in your description, it sounds like expected behaviour to me. Where
do you see a bug in that behaviour ?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: bug in iptables-restore and "recent" module
2015-02-17 8:52 ` Pascal Hambourg
@ 2015-02-17 11:12 ` Dennis Jacobfeuerborn
2015-03-02 7:52 ` richard lucassen
2015-02-20 21:05 ` richard lucassen
1 sibling, 1 reply; 8+ messages in thread
From: Dennis Jacobfeuerborn @ 2015-02-17 11:12 UTC (permalink / raw)
To: Pascal Hambourg, netfilter
On 17.02.2015 09:52, Pascal Hambourg wrote:
> richard lucassen a écrit :
>> On Mon, 16 Feb 2015 00:08:41 +0100
>> Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
>>
>>>> On line 180 there is the "COMMIT" of the filter table.
>>> That sounds like expected behaviour. Where's the bug ?
>>
>> I'd say in iptables-restore. Apparently the -t (test) does not notice
>> that there is a problem while the real iptables-restore does.
>
> Sorry, my question was not clear enough. Let me rephrase.
>
> As -t does not commit the tables to the kernel, I do not expect it to
> detect errors related to the kernel configuration. So I do not see any
> bug in your description, it sounds like expected behaviour to me. Where
> do you see a bug in that behaviour ?
This should probably be mentioned in the man page. Most people would
think that if the ruleset passes a test with -t this means the ruleset
can be activated. Which part specifically of the mentioned rule is it
that cannot be tested without being committed the rule in the kernel?
Regards,
Dennis
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: bug in iptables-restore and "recent" module
2015-02-17 8:52 ` Pascal Hambourg
2015-02-17 11:12 ` Dennis Jacobfeuerborn
@ 2015-02-20 21:05 ` richard lucassen
2015-02-20 21:22 ` Neal Murphy
1 sibling, 1 reply; 8+ messages in thread
From: richard lucassen @ 2015-02-20 21:05 UTC (permalink / raw)
To: netfilter
On Tue, 17 Feb 2015 09:52:54 +0100
Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
> > I'd say in iptables-restore. Apparently the -t (test) does not
> > notice that there is a problem while the real iptables-restore does.
>
> Sorry, my question was not clear enough. Let me rephrase.
>
> As -t does not commit the tables to the kernel, I do not expect it to
> detect errors related to the kernel configuration. So I do not see any
> bug in your description, it sounds like expected behaviour to me.
> Where do you see a bug in that behaviour ?
You have a point :) And I agree with Dennis to add it to the
manpage.
R.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.
+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
+------------------------------------------------------------------+
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: bug in iptables-restore and "recent" module
2015-02-20 21:05 ` richard lucassen
@ 2015-02-20 21:22 ` Neal Murphy
0 siblings, 0 replies; 8+ messages in thread
From: Neal Murphy @ 2015-02-20 21:22 UTC (permalink / raw)
To: netfilter
On Friday, February 20, 2015 04:05:44 PM richard lucassen wrote:
> On Tue, 17 Feb 2015 09:52:54 +0100
>
> Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
> > > I'd say in iptables-restore. Apparently the -t (test) does not
> > > notice that there is a problem while the real iptables-restore does.
> >
> > Sorry, my question was not clear enough. Let me rephrase.
> >
> > As -t does not commit the tables to the kernel, I do not expect it to
> > detect errors related to the kernel configuration. So I do not see any
> > bug in your description, it sounds like expected behaviour to me.
> > Where do you see a bug in that behaviour ?
>
> You have a point :) And I agree with Dennis to add it to the
> manpage.
To state it a little more explicitly:
o '-t' can only validate the syntax; it cannot check the data
o 'the kernel' validates the data
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: bug in iptables-restore and "recent" module
2015-02-17 11:12 ` Dennis Jacobfeuerborn
@ 2015-03-02 7:52 ` richard lucassen
0 siblings, 0 replies; 8+ messages in thread
From: richard lucassen @ 2015-03-02 7:52 UTC (permalink / raw)
To: netfilter; +Cc: Dennis Jacobfeuerborn
On Tue, 17 Feb 2015 12:12:30 +0100
Dennis Jacobfeuerborn <dennisml@conversis.de> wrote:
> > As -t does not commit the tables to the kernel, I do not expect it
> > to detect errors related to the kernel configuration. So I do not
> > see any bug in your description, it sounds like expected behaviour
> > to me. Where do you see a bug in that behaviour ?
>
> This should probably be mentioned in the man page. Most people would
> think that if the ruleset passes a test with -t this means the ruleset
> can be activated. Which part specifically of the mentioned rule is it
> that cannot be tested without being committed the rule in the kernel?
--hitcount
Default is 20 and when --hitcount exceeds this value, "iptables-restore
-t" approves the syntax but the kernel does not accept this value.
R.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.
+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
+------------------------------------------------------------------+
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2015-03-02 7:52 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-15 12:31 bug in iptables-restore and "recent" module richard lucassen
2015-02-15 23:08 ` Pascal Hambourg
2015-02-16 22:53 ` richard lucassen
2015-02-17 8:52 ` Pascal Hambourg
2015-02-17 11:12 ` Dennis Jacobfeuerborn
2015-03-02 7:52 ` richard lucassen
2015-02-20 21:05 ` richard lucassen
2015-02-20 21:22 ` Neal Murphy
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.