headers
Rusty Russell | 1 Jan 2005 05:57
Picon
Gravatar

[PATCH] netfilter: Fix cleanup in ipt_recent should ipt_registrater_match error

Name: Fix cleanup in ipt_recent should ipt_registrater_match error
Status: Tested under nfsim
Signed-off-by: Rusty Russell <rusty <at> rustcorp.com.au>

When ipt_registrater_match() fails, ipt_recent doesn't remove its proc
entry.  Found by nfsim.

Index: linux-2.6.10-bk1-Netfilter/net/ipv4/netfilter/ipt_recent.c
===================================================================
--- linux-2.6.10-bk1-Netfilter.orig/net/ipv4/netfilter/ipt_recent.c	2005-01-01
12:07:56.364981672 +1100
+++ linux-2.6.10-bk1-Netfilter/net/ipv4/netfilter/ipt_recent.c	2005-01-01 12:11:44.159351664 +1100
 <at>  <at>  -959,7 +959,7  <at>  <at> 
 /* Kernel module initialization. */
 static int __init init(void)
 {
-	int count;
+	int err, count;

 	printk(version);
 #ifdef CONFIG_PROC_FS
 <at>  <at>  -983,7 +983,10  <at>  <at> 
 	if(debug) printk(KERN_INFO RECENT_NAME ": ip_list_hash_size: %d\n",ip_list_hash_size);
 #endif

-	return ipt_register_match(&recent_match);
+	err = ipt_register_match(&recent_match);
+	if (err)
+		remove_proc_entry("ipt_recent", proc_net);
+	return err;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jozsef Kadlecsik | 1 Jan 2005 15:59
Picon

Re: [PATCH] Fix RST handling in ip_conntrack_proto_tcp.c

Hi Martin,

On Fri, 31 Dec 2004, Martin Josefsson wrote:

> Your latest patch contained a change to the RST handling.
> The change was that an RST is ignored if the previous packet was an ACK.
> This is happens all the time. I know it was intended as a fix for the
> SYN - ACK probe - RST sequence but it breaks normal usage. The problem
> is that connections that end with RST never get their state changed and
> are left in ESTABLISHED state with a large timeout.

Ouch!

> The patch below adds a check for
> !test_bit(IPS_ASSURED_BIT, &conntrack->status) so your change will only
> be active for unassured connections. Maybe you have a better idea for
> how to fix both cases.
>
> This patch has been tested by a user that reported the problem on irc
> and it fixes the problem for him. I'm also running it on a machine with
> lots of traffic and it fixes the problem for me as well.
>
> Please make sure something that fixes the problem is submitted fairly
> quickly.

I think your patch should  be submitted immediately. The introduced bug is
too bad to leave it linger on.

> <hint> A tcp-state/windowtracking testcase for nfsim would be great
> </hint> :)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Martin Josefsson | 1 Jan 2005 16:23
Picon

Re: [PATCH] Fix RST handling in ip_conntrack_proto_tcp.c

On Sat, 2005-01-01 at 15:59 +0100, Jozsef Kadlecsik wrote:
> Hi Martin,

Hi Jozsef

> Ouch!

I agree :)

> > Please make sure something that fixes the problem is submitted fairly
> > quickly.
> 
> I think your patch should  be submitted immediately. The introduced bug is
> too bad to leave it linger on.

I'll submit it to Andrew since Davem is on vacation.

> > <hint> A tcp-state/windowtracking testcase for nfsim would be great
> > </hint> :)
> 
> Yep, I got Rusty's message as well :-) Time to dig out the initial tests
> from the old cvs and convert them to nfsim with new cases added.

:) We need more testcases badly, for all sorts of things.

--

-- 
/Martin
Permalink | Reply | 2 comments |
headers
Pablo Neira | 1 Jan 2005 22:56

Re: [PATCH 1/2] Versioning (aka release) stuff for iptables

Rusty Russell wrote:

>On Sat, 2004-12-25 at 22:31 +0100, Pablo Neira wrote:
>  
>
>>Hi Rusty,
>>
>>I've been working on the versioning stuff last days. I've tested with 
>>the mark target.
>>    
>>
>
>Hi Pablo,
>
>	I've taken your patches and hacked on them again.  I thought for a long
>time about the compatibility question, and decided that we need a kernel
>mechanism for querying versions of things as well.  This makes life much
>easier, as then all versions can register with iptables and it can
>figure out which one to use.
>  
>

I agree, I like your autoprobing version stuff.

>Enclosed is a series of four kernel patches, and one iptables patch:
>
>[...snip...]
>        
>It seems to work here... thoughts?
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pablo Neira | 1 Jan 2005 23:06

Re: [testsuite] ipt_multiport testcase

Samuel Jean wrote:

># Multiport doesn't support invert nor complains about it. (expecting: answer from rusty)
># Do we still test it Rusty ?
>iptables -I INPUT -p tcp -m multiport ! --source-ports 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
>iptables -D INPUT -p tcp -m multiport ! --source-ports 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
>iptables -I INPUT -p tcp -m multiport ! --destination-ports 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
>iptables -D INPUT -p tcp -m multiport ! --destination-ports 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
>iptables -I INPUT -p tcp -m multiport ! --ports 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
>iptables -D INPUT -p tcp -m multiport ! --ports 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
>  
>

Phil Oester sent a patch to fix this some time ago, see:

https://lists.netfilter.org/pipermail/netfilter-devel/2004-September/016797.html

so it's fixed. BTW, thanks, your testsuites let me same quite some time.

--
Pablo
Permalink | Reply | 0 comments |
headers
Pablo Neira | 1 Jan 2005 23:05

[PATCH] move ipt_error and ipt_standard to iptables.h

Hi,

ipt_error_target, ipt_error and ipt_standard are defined in every table. 
Move these declarations to ip_tables.h where I think they really belongs to.

Please, let me know if there any special reason to duplicate them that way.

Signed-off-by: Pablo Neira Ayuso <pablo <at> eurodev.net>

--
Pablo
Attachment (ipt_error_and_generic_redefinition.patch): text/x-patch, 3416 bytes
Permalink | Reply | 1 comment |
headers
Guillowind | 1 Jan 2005 23:03
Picon
Favicon

Re: string patch for 2.6

Hello,

Perhaps Im going about this the wrong way but Im trying to apply this patch I'd really like to use string patch
for 2.6 kernel.

But I get 
patch -p0 < /usr/src/redhat/SOURCES/kernel-2.6-string.patch
can't find file to patch at input line 4
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -urN patch-o-matic-ng-20041229.orig/string/info patch-o-matic-ng-20041229/string/info
|--- patch-o-matic-ng-20041229.orig/string/info  2004-02-20 01:55:30.000000000 +0200
|+++ patch-o-matic-ng-20041229/string/info   2004-12-30 09:45:42.000000000 +0200
--------------------------
File to patch:

when I attempt this, can anyone clarify the next step for me, if I specify the listed file with a full path,
then I get another error about line 5 concerning the authors name and so on.

I'd like to get new kernels and iptables rpms built with this patch can anyone clarify this for me

Thanks.
Permalink | Reply | 0 comments |
headers
Guillowind | 2 Jan 2005 00:25
Picon
Favicon

Re: string patch for 2.6

Ok, sorry for the spam/confusion

I made another directory called linux-2.6 in the string directory and copied the files from the linux dir
into it then edited the patch to leave out the editing of string/info as it already appeared to have that
information, then repatched with patch -p1 < ../kernel-2.6-string patch and there were no errors.

I ran a make menuconfig for the kernel dir (2.6.10) and it was there, so now Im building the RPMS, Thanks!

Brian Urrutia
RHCE
Permalink | Reply | 0 comments |
headers
Rusty Russell | 2 Jan 2005 00:59
Picon
Gravatar

Re: Is my program is correct to print packet data part at IP layer?

On Fri, 2004-12-31 at 04:13 -0800, linux lover wrote:
> Respected sir,
>             I request you to please check my program
> and reply me whether it is the correct way of getting
> packets data part at IP layer? I am using netfilter
> and dumping its output to unsigned string. I just want
> to know the results return by following program is
> correct or wrong?

Hi,

	The data field may not be linear; it will be in pieces for many
packets.  Also, skb->data will point at the IP header, not the data
within the packet.  I recommend looking at ip_conntrack_ftp which has to
look inside TCP packets, for example.

Good luck!
Rusty.
--

-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman
Permalink | Reply | 0 comments |
headers
Pablo Neira | 2 Jan 2005 01:22

Re: [NEW TARGET] target for modifying conntrack timeout value

Hi Richard,

Richard wrote:

>I drop it and also implemented other suggestions. Here is the latest.
>  
>

I've converted your target to a match because that way we can use 
ctexpire together with NAT actions in the same rule. This was inspired 
by reading ipt_limit. I've done some minor cleanups and a checking to 
make sure that this match is never used in the raw table.

Would like to send to the list a version for patch-o-matic-ng? Then we 
could push it to the SVN repository.

--
Pablo
Attachment (ctexpire-kernel.patch): text/x-patch, 4078 bytes
Attachment (ctexpire-iptables.patch): text/x-patch, 5545 bytes
Permalink | Reply | 6 comments |

Gmane