Conntrack & NAT question

Conntrack & NAT question

[KOVACS Krisztian]

  Hi,

  While re-thinking the conntrack entry update facility of ct_sync, I
was thinking on the relation of conntrack entries, their NAT-related
information, and confirmation.

  So, in theory, I think that the tuples of an already confirmed
conntrack entry cannot be changed. Since NAT (usually) changes the reply
tuple, their NAT entries should be constant as well after confirming.
However, I'm having weird things in ct_sync... In theory, ct_sync
replicates confirmed conntrack entries only, so there shouldn't be any
problem if my theory 'confirmed entries have constant tuples' is true.
However, I have somethink like this in the update function:

	[...]

	if (new) {
		memcpy(&ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple, &sct->orig,
		       sizeof(struct ip_conntrack_tuple));
		memcpy(&ct->tuplehash[IP_CT_DIR_REPLY].tuple, &sct->reply,
		       sizeof(struct ip_conntrack_tuple));
	} else {
		CT_SYNC_ASSERT(memcmp(&ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple,
				    &sct->orig, sizeof(sct->orig)) == 0);
		CT_SYNC_ASSERT(memcmp(&ct->tuplehash[IP_CT_DIR_REPLY].tuple,
				    &sct->reply, sizeof(sct->reply)) == 0);
		CT_SYNC_DUMP_TUPLE(&sct->orig);
		CT_SYNC_DUMP_TUPLE(&sct->reply);
	}

	[...]

  The 'new' parameter means we're updating an entry we've just created.
So, unless the entry is new, we check whether the tuples in the update
message are the same as ours. And, unfortunately, I have a few assertion
failed messages in the logs... :(

  Any idea? What am I missing?

-- 
 Regards,
   Krisztian KOVACS

Re: Conntrack & NAT question

[Pablo Neira]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

Hi Krisztian,

KOVACS Krisztian wrote:

>  The 'new' parameter means we're updating an entry we've just created.
>So, unless the entry is new, we check whether the tuples in the update
>message are the same as ours. And, unfortunately, I have a few assertion
>failed messages in the logs... :(
>  
>

maybe this could be related to the initialization of the tuple and 
repl_tuple contained in ct_sync message. I didn't have much time to have 
a look at ct_sync implementation so far, if I'm missing anything, please 
let me know.

regards,
Pablo

[-- Attachment #2: memset.patch --]
[-- Type: text/x-patch, Size: 1232 bytes --]

? memset.patch
Index: Makefile
===================================================================
RCS file: /cvspublic/netfilter-ha/ct_sync/Makefile,v
retrieving revision 1.3
diff -u -r1.3 Makefile
--- Makefile	30 Jan 2004 20:24:26 -0000	1.3
+++ Makefile	15 Jul 2004 14:14:55 -0000
@@ -1,5 +1,5 @@
 # set to your kernel tree
-KERNEL  = /usr/src/linux-ctsync
+KERNEL  = /usr/src/new/linux-2.4.24
 
 # get the Linux architecture. Needed to find proper include file for CFLAGS
 ARCH=$(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ -e s/arm.*/arm/ -e s/sa110/arm/)
Index: ct_sync_main.c
===================================================================
RCS file: /cvspublic/netfilter-ha/ct_sync/ct_sync_main.c,v
retrieving revision 1.30
diff -u -r1.30 ct_sync_main.c
--- ct_sync_main.c	13 Jul 2004 14:53:41 -0000	1.30
+++ ct_sync_main.c	15 Jul 2004 14:14:58 -0000
@@ -164,6 +164,9 @@
 	hdr->resource = CT_SYNC_RES_CONNTRACK;
 	hdr->len = __constant_htons(sizeof(*sct));
 
+	memset(&sct->orig, 0, sizeof(struct ip_conntrack_tuple));
+	memset(&sct->reply, 0, sizeof(struct ip_conntrack_tuple));
+
 	/* copy data from conntrack struct */
 	memcpy(&sct->orig, &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple, 
 		sizeof(sct->orig));

Re: Conntrack & NAT question

[Pablo Neira]

Hi again,

sorry I meant this part:

>RCS file: /cvspublic/netfilter-ha/ct_sync/ct_sync_main.c,v
>retrieving revision 1.30
>diff -u -r1.30 ct_sync_main.c
>--- ct_sync_main.c	13 Jul 2004 14:53:41 -0000	1.30
>+++ ct_sync_main.c	15 Jul 2004 14:14:58 -0000
>@@ -164,6 +164,9 @@
> 	hdr->resource = CT_SYNC_RES_CONNTRACK;
> 	hdr->len = __constant_htons(sizeof(*sct));
> 
>+	memset(&sct->orig, 0, sizeof(struct ip_conntrack_tuple));
>+	memset(&sct->reply, 0, sizeof(struct ip_conntrack_tuple));
>+
> 	/* copy data from conntrack struct */
> 	memcpy(&sct->orig, &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple, 
> 		sizeof(sct->orig));
>  
>

regards,
Pablo

Re: Conntrack & NAT question

[KOVACS Krisztian]

  Hi,

2004-07-15, cs keltezéssel 17:12-kor Pablo Neira ezt írta:
> >  The 'new' parameter means we're updating an entry we've just created.
> >So, unless the entry is new, we check whether the tuples in the update
> >message are the same as ours. And, unfortunately, I have a few assertion
> >failed messages in the logs... :(
> >  
> >
> 
> maybe this could be related to the initialization of the tuple and 
> repl_tuple contained in ct_sync message. I didn't have much time to have 
> a look at ct_sync implementation so far, if I'm missing anything, please 
> let me know.

  I don't think this is a problem here, the two memcpy() calls overwrite
the whole tuples anyway. And the problem is much more rare, it happened
maybe five times an hour on our test system. (Note: the test system did
not have l2drop enabled, that is, broadcast messages on the attached
ethernet segments were received on both nodes. This was already a source
of a couple of problems before, but I thought that problem was solved by
checking if the conntrack entry is active (its timer is initialized),
and not touching it in that case.)

  But thanks for the idea, of course. :)

-- 
 Regards,
   Krisztian KOVACS