libnetfilter_conntrack question

libnetfilter_conntrack question

[Phil Dibowitz]

[-- 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 --]

Re: libnetfilter_conntrack question

[Phil Dibowitz]

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

Phil Dibowitz wrote:
> 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:

::sigh::

You can ignore the question. Since inet_ntoa uses static buffers, it was
simply inet_ntoa() overwriting that buffer before the sprintf() was done.

Sorry for the noise.
-- 
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 --]

Re: libnetfilter_conntrack question

[Pablo Neira Ayuso]

Phil Dibowitz wrote:
> 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.

That release is from the Stone age, we've got one more recent, and
you're using the old API, please upgrade. I would also suggest you to
upgrade your kernel, at least to 2.6.18.

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris

Re: libnetfilter_conntrack question

[Phil Dibowitz]

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

Pablo Neira Ayuso wrote:
> Phil Dibowitz wrote:
>> 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.
> 
> That release is from the Stone age, we've got one more recent, and
> you're using the old API, please upgrade. I would also suggest you to
> upgrade your kernel, at least to 2.6.18.
> 

Noted.

Another question - is there a way to get the nfct flags map outside of a
hook? I don't see a way to pull it down, but I could be missing it.

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 --]

Re: libnetfilter_conntrack question

[Pablo Neira Ayuso]

Phil Dibowitz wrote:
> Another question - is there a way to get the nfct flags map outside of a
> hook? I don't see a way to pull it down, but I could be missing it.

Sorry, I don't understand what you mean.

BTW, I suggest you to have a look a new_api_test.c under utils/ to get
quick look on the new API. The old API is deprecated and will vanish
sooner or later, new apps must use the new API.

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris

Re: libnetfilter_conntrack question

[Phil Dibowitz]

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

Pablo Neira Ayuso wrote:
> Phil Dibowitz wrote:
>> Another question - is there a way to get the nfct flags map outside of a
>> hook? I don't see a way to pull it down, but I could be missing it.
> 
> Sorry, I don't understand what you mean.

Inside nfct there is a flags unsigned int that says stuff like "do you have
counters enabled" and various other things. Is there a function I can call
to get it?

For example - if a user requests display of byte/packet counters, I'd like
to be able to check if support for that is in the kernel, if it's not, say
so, throw a message about it, and then continue on rather than figure it out
in a hook and try and save off some data about it so I can handle it later.

> BTW, I suggest you to have a look a new_api_test.c under utils/ to get
> quick look on the new API. The old API is deprecated and will vanish
> sooner or later, new apps must use the new API.

Thakns for the heads up. ..and I just ported my app from
/proc/net/ip_conntrack to libnetfilter-conntrack-0.0.30. Just so I know, do
you plan any other major API changes soon?

Anyway... new_api_test.c does _test_ the API... the only thing I currently
use in my app is

nfct_open()
nfct_register_callback()
nfct_dump_conntrack_table()
nfct_close()

and then in my hook I just go digging through the nfct_conntrack struct for
the data I want.

The struct appears the same. But instead of dump_conntrack, it looks like
I'd call nfct_callback_register() with NFCT_ALL and then nfct_query with
NFCT_Q_DUMP... or am I missing some other change here from a quick glance at
the code?

Thanks again,
-- 
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 --]

NFCT_Q_DUMP problem

[Phil Dibowitz]

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

Pablo Neira Ayuso wrote:
> BTW, I suggest you to have a look a new_api_test.c under utils/ to get
> quick look on the new API. The old API is deprecated and will vanish
> sooner or later, new apps must use the new API.

So I sat down to write some test code today on the new API, and I found all
the nice getter functions, which are awesome... but I can't seem to make the
new API work with NFCT_Q_DUMP. I shrunk down my test the bare minimum and
nfct_query *always* returns errno for "Address family not supported by
protocol" :(

new_api_test.c doesn't test the NFCT_Q_DUMP query, so I'm wondering if it's
perhaps a problem in the NFCT_Q_DUMP query type.

Here's some sample code:

[phil@rider nftest]$ cat minitest.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <libnetfilter_conntrack/libnetfilter_conntrack.h>
#include <libnetfilter_conntrack/libnetfilter_conntrack_tcp.h>

static int conntrack_addcon_hook(enum nf_conntrack_msg_type type,
                        struct nf_conntrack *ct,
                        void *data)
{
        return NFCT_CB_CONTINUE;
}

int main(int argc, char *argv[])
{
        struct nfct_handle *cth;
        struct nf_conntrack *ct;
        int res;

        ct = nfct_new();
        if (!ct) {
                printf("Error, couldn't create and nfct\n");
                exit(1);
        }
        cth = nfct_open(CONNTRACK, 0);
        if (!cth) {
                printf("Error, couldn't open conntrack table\n");
                exit(1);
        }
        nfct_callback_register(cth, NFCT_T_ALL, conntrack_addcon_hook,
				NULL);
        res = nfct_query(cth, NFCT_Q_DUMP, ct);
        if (res < 0) {
                printf("dump failed(%d): %s\n", res, strerror(errno));
        }
        nfct_close(cth);
        return 1;
}


When I run this I get:
  [phil@rider nftest]$ sudo ./minitest
  dump failed(-1): Address family not supported by protocol

-- 
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 --]

Re: NFCT_Q_DUMP problem

[Pablo Neira Ayuso]

Phil Dibowitz wrote:
> Pablo Neira Ayuso wrote:
>> BTW, I suggest you to have a look a new_api_test.c under utils/ to get
>> quick look on the new API. The old API is deprecated and will vanish
>> sooner or later, new apps must use the new API.
> 
> So I sat down to write some test code today on the new API, and I found all
> the nice getter functions, which are awesome... but I can't seem to make the
> new API work with NFCT_Q_DUMP. I shrunk down my test the bare minimum and
> nfct_query *always* returns errno for "Address family not supported by
> protocol" :(
> 
> new_api_test.c doesn't test the NFCT_Q_DUMP query, so I'm wondering if it's
> perhaps a problem in the NFCT_Q_DUMP query type.
> 
> Here's some sample code:
> [...]
>         res = nfct_query(cth, NFCT_Q_DUMP, ct);
                                              ^^^
u_int8_t family = AF_INET;
res = nfct_query(cth, NFCT_Q_DUMP, &family);

Extracted from the API docs:

  * The pointer to data can be a conntrack object or the protocol family
  * depending on the request.
  *
  * For query types:
  *      NFCT_Q_CREATE
  *      NFCT_Q_UPDATE
  *      NFCT_Q_DESTROY
  *      NFCT_Q_GET
  *
  * Pass a valid pointer to a conntrack object.
  *
  * For query types:
  *      NFCT_Q_FLUSH
  *      NFCT_Q_DUMP
  *      NFCT_Q_DUMP_RESET
  *
  * Pass a valid pointer to the protocol family (u_int8_t)

I'm thinking about changing this to use va_list, thus not needing to 
pass &family which is a bit ugly. This is one of the minor nitpicks of 
the new API that I'd like to improve.

BTW, when do you plan to release your application?

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of 
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris

Re: NFCT_Q_DUMP problem

[Phil Dibowitz]

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

Pablo Neira Ayuso wrote:
> u_int8_t family = AF_INET;
> res = nfct_query(cth, NFCT_Q_DUMP, &family);

Whoops, thanks!

> I'm thinking about changing this to use va_list, thus not needing to
> pass &family which is a bit ugly. This is one of the minor nitpicks of
> the new API that I'd like to improve.
> 
> BTW, when do you plan to release your application?

iptstate(8) is already a released and stable piece of software, but a while
back Harald Welte had mentioned I should port it from using
/proc/net/ip_conntrack to "ctnetlink". But at the time ctnetlink was neither
a stable API nor a friendly API nor was it in any common distros.

However libnetfilter_conntrack is in many distros now and is cleaner and
easier to use, and is a (more?) stable API. So I decided to finally make the
switch.

As for when it'll get released... eh... few weeks? The port to the old API
is done, the port to the new API should be done the next time I have an hour
or so, and then I have a few new features pending for this release.

-- 
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 --]

Re: NFCT_Q_DUMP problem

[Pablo Neira Ayuso]

Phil Dibowitz wrote:
> Pablo Neira Ayuso wrote:
>> BTW, when do you plan to release your application?
> 
> iptstate(8) is already a released and stable piece of software, but a while
> back Harald Welte had mentioned I should port it from using
> /proc/net/ip_conntrack to "ctnetlink". But at the time ctnetlink was neither
> a stable API nor a friendly API nor was it in any common distros.

Yes, I had a look at this application time ago but I didn't know that 
you were the author. Just some thoughts, it would be fine to measure the 
performance drop that incurs in a busy firewall, even with the ctnetlink 
interface. An alternative can be to fetch information from conntrackd 
[1], it has a statistics mode (still quite simple) so you could fetch 
the conntrack table from the daemon (userspace) instead of the kernel, 
thus not locking the packet processing, even if it's much better as is 
now with ctnetlink than with the /proc interface.

> However libnetfilter_conntrack is in many distros now and is cleaner and
> easier to use, and is a (more?) stable API. So I decided to finally make the
> switch.
> 
> As for when it'll get released... eh... few weeks? The port to the old API
> is done, the port to the new API should be done the next time I have an hour
> or so, and then I have a few new features pending for this release.

Nice, I was about to propose to the coreteam to include a new section in 
the webpage with third party applications that are not directly 
mantained by us, I think that yours can be candidate, my only concern 
here is the current name of your application, I mean, it is not ugly, 
but ipt_state is a match used by iptables and this can get people 
confused. Just to let you know that, in the same direction, I'm going 
merge 'conntrack' [2] and conntrackd into a package called 
conntrack-tools just to avoid this kind of naming problems.

[1] http://people.netfilter.org/pablo/conntrackd/
[2] http://www.netfilter.org/projects/conntrack/index.html

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of 
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris

Re: NFCT_Q_DUMP problem

[Patrick McHardy]

Phil Dibowitz wrote:
> So I sat down to write some test code today on the new API, and I found all
> the nice getter functions, which are awesome... but I can't seem to make the
> new API work with NFCT_Q_DUMP. I shrunk down my test the bare minimum and
> nfct_query *always* returns errno for "Address family not supported by
> protocol" :(
> 
> new_api_test.c doesn't test the NFCT_Q_DUMP query, so I'm wondering if it's
> perhaps a problem in the NFCT_Q_DUMP query type.
> 
> Here's some sample code:
> 
> [phil@rider nftest]$ cat minitest.c
> [...]
>
> When I run this I get:
>   [phil@rider nftest]$ sudo ./minitest
>   dump failed(-1): Address family not supported by protocol


Works fine for me with latest libnfnetlink/libnetfilter_conntrack.

Re: NFCT_Q_DUMP problem

[Phil Dibowitz]

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

On Thu, Mar 15, 2007 at 01:45:24AM +0100, Patrick McHardy wrote:
> Phil Dibowitz wrote:
> > So I sat down to write some test code today on the new API, and I found all
> > the nice getter functions, which are awesome... but I can't seem to make the
> > new API work with NFCT_Q_DUMP. I shrunk down my test the bare minimum and
> > nfct_query *always* returns errno for "Address family not supported by
> > protocol" :(
> > 
> > new_api_test.c doesn't test the NFCT_Q_DUMP query, so I'm wondering if it's
> > perhaps a problem in the NFCT_Q_DUMP query type.
> > 
> > Here's some sample code:
> > 
> > [phil@rider nftest]$ cat minitest.c
> > [...]
> >
> > When I run this I get:
> >   [phil@rider nftest]$ sudo ./minitest
> >   dump failed(-1): Address family not supported by protocol
> 
> 
> Works fine for me with latest libnfnetlink/libnetfilter_conntrack.

Pablo's email that I was calling nfct_query() wrong (the last arguement
changes depending on the 2nd arguement), was the problem. Once I fixed that,
it worked.

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: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: libnetfilter_conntrack question

[Phil Dibowitz]

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

Pablo Neira Ayuso wrote:
> Phil Dibowitz wrote:
>> Another question - is there a way to get the nfct flags map outside of a
>> hook? I don't see a way to pull it down, but I could be missing it.
> 
> Sorry, I don't understand what you mean.

Pablo, et al,

In the new API the flags bitmap I mentioned above is gone.

What's the "right" way to determine stuff like (flags & NFCT_COUNTERS_ORIG)?
It used to get passed into the callback in the old API, but no longer does.

Thanks again for all your help!
-- 
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 --]

Re: libnetfilter_conntrack question

[Pablo Neira Ayuso]

Phil Dibowitz wrote:
> In the new API the flags bitmap I mentioned above is gone.
> 
> What's the "right" way to determine stuff like (flags & NFCT_COUNTERS_ORIG)?
> It used to get passed into the callback in the old API, but no longer does.

There is a nfct_attr_is_set(...) function to check if an attribute is 
set or not.

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of 
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris

Re: libnetfilter_conntrack question

[Phil Dibowitz]

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

Pablo Neira Ayuso wrote:
> Phil Dibowitz wrote:
>> In the new API the flags bitmap I mentioned above is gone.
>>
>> What's the "right" way to determine stuff like (flags &
>> NFCT_COUNTERS_ORIG)?
>> It used to get passed into the callback in the old API, but no longer
>> does.
> 
> There is a nfct_attr_is_set(...) function to check if an attribute is
> set or not.

Ah. Perfect. Thanks.

One other question - I noticed that I can't seem to delete ICMP states. This
is true both from my own code, as well as from conntrack(8):

[phil@rider libnetfilter_conntrack]$ sudo grep icmp /proc/net/ip_conntrack
icmp     1 29 src=10.1.1.2 dst=209.40.128.125 type=8 code=0 id=43603
[UNREPLIED] src=209.40.128.125 dst=10.1.1.2 type=0 code=0 id=43603 use=1

[phil@rider libnetfilter_conntrack]$ sudo conntrack -D conntrack  -s
10.1.1.2 -d 209.40.128.125 -p icmp --icmp-type 8 --icmp-code 0
NFNETLINK answers: No such file or directory
Operation failed: such conntrack doesn't exist

I get the same thing either way - that the conntrack doesn't exist. I can
delete TCP and UDP just fine, but not ICMP. And just for clarity, yes, I'm
attempting to delete it before it expires (this is easy to check by keeping
iptstate running in a window).

Am I doing something wrong, or can you not delete ICMP states?

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 --]

Re: libnetfilter_conntrack question

[Patrick McHardy]

Phil Dibowitz wrote:
> One other question - I noticed that I can't seem to delete ICMP states. This
> is true both from my own code, as well as from conntrack(8):
> 
> [phil@rider libnetfilter_conntrack]$ sudo grep icmp /proc/net/ip_conntrack
> icmp     1 29 src=10.1.1.2 dst=209.40.128.125 type=8 code=0 id=43603
> [UNREPLIED] src=209.40.128.125 dst=10.1.1.2 type=0 code=0 id=43603 use=1
> 
> [phil@rider libnetfilter_conntrack]$ sudo conntrack -D conntrack  -s
> 10.1.1.2 -d 209.40.128.125 -p icmp --icmp-type 8 --icmp-code 0
> NFNETLINK answers: No such file or directory
> Operation failed: such conntrack doesn't exist
> 
> I get the same thing either way - that the conntrack doesn't exist. I can
> delete TCP and UDP just fine, but not ICMP. And just for clarity, yes, I'm
> attempting to delete it before it expires (this is easy to check by keeping
> iptstate running in a window).
> 
> Am I doing something wrong, or can you not delete ICMP states?


I think you have to specify --icmp-id as well, otherwise the tuple is
incomplete.