conntrack-tool core dumps

conntrack-tool core dumps

[Wang Jian]

Hi,

When some packets hit the box, conntrack-tool core dumps, below is
backtrace

[root@qos conntrack-tool]# gdb conntrack core.3023 
...
Loaded symbols for extensions/libct_proto_tcp.so
#0  0xb7f1fc2a in strcmp () from /lib/tls/libc.so.6
(gdb) bt
#0  0xb7f1fc2a in strcmp () from /lib/tls/libc.so.6
#1  0x0804aaf8 in findproto (name=0x0) at src/libct.c:429
#2  0x0804a301 in event_handler (sock=0xbffff710, nlh=0xbfffd75c, 
    arg=0xbffff770) at src/libct.c:181
#3  0x0804ae9c in list_conntrack_handler ()
#4  0x0804bb4b in nfnl_listen ()
#5  0x0804b08d in ctnl_event_conntrack ()
#6  0x0804aa82 in event_conntrack () at src/libct.c:413
#7  0x08049d05 in main (argc=3, argv=0xbffff904) at src/conntrack.c:458
(gdb) up
#1  0x0804aaf8 in findproto (name=0x0) at src/libct.c:429
429                     if (strcmp(cur->name, name) == 0) {
(gdb) print cur
$1 = (struct ctproto_handler *) 0xb7fe9b60
(gdb) print name
$2 = 0x0
(gdb) print cur->name
$3 = 0xb7fe89a7 "tcp"




-- 
  lark

Re: conntrack-tool core dumps

[Amin Azez]

Wang, I don't get a core dump. I am happy to compare notes on what we did.

I do note that all of my reported events are:
type: [NEW]
even current connections and closing connections.

At the moment my nfnetlink and ctnetlink kernel modules are the result
of some patches Pablo published and some patches I sent him.

In order to canonicalise my build process against more official sources
and also to check if I get core-dumps when I build the way you
described, I am taking pristine 2.6.11-6 sources and applying the latest
pom-ng's to it to get nfnetlink and ctnetlink.

[later]

This is what I did.
1) untar pristine 2.6.11-6
2) untar latest pom-ng
3) patch pom-ng with first patch from PAblo's message dated 12/4/2005
4) rename ctevent-api to conntrack-event-api
5) pom-ng apply conntrack-event-api and ctnetlink (pom-ng never asked 
about nfnetlink but it seems to have applied)
6) reboot with new kernel, rmmod ip_queue, modprobe ip_conntrack_netlink
7) get latest libctnetlink and libnfnetlink snapshots
8) compile, build and install those
9) rebuild conntrack-tool

It still works fine with no errors.

I'm not looking at Harald's packet accounting that you tipped me on, or 
I will rework what I wrote before against the pom-ng'd versions and use 
Jonas cool Patch2pom tool.

Amin

Wang Jian wrote:
> Hi,
> 
> When some packets hit the box, conntrack-tool core dumps, below is
> backtrace
> 
> [root@qos conntrack-tool]# gdb conntrack core.3023 
> ...
> Loaded symbols for extensions/libct_proto_tcp.so
> #0  0xb7f1fc2a in strcmp () from /lib/tls/libc.so.6
> (gdb) bt
> #0  0xb7f1fc2a in strcmp () from /lib/tls/libc.so.6
> #1  0x0804aaf8 in findproto (name=0x0) at src/libct.c:429
> #2  0x0804a301 in event_handler (sock=0xbffff710, nlh=0xbfffd75c, 
>     arg=0xbffff770) at src/libct.c:181
> #3  0x0804ae9c in list_conntrack_handler ()
> #4  0x0804bb4b in nfnl_listen ()
> #5  0x0804b08d in ctnl_event_conntrack ()
> #6  0x0804aa82 in event_conntrack () at src/libct.c:413
> #7  0x08049d05 in main (argc=3, argv=0xbffff904) at src/conntrack.c:458
> (gdb) up
> #1  0x0804aaf8 in findproto (name=0x0) at src/libct.c:429
> 429                     if (strcmp(cur->name, name) == 0) {
> (gdb) print cur
> $1 = (struct ctproto_handler *) 0xb7fe9b60
> (gdb) print name
> $2 = 0x0
> (gdb) print cur->name
> $3 = 0xb7fe89a7 "tcp"
> 
> 
> 
> 

Re: conntrack-tool core dumps

[Wang Jian]

Hi Amin Azez,

I am now very regret that I deleted all of core dumps. I get 4 core
dumps and now I can't duplicate core dump in 6 hours. I should use the
core dumps to get more information :(


On Mon, 18 Apr 2005 16:35:14 +0100, Amin Azez <azez@ufomechanic.net> wrote:

> Wang, I don't get a core dump. I am happy to compare notes on what we did.
> 
> I do note that all of my reported events are:
> type: [NEW]
> even current connections and closing connections.
> 

This is not the case in my side. For example:

type: [NEW] src=192.168.0.123 dst=64.4.21.188 sport=2580 dport=80 src=64.4.21.188 dst=192.168.0.123 sport=80 dport=2580 timeout:10 tcp 6
type: [DESTROY] src=192.168.0.123 dst=64.4.21.188 sport=2580 dport=80 src=64.4.21.188 dst=192.168.0.123 sport=80 dport=2580 timeout:10 

There is problem to create whole sessions record from events. event
messages should carry necessary information for correlation


> At the moment my nfnetlink and ctnetlink kernel modules are the result
> of some patches Pablo published and some patches I sent him.
> 
> In order to canonicalise my build process against more official sources
> and also to check if I get core-dumps when I build the way you
> described, I am taking pristine 2.6.11-6 sources and applying the latest
> pom-ng's to it to get nfnetlink and ctnetlink.
> 
> [later]
> 
> This is what I did.
> 1) untar pristine 2.6.11-6

I am using pristine 2.6.11.

> 2) untar latest pom-ng

I use pom-ng from head of trunk (r3880).

> 3) patch pom-ng with first patch from PAblo's message dated 12/4/2005
> 4) rename ctevent-api to conntrack-event-api
> 5) pom-ng apply conntrack-event-api and ctnetlink (pom-ng never asked 
> about nfnetlink but it seems to have applied)

# ./pppp conntrack-event-api nfnetlink ctnetlink

pppp is a wrapper script which defines kernel and itpables dir

> 6) reboot with new kernel, rmmod ip_queue, modprobe ip_conntrack_netlink
> 7) get latest libctnetlink and libnfnetlink snapshots

I use libnfnetlink and libctnetlink from head of trunk (r3880)

> 8) compile, build and install those
> 9) rebuild conntrack-tool

I did some trivial tweak 

diff -ur conntrack-tool/Makefile conntrack-tool.new/Makefile
--- conntrack-tool/Makefile     2005-04-13 07:47:31.000000000 +0800
+++ conntrack-tool.new/Makefile 2005-04-19 00:37:54.000000000 +0800
@@ -1,11 +1,11 @@
-LINKOPTS=-ldl -lnfnetlink -lctnetlink -rdynamic
+LINKOPTS=-ldl -lctnetlink -lnfnetlink -rdynamic
 KERNELDIR=/lib/modules/$(shell uname -r)/build/include/
-CFLAGS=-I${KERNELDIR} -Iinclude/ -g
+CFLAGS=-I${KERNELDIR} -I/home/netfilter/libnfnetlink/ -I/home/netfilter/libctnetlink/ -I/home/linux-2.6.11-w/include -Iinclude/ -g
 
 default:
        ${CC} -c ${CFLAGS} src/conntrack.c -o src/conntrack.o
        ${CC} -c ${CFLAGS} src/libct.c -o src/libct.o
-       ${CC} ${LINKOPTS} src/conntrack.o src/libct.o -o conntrack
+       ${CC} src/conntrack.o src/libct.o -o conntrack ${LINKOPTS} 
        ${MAKE} -C extensions/
 
 clean:
diff -ur conntrack-tool/src/libct.c conntrack-tool.new/src/libct.c
--- conntrack-tool/src/libct.c  2005-04-15 18:10:24.000000000 +0800
+++ conntrack-tool.new/src/libct.c      2005-04-19 00:39:42.000000000 +0800
@@ -323,7 +323,7 @@
        }
 
        /* FIXME: please unify returns values... */
-       if (ctnl_del_conntrack(&cth, tuple, t, id) < 0) {
+       if (ctnl_del_conntrack(&cth, tuple, t) < 0) {
                printf("error del conntrack\n");
                exit(0);
        }
@@ -354,7 +354,7 @@
        ctnl_register_handler(&cth, &h);
 
        /* FIXME!!!! get_conntrack_handler returns -100 */
-       if (ctnl_get_conntrack(&cth, tuple, t, id) != -100) {
+       if (ctnl_get_conntrack(&cth, tuple, t) != -100) {
                printf("error get conntrack\n");
                exit(0);
        }


> 
> It still works fine with no errors.
> 
> I'm not looking at Harald's packet accounting that you tipped me on, or 
> I will rework what I wrote before against the pom-ng'd versions and use 
> Jonas cool Patch2pom tool.
> 
> Amin
> 
> Wang Jian wrote:
> > Hi,
> > 
> > When some packets hit the box, conntrack-tool core dumps, below is
> > backtrace
> > 
> > [root@qos conntrack-tool]# gdb conntrack core.3023 
> > ...
> > Loaded symbols for extensions/libct_proto_tcp.so
> > #0  0xb7f1fc2a in strcmp () from /lib/tls/libc.so.6
> > (gdb) bt
> > #0  0xb7f1fc2a in strcmp () from /lib/tls/libc.so.6
> > #1  0x0804aaf8 in findproto (name=0x0) at src/libct.c:429
> > #2  0x0804a301 in event_handler (sock=0xbffff710, nlh=0xbfffd75c, 
> >     arg=0xbffff770) at src/libct.c:181
> > #3  0x0804ae9c in list_conntrack_handler ()
> > #4  0x0804bb4b in nfnl_listen ()
> > #5  0x0804b08d in ctnl_event_conntrack ()
> > #6  0x0804aa82 in event_conntrack () at src/libct.c:413
> > #7  0x08049d05 in main (argc=3, argv=0xbffff904) at src/conntrack.c:458
> > (gdb) up
> > #1  0x0804aaf8 in findproto (name=0x0) at src/libct.c:429
> > 429                     if (strcmp(cur->name, name) == 0) {
> > (gdb) print cur
> > $1 = (struct ctproto_handler *) 0xb7fe9b60
> > (gdb) print name
> > $2 = 0x0
> > (gdb) print cur->name
> > $3 = 0xb7fe89a7 "tcp"
> > 
> > 
> > 
> > 
> 
> 
> 



-- 
  lark

conntrack session information

[Amin Azez]

Wang Jian wrote:
> There is problem to create whole sessions record from events. event
> messages should carry necessary information for correlation

I'm proposing that we base this session id on a 64 bit counter.
I will also want to adjust conntrack to record the system time at which 
the conntrack was created anyway.

If we also associate with this a serial number, the chances "in normal 
use" that the counter will wrap around with the same system time are 
miniscule.

For most purposes the connection serial number is unique, but the 
associated timestamp makes it historically unique.

Final question, I suppose that ip_conntrack.master references will cause 
the master conntrack (of related conntracks) to hang around until the 
related conntracks have been deleted? Thus, the netlink stuff can report 
the id of the master conntrack when it reports other conntrack info.

Does this sound reasonable to folk? Is this too much overheard per 
conntrack? What bottlenecks are there?

Maybe it would require a cross-cpu counter with serialized access. Is 
there a standard kernel form for this, or do we use spinlocked structs 
or something? Or is a per-cpu counter preferred, combined with a CPU-id?

Amin

Re: conntrack session information

[Wang Jian]

Hi Amin Azez,

It is most easy to use an unique id which will not wrap for quite
sometime, but I think the overhead (size) is too much.

The alternative way to do it is just adding protocol information to
every event message, so the tuple of conntrack is complete. The tuple
will not duplicate during its lifetime, am I wrong? This is enough to
build up the whole session. I assume that two conntracks using the same
tuple are always perfect serialized, in the NEW, DESTROY, NEW, DESTROY
order, not in NEW, NEW, DESTROY, DESTORY order.

If you are using a sql database to store the session, it is easy. If you
are not using sql database, you have to do a little more work but not
big deal.

The tricky issue when building session is that DESTORY message gets lost.
This troubles unique id way as well as tuple way.

On Wed, 20 Apr 2005 13:11:14 +0100, Amin Azez <azez@ufomechanic.net> wrote:

> 
> Wang Jian wrote:
> > There is problem to create whole sessions record from events. event
> > messages should carry necessary information for correlation
> 
> I'm proposing that we base this session id on a 64 bit counter.
> I will also want to adjust conntrack to record the system time at which 
> the conntrack was created anyway.
> 
> If we also associate with this a serial number, the chances "in normal 
> use" that the counter will wrap around with the same system time are 
> miniscule.
> 
> For most purposes the connection serial number is unique, but the 
> associated timestamp makes it historically unique.
> 
> Final question, I suppose that ip_conntrack.master references will cause 
> the master conntrack (of related conntracks) to hang around until the 
> related conntracks have been deleted? Thus, the netlink stuff can report 
> the id of the master conntrack when it reports other conntrack info.
> 
> Does this sound reasonable to folk? Is this too much overheard per 
> conntrack? What bottlenecks are there?
> 
> Maybe it would require a cross-cpu counter with serialized access. Is 
> there a standard kernel form for this, or do we use spinlocked structs 
> or something? Or is a per-cpu counter preferred, combined with a CPU-id?
> 
> Amin
> 



-- 
  lark

Re: conntrack session information

[Amin Azez]

Wang Jian wrote:
> Hi Amin Azez,
> 
> It is most easy to use an unique id which will not wrap for quite
> sometime, but I think the overhead (size) is too much.

4 or 8 bytes per conntrack is small I think.

> The alternative way to do it is just adding protocol information to
> every event message, so the tuple of conntrack is complete. The tuple
> will not duplicate during its lifetime, am I wrong? This is enough to
> build up the whole session. I assume that two conntracks using the same
> tuple are always perfect serialized, in the NEW, DESTROY, NEW, DESTROY
> order, not in NEW, NEW, DESTROY, DESTORY order.

This is so, and /probably/ combined with the contrack creation time will 
make a historically unique id.

> If you are using a sql database to store the session, it is easy. If you
> are not using sql database, you have to do a little more work but not
> big deal.

It is a matter of convenience, not neccessity, and the ease with which 
conntrack(-tool) and other clients can relate conntracks accross 
conntrack events.

> The tricky issue when building session is that DESTORY message gets lost.
> This troubles unique id way as well as tuple way.

When combined with conntrack creation time, this is not a problem either 
way.

How do you feel about conntrack creation time being part of the 
conntrack data?

Sam

> 
> On Wed, 20 Apr 2005 13:11:14 +0100, Amin Azez <azez@ufomechanic.net> wrote:
> 
> 
>>Wang Jian wrote:
>>
>>>There is problem to create whole sessions record from events. event
>>>messages should carry necessary information for correlation
>>
>>I'm proposing that we base this session id on a 64 bit counter.
>>I will also want to adjust conntrack to record the system time at which 
>>the conntrack was created anyway.
>>
>>If we also associate with this a serial number, the chances "in normal 
>>use" that the counter will wrap around with the same system time are 
>>miniscule.
>>
>>For most purposes the connection serial number is unique, but the 
>>associated timestamp makes it historically unique.
>>
>>Final question, I suppose that ip_conntrack.master references will cause 
>>the master conntrack (of related conntracks) to hang around until the 
>>related conntracks have been deleted? Thus, the netlink stuff can report 
>>the id of the master conntrack when it reports other conntrack info.
>>
>>Does this sound reasonable to folk? Is this too much overheard per 
>>conntrack? What bottlenecks are there?
>>
>>Maybe it would require a cross-cpu counter with serialized access. Is 
>>there a standard kernel form for this, or do we use spinlocked structs 
>>or something? Or is a per-cpu counter preferred, combined with a CPU-id?
>>
>>Amin
>>
> 
> 
> 
> 

Re: conntrack session information

[Wang Jian]

Hi Amin Azez,


On Wed, 20 Apr 2005 14:50:05 +0100, Amin Azez <azez@ufomechanic.net> wrote:

> Wang Jian wrote:
> > Hi Amin Azez,
> > 
> > It is most easy to use an unique id which will not wrap for quite
> > sometime, but I think the overhead (size) is too much.
> 
> 4 or 8 bytes per conntrack is small I think.

It is small. But didn't we get size per conntrack cut lately? Then we
add more bytes to it once again?

> 
> > The alternative way to do it is just adding protocol information to
> > every event message, so the tuple of conntrack is complete. The tuple
> > will not duplicate during its lifetime, am I wrong? This is enough to
> > build up the whole session. I assume that two conntracks using the same
> > tuple are always perfect serialized, in the NEW, DESTROY, NEW, DESTROY
> > order, not in NEW, NEW, DESTROY, DESTORY order.
> 
> This is so, and /probably/ combined with the contrack creation time will 
> make a historically unique id.
> 
> > If you are using a sql database to store the session, it is easy. If you
> > are not using sql database, you have to do a little more work but not
> > big deal.
> 
> It is a matter of convenience, not neccessity, and the ease with which 
> conntrack(-tool) and other clients can relate conntracks accross 
> conntrack events.

Agree. But is the pay worthy of the overhead added? I am not the one to
decide here. Best to leave that for Pablo and Harald to decide.

> 
> > The tricky issue when building session is that DESTORY message gets lost.
> > This troubles unique id way as well as tuple way.
> 
> When combined with conntrack creation time, this is not a problem either 
> way.

Even without creation time, I think it it ok now. Just consider the
unclosed [NEW] conntrack is closed when another [NEW] appears.

> 
> How do you feel about conntrack creation time being part of the 
> conntrack data?

I think it is not necessary ;)

> 
> > 
> > On Wed, 20 Apr 2005 13:11:14 +0100, Amin Azez <azez@ufomechanic.net> wrote:
> > 
> > 
> >>Wang Jian wrote:
> >>
> >>>There is problem to create whole sessions record from events. event
> >>>messages should carry necessary information for correlation
> >>
> >>I'm proposing that we base this session id on a 64 bit counter.
> >>I will also want to adjust conntrack to record the system time at which 
> >>the conntrack was created anyway.
> >>
> >>If we also associate with this a serial number, the chances "in normal 
> >>use" that the counter will wrap around with the same system time are 
> >>miniscule.
> >>
> >>For most purposes the connection serial number is unique, but the 
> >>associated timestamp makes it historically unique.
> >>
> >>Final question, I suppose that ip_conntrack.master references will cause 
> >>the master conntrack (of related conntracks) to hang around until the 
> >>related conntracks have been deleted? Thus, the netlink stuff can report 
> >>the id of the master conntrack when it reports other conntrack info.
> >>
> >>Does this sound reasonable to folk? Is this too much overheard per 
> >>conntrack? What bottlenecks are there?
> >>
> >>Maybe it would require a cross-cpu counter with serialized access. Is 
> >>there a standard kernel form for this, or do we use spinlocked structs 
> >>or something? Or is a per-cpu counter preferred, combined with a CPU-id?
> >>
> >>Amin
> >>
> > 
> > 
> > 
> > 
> 



-- 
  lark

Re: conntrack session information

[Amin Azez]

Wang Jian wrote:
> Hi Amin Azez,
> 
> It is most easy to use an unique id which will not wrap for quite
> sometime, but I think the overhead (size) is too much.

4 or 8 bytes per conntrack is small I think.

> The alternative way to do it is just adding protocol information to
> every event message, so the tuple of conntrack is complete. The tuple
> will not duplicate during its lifetime, am I wrong? This is enough to
> build up the whole session. I assume that two conntracks using the same
> tuple are always perfect serialized, in the NEW, DESTROY, NEW, DESTROY
> order, not in NEW, NEW, DESTROY, DESTORY order.

This is so, and /probably/ combined with the contrack creation time will 
make a historically unique id.

> If you are using a sql database to store the session, it is easy. If you
> are not using sql database, you have to do a little more work but not
> big deal.

It is a matter of convenience, not neccessity, and the ease with which 
conntrack(-tool) and other clients can relate conntracks accross 
conntrack events.

> The tricky issue when building session is that DESTORY message gets lost.
> This troubles unique id way as well as tuple way.

When combined with conntrack creation time, this is not a problem either 
way.

How do you feel about conntrack creation time being part of the 
conntrack data?

Sam

> 
> On Wed, 20 Apr 2005 13:11:14 +0100, Amin Azez <azez@ufomechanic.net> wrote:
> 
> 
>>Wang Jian wrote:
>>
>>>There is problem to create whole sessions record from events. event
>>>messages should carry necessary information for correlation
>>
>>I'm proposing that we base this session id on a 64 bit counter.
>>I will also want to adjust conntrack to record the system time at which 
>>the conntrack was created anyway.
>>
>>If we also associate with this a serial number, the chances "in normal 
>>use" that the counter will wrap around with the same system time are 
>>miniscule.
>>
>>For most purposes the connection serial number is unique, but the 
>>associated timestamp makes it historically unique.
>>
>>Final question, I suppose that ip_conntrack.master references will cause 
>>the master conntrack (of related conntracks) to hang around until the 
>>related conntracks have been deleted? Thus, the netlink stuff can report 
>>the id of the master conntrack when it reports other conntrack info.
>>
>>Does this sound reasonable to folk? Is this too much overheard per 
>>conntrack? What bottlenecks are there?
>>
>>Maybe it would require a cross-cpu counter with serialized access. Is 
>>there a standard kernel form for this, or do we use spinlocked structs 
>>or something? Or is a per-cpu counter preferred, combined with a CPU-id?
>>
>>Amin
>>
> 
> 
> 
> 

Re: conntrack-tool core dumps

[Pablo Neira]

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

Wang Jian wrote:
> Hi,
> 
> When some packets hit the box, conntrack-tool core dumps, below is
> backtrace
> 
> [root@qos conntrack-tool]# gdb conntrack core.3023 
> ...
> Loaded symbols for extensions/libct_proto_tcp.so
> #0  0xb7f1fc2a in strcmp () from /lib/tls/libc.so.6
> (gdb) bt
> #0  0xb7f1fc2a in strcmp () from /lib/tls/libc.so.6
> #1  0x0804aaf8 in findproto (name=0x0) at src/libct.c:429
> #2  0x0804a301 in event_handler (sock=0xbffff710, nlh=0xbfffd75c, 
>     arg=0xbffff770) at src/libct.c:181
> #3  0x0804ae9c in list_conntrack_handler ()
> #4  0x0804bb4b in nfnl_listen ()
> #5  0x0804b08d in ctnl_event_conntrack ()
> #6  0x0804aa82 in event_conntrack () at src/libct.c:413
> #7  0x08049d05 in main (argc=3, argv=0xbffff904) at src/conntrack.c:458
> (gdb) up
> #1  0x0804aaf8 in findproto (name=0x0) at src/libct.c:429
> 429                     if (strcmp(cur->name, name) == 0) {
> (gdb) print cur
> $1 = (struct ctproto_handler *) 0xb7fe9b60
> (gdb) print name
> $2 = 0x0
> (gdb) print cur->name
> $3 = 0xb7fe89a7 "tcp"

The patch attached must fix your problem. I'll commit to SVN asap.

--
Pablo

[-- Attachment #2: x --]
[-- Type: text/plain, Size: 500 bytes --]

Index: src/libct.c
===================================================================
--- src/libct.c	(revision 3881)
+++ src/libct.c	(working copy)
@@ -462,6 +462,12 @@
 	struct list_head *i;
 	struct ctproto_handler *cur = NULL, *handler = NULL;
 
+	/* This protocol has no handler, use generic and we are done */
+	if (!name) {
+		handler = &generic_handler;
+		return handler;
+	}
+
 	list_for_each(i, &proto_list) {
 		cur = (struct ctproto_handler *) i;
 		if (strcmp(cur->name, name) == 0) {

Re: conntrack-tool core dumps

[Wang Jian]

Hi Pablo Neira,

The patch looks good. thanks.

BTW, I have tried pom-ng (r3884) conntrack-event-api/, nfnetlink/,
ctnetlink/ and conntrack/, . It works fine.

But conntrack/ + old ctevent-api patch + nfnetlink/ + ctnetlink/ will
receives strange event like

type: [NEW] src=192.168.0.254 dst=192.168.0.123 sport=2937 dport=22 src=192.168.0.123 dst=192.168.0.254 sport=22 dport=2937 status:392 timeout:120 tcp 6 
type: [DESTROY] src=192.168.0.254 dst=192.168.0.123 sport=2937 dport=22 src=192.168.0.123 dst=192.168.0.254 sport=22 dport=2937 status:392 timeout:120 

type: [UPDATE] src=192.168.0.254 dst=192.168.0.123 sport=2937 dport=22 src=192.168.0.123 dst=192.168.0.254 sport=22 dport=2937 status:394 tcp 6 

The strange place is value of status.

So anyone who wants to try should sync to the head now.

On Tue, 19 Apr 2005 12:44:41 +0200, Pablo Neira <pablo@eurodev.net> wrote:

> Wang Jian wrote:
> > Hi,
> > 
> > When some packets hit the box, conntrack-tool core dumps, below is
> > backtrace
> > 
> > [root@qos conntrack-tool]# gdb conntrack core.3023 
> > ...
> > Loaded symbols for extensions/libct_proto_tcp.so
> > #0  0xb7f1fc2a in strcmp () from /lib/tls/libc.so.6
> > (gdb) bt
> > #0  0xb7f1fc2a in strcmp () from /lib/tls/libc.so.6
> > #1  0x0804aaf8 in findproto (name=0x0) at src/libct.c:429
> > #2  0x0804a301 in event_handler (sock=0xbffff710, nlh=0xbfffd75c, 
> >     arg=0xbffff770) at src/libct.c:181
> > #3  0x0804ae9c in list_conntrack_handler ()
> > #4  0x0804bb4b in nfnl_listen ()
> > #5  0x0804b08d in ctnl_event_conntrack ()
> > #6  0x0804aa82 in event_conntrack () at src/libct.c:413
> > #7  0x08049d05 in main (argc=3, argv=0xbffff904) at src/conntrack.c:458
> > (gdb) up
> > #1  0x0804aaf8 in findproto (name=0x0) at src/libct.c:429
> > 429                     if (strcmp(cur->name, name) == 0) {
> > (gdb) print cur
> > $1 = (struct ctproto_handler *) 0xb7fe9b60
> > (gdb) print name
> > $2 = 0x0
> > (gdb) print cur->name
> > $3 = 0xb7fe89a7 "tcp"
> 
> The patch attached must fix your problem. I'll commit to SVN asap.
> 
> --
> Pablo



-- 
  lark