libnetfilter_conntrack question

[Phil Dibowitz <phil@ipom.com>]

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

Hey folks,

I've been playing with libnetfilter_conntrack, and I quite like where the
interface has come.

I'm having a bit of a problem though, apparently understanding the
nfct_conntrack struct, however.

I have a bit of sample code that registers a callback and then calls
nfct_dump_conntrack_table(). My callback is essentially just:

sprintf(buf,"%s:%d %s:%d %d",
                inet_ntoa(ct->tuple[NFCT_DIR_ORIGINAL].src),
                ct->tuple[NFCT_DIR_ORIGINAL].l4src,
                inet_ntoa(ct->tuple[NFCT_DIR_ORIGINAL].dst),
                ct->tuple[NFCT_DIR_ORIGINAL].l4dst,
                ct->tuple[NFCT_DIR_ORIGINAL].protonum);

The problem is... I always get the same thing for src and dst and sometimes
for l4src/l4dst

In the example above, I get every connection is listed as going from some
internal machine to *itself* but to/from different ports:

If I do ORIGINAL for src and REPLY for dst everything is going from some
internal IP to the same internal IP on the *same port*.

If I set them all to REPLY, I get mostly external IPs with a few internal
IPs, but again, it's all from some IP to that *same* IP.

I even tried ORIGINAL with src and REPLY as src for the destination on a
whim which also gave me all internal addresses.

I've yet to figure out how to pull the source and destination for a given
nfct_conntrack struct.

For what it's worth, I'm using libnetfilter_conntrack 0.0.31 on a 2.6.15.6
kernel (yes, I know, it's a bit old). /proc/net/ip_conntrack shows more
expected data - source and destinations being different.

Any help would be appreciated, thanks.
-- 
Phil Dibowitz                             phil@ipom.com
Open Source software and tech docs        Insanity Palace of Metallica
http://www.phildev.net/                   http://www.ipom.com/

"Never write it in C if you can do it in 'awk';
 Never do it in 'awk' if 'sed' can handle it;
 Never use 'sed' when 'tr' can do the job;
 Never invoke 'tr' when 'cat' is sufficient;
 Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]