libnfcontrack weirdness

libnfcontrack weirdness

[Alex Bligh]

I may be doing something stupid here, but I can't seem to get information
on an existing connection through libnfconntrack.

Code extract below. When passed a 4-tuple describing an existing connection,
it prints "Found connection", when passed other stuff, it does not. So
that much is working.

However, no ATTR_ stuff relating to the connection is printed out
except for ATTR_ORIG_PORT_* which are synonyms of what has been
set with nfct_set_attr.

I am having difficulty finding documentation for this, but surely
there must be a way to get the information out from the connection
itself.

-- 
Alex Bligh



/* Get the prenat source port associated with a connection */
u_int16_t getprenatport(struct in_addr * local_addr, struct in_addr * 
remote_addr, int local_port, int remote_port)
{
    struct nfct_handle *h;
    struct nf_conntrack *ct;
    u_int16_t port =0;

    if (NULL == (ct = nfct_new()))
	return 0;

    nfct_set_attr_u8(ct, ATTR_L3PROTO, AF_INET);
    nfct_set_attr_u32(ct, ATTR_IPV4_SRC, *((u_int32_t *)remote_addr));
    nfct_set_attr_u32(ct, ATTR_IPV4_DST, *((u_int32_t *)local_addr));

    nfct_set_attr_u8(ct, ATTR_L4PROTO, IPPROTO_TCP);
    nfct_set_attr_u16(ct, ATTR_PORT_SRC, htons(remote_port));
    nfct_set_attr_u16(ct, ATTR_PORT_DST, htons(local_port));


    h = nfct_open(CONNTRACK, 0);
    if (!h) {
      return 0;
    }

    if (nfct_query(h, NFCT_Q_GET, ct)<0)
      {
        nfct_close(h);
        return 0;
      }

    dolog ("Found connection "
           "ATTR_ORIG_COUNTER_PACKETS=%d "
           "ATTR_REPL_COUNTER_PACKETS=%d "
           "ATTR_REPL_PORT_SRC=%d "
           "ATTR_REPL_PORT_DST=%d "
           "ATTR_ORIG_PORT_SRC=%d "
           "ATTR_ORIG_PORT_DST=%d "
           "ATTR_MASTER_PORT_SRC=%d "
           "ATTR_MASTER_PORT_DST=%d",
           ntohs(nfct_get_attr_u32(ct, ATTR_ORIG_COUNTER_PACKETS)),
           ntohs(nfct_get_attr_u32(ct, ATTR_REPL_COUNTER_PACKETS)),
           ntohs(nfct_get_attr_u16(ct, ATTR_REPL_PORT_SRC)),
           ntohs(nfct_get_attr_u16(ct, ATTR_REPL_PORT_DST)),
           ntohs(nfct_get_attr_u16(ct, ATTR_ORIG_PORT_SRC)),
           ntohs(nfct_get_attr_u16(ct, ATTR_ORIG_PORT_DST)),
           ntohs(nfct_get_attr_u16(ct, ATTR_MASTER_PORT_SRC)),
           ntohs(nfct_get_attr_u16(ct, ATTR_MASTER_PORT_DST))
           );

    port =  ntohs(nfct_get_attr_u16(ct, ATTR_ORIG_PORT_DST));
    nfct_close(h);
    return 0;

}

Re: libnfcontrack weirdness

[Andrew Beverley]

On Mon, 2010-08-02 at 17:20 +0100, Alex Bligh wrote:
> I may be doing something stupid here, but I can't seem to get information
> on an existing connection through libnfconntrack.
> 
> Code extract below. When passed a 4-tuple describing an existing connection,
> it prints "Found connection", when passed other stuff, it does not. So
> that much is working.
> 
> However, no ATTR_ stuff relating to the connection is printed out
> except for ATTR_ORIG_PORT_* which are synonyms of what has been
> set with nfct_set_attr.

You have to use a callback function to read any information back. Before
your nfct_query you should use nfct_callback_register to register a
callback function, which should contain your get_attr calls.

> I am having difficulty finding documentation for this,
>

The documentation is sparse, but there are some good examples in the
utils folder of the source code. Also, api.c is well commented for each
of the functions.

Regards,

Andy

Re: libnfcontrack weirdness

[Pablo Neira Ayuso]

On 02/08/10 20:10, Andrew Beverley wrote:
> The documentation is sparse, but there are some good examples in the
> utils folder of the source code. Also, api.c is well commented for each
> of the functions.

We should convert that documentation in the source code of api.c to
doxygen format. It shouldn't take more than one hour to get it done.
Then, we can put it on the website as we did for libnetfilter_log and
libnetfilter_queue.

If someone feels in the mood to do it, you can have a look at the other
libraries to see how we've done it.

Re: libnfcontrack weirdness

[Jan Engelhardt]

On Monday 2010-08-02 20:45, Pablo Neira Ayuso wrote:

>On 02/08/10 20:10, Andrew Beverley wrote:
>> The documentation is sparse, but there are some good examples in the
>> utils folder of the source code. Also, api.c is well commented for each
>> of the functions.
>
>We should convert that documentation in the source code of api.c to
>doxygen format. It shouldn't take more than one hour to get it done.
>Then, we can put it on the website as we did for libnetfilter_log and
>libnetfilter_queue.

Need a doxygen filter that accepts kdoc?

Re: libnfcontrack weirdness

[Pablo Neira Ayuso]

On 02/08/10 21:10, Jan Engelhardt wrote:
> On Monday 2010-08-02 20:45, Pablo Neira Ayuso wrote:
> 
>> On 02/08/10 20:10, Andrew Beverley wrote:
>>> The documentation is sparse, but there are some good examples in the
>>> utils folder of the source code. Also, api.c is well commented for each
>>> of the functions.
>>
>> We should convert that documentation in the source code of api.c to
>> doxygen format. It shouldn't take more than one hour to get it done.
>> Then, we can put it on the website as we did for libnetfilter_log and
>> libnetfilter_queue.
> 
> Need a doxygen filter that accepts kdoc?

That would be nice.

Re: libnfcontrack weirdness

[Jan Engelhardt]

On Tuesday 2010-08-03 14:43, Pablo Neira Ayuso wrote:
>On 02/08/10 21:10, Jan Engelhardt wrote:
>> On Monday 2010-08-02 20:45, Pablo Neira Ayuso wrote:
>> 
>>> On 02/08/10 20:10, Andrew Beverley wrote:
>>>> The documentation is sparse, but there are some good examples in the
>>>> utils folder of the source code. Also, api.c is well commented for each
>>>> of the functions.
>>>
>>> We should convert that documentation in the source code of api.c to
>>> doxygen format. It shouldn't take more than one hour to get it done.
>>> Then, we can put it on the website as we did for libnetfilter_log and
>>> libnetfilter_queue.
>> 
>> Need a doxygen filter that accepts kdoc?
>
>That would be nice.

repo: git://dev.medozas.de/hxtools
file: libexec/doxygen-kerneldoc-filter

Re: libnfcontrack weirdness

[Andrew Beverley]

On Mon, 2010-08-02 at 20:45 +0200, Pablo Neira Ayuso wrote:
> On 02/08/10 20:10, Andrew Beverley wrote:
> > The documentation is sparse, but there are some good examples in the
> > utils folder of the source code. Also, api.c is well commented for each
> > of the functions.
> 
> We should convert that documentation in the source code of api.c to
> doxygen format. It shouldn't take more than one hour to get it done.
> Then, we can put it on the website as we did for libnetfilter_log and
> libnetfilter_queue.
> 
> If someone feels in the mood to do it, you can have a look at the other
> libraries to see how we've done it.

I'd like to give it a go, but it probably wouldn't be for the next
couple of weeks. I'm keen to get into the documentation side of life,
once I've got a couple of other projects out of the way.

Andy

Re: libnfcontrack weirdness

[Alex Bligh]

--On 2 August 2010 19:10:23 +0100 Andrew Beverley <andy@andybev.com> wrote:

> You have to use a callback function to read any information back. Before
> your nfct_query you should use nfct_callback_register to register a
> callback function, which should contain your get_attr calls.

Thanks. I got this working in the end. However, somewhat bizarrely
the relevant information (the internal port number) in the callback is
returned in ATTR_ORIG_SRC_PORT (etc.), despite this being what is
searched on (the external port number). I am a bit confused by this,
but it seems to work.

>> I am having difficulty finding documentation for this,
>
> The documentation is sparse, but there are some good examples in the
> utils folder of the source code. Also, api.c is well commented for each
> of the functions.

Thanks. Just to give you a clueless newbie's point of view, I was trying
to find either a web page, or a manpage. Doxygen would clearly help
with the latter. Even a README file that explicitly pointed at api.c
if that's where to look (the current reference is somewhat cryptic -
I thought it was to the .h files) would be a lot better than a poke in
the eye.

-- 
Alex Bligh