ip_conntrack_get

ip_conntrack_get

[pablo neira]

Hi everyone,

I've been for almost two weeks trying to understand netfilter code, at this point 
I'm trying to understand conntrack table code.

I have a problem with how conntrack manages the ip_conntrack_info stuff.

>From ip_conntrack_core.c

398 <http://lxr.linux.no/source/net/ipv4/netfilter/ip_conntrack_core.c#L398> __ip_conntrack_get <http://lxr.linux.no/ident?i=__ip_conntrack_get>(struct nf_ct_info <http://lxr.linux.no/ident?i=nf_ct_info> *nfct, enum ip_conntrack_info <http://lxr.linux.no/ident?i=ip_conntrack_info> *ctinfo)
399 <http://lxr.linux.no/source/net/ipv4/netfilter/ip_conntrack_core.c#L399> {
400 <http://lxr.linux.no/source/net/ipv4/netfilter/ip_conntrack_core.c#L400>         struct ip_conntrack <http://lxr.linux.no/ident?i=ip_conntrack> *ct
401 <http://lxr.linux.no/source/net/ipv4/netfilter/ip_conntrack_core.c#L401>                 = (struct ip_conntrack <http://lxr.linux.no/ident?i=ip_conntrack> *)nfct->master <http://lxr.linux.no/ident?i=master>;

I don't understand that casting at the line 400th/401th.

This is the definition of the structure nf_ct_info:

>From skbuff.h

92 <http://lxr.linux.no/source/include/linux/skbuff.h#L92> struct nf_ct_info <http://lxr.linux.no/ident?i=nf_ct_info> {
93 <http://lxr.linux.no/source/include/linux/skbuff.h#L93>         struct nf_conntrack <http://lxr.linux.no/ident?i=nf_conntrack> *master <http://lxr.linux.no/ident?i=master>;
94 <http://lxr.linux.no/source/include/linux/skbuff.h#L94> };

And the definition of nf_conntrack is:

87 <http://lxr.linux.no/source/include/linux/skbuff.h#L87> struct nf_conntrack <http://lxr.linux.no/ident?i=nf_conntrack> {
88 <http://lxr.linux.no/source/include/linux/skbuff.h#L88>         atomic_t <http://lxr.linux.no/ident?i=atomic_t> use;
89 <http://lxr.linux.no/source/include/linux/skbuff.h#L89>         void (*destroy)(struct nf_conntrack <http://lxr.linux.no/ident?i=nf_conntrack> *);
90 <http://lxr.linux.no/source/include/linux/skbuff.h#L90> };

Actually nf_conntrack doesn't look like ip_conntrack structure anyway.

I also don't understand the way ctinfo is calculate. This stuff...

403 <http://lxr.linux.no/source/net/ipv4/netfilter/ip_conntrack_core.c#L403>         *//* ctinfo is the index of the nfct inside the conntrack *//*
404 <http://lxr.linux.no/source/net/ipv4/netfilter/ip_conntrack_core.c#L404>         *ctinfo = nfct - ct->infos;


Don't blame me if it's obvious for you, I'm just a guy trying to understand a really 
really nice piece of code. Thanks!

cheers,
Pablo

Re: ip_conntrack_get

[Henrik Nordstrom]

On Wed, 12 Nov 2003, pablo neira wrote:

> Actually nf_conntrack doesn't look like ip_conntrack structure anyway.

Well.. it does. If you look closely at ip_conntrack you will notice the 
first member is a nf_conntrack, making ip_conntrack a superset of 
nf_conntrack.

> I also don't understand the way ctinfo is calculate. This stuff...
> 
> 403 <http://lxr.linux.no/source/net/ipv4/netfilter/ip_conntrack_core.c#L403>         *//* ctinfo is the index of the nfct inside the conntrack *//*
> 404 <http://lxr.linux.no/source/net/ipv4/netfilter/ip_conntrack_core.c#L404>         *ctinfo = nfct - ct->infos;

Neither do I.. but then I have never needed to care as ip_conntrack_get()  
and the conntrack core does a good job of hiding the magics in that area.. 
it is probably quite simple reasons behind this odd looking construct.

Regards
Henrik

Re: ip_conntrack_get

[Jesse Peng]

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

Henrik Nordstrom wrote:

>>I also don't understand the way ctinfo is calculate. This stuff...
>>
>>403 <http://lxr.linux.no/source/net/ipv4/netfilter/ip_conntrack_core.c#L403>         *//* ctinfo is the index of the nfct inside the conntrack *//*
>>404 <http://lxr.linux.no/source/net/ipv4/netfilter/ip_conntrack_core.c#L404>         *ctinfo = nfct - ct->infos;
>>    
>>
>
>Neither do I.. but then I have never needed to care as ip_conntrack_get()  
>and the conntrack core does a good job of hiding the magics in that area.. 
>it is probably quite simple reasons behind this odd looking construct.
>
>Regards
>Henrik
>
>
>  
>
Execuse me for the late response,for I thought my colleague would taken 
the responsibility. As I think, just same as me, Pablo must be very 
interested in learning netfilter ;)!

while a new ip_conntrack cache initiates, every member 
infos[i](nf_ct_info structure) then be charged with the same address 
value pointing to the ip_conntrack cache's begining address(it's the 
address of its first member nf_conntrack structure naming ct_general also).

code reference:ip_conntrack_core.c ->init_conntrack ->
for (i=0; i < IP_CT_NUMBER; i++)
conntrack->infos[i].master = &conntrack->ct_general;

either the first packet which initiates the ip_conntrack initiation or 
any subsequent packets belonging to this connection, after 
resolve_normal_ct, will get its member pointer structure nf_ct_info 
naming nfct burned the address pointing to the concerning infos[i](the i 
is right the ctinfo we figure out during resolve_normal_ct, as you know, 
which indecates the relation this packet with its belonging connection).

code reference:ip_conntrack_core.c ->resolve_normal_ct ->
skb->nfct = &h->ctrack->infos[*ctinfo];

ok! now with the address of info[i] the pskb get, we can figure out two 
things.First, following the pointer to its address, with the value it 
keeps, we get the address of the ip_conntrack.Second,following the 
ip_conntrack we can get the address of infos[0],then with 
infos[i]-infos[0](nfct-ct->infos),we get the i, which is right the 
*ctinfo we wanna know!

code reference:ip_conntrack_core.c ->__ip_conntrack_get ->
struct ip_conntrack *ct
= (struct ip_conntrack *)nfct->master; 
-------------------------------------->first

/* ctinfo is the index of the nfct inside the conntrack */
*ctinfo = nfct - ct->infos; -------------------------------------->second

I don't know if this answer your question? if not, it's time to improve 
my English expression ;)!



[-- Attachment #2: Type: text/html, Size: 3464 bytes --]

Re: ip_conntrack_get

[Henrik Nordstrom]

On Tue, 9 Dec 2003, Jesse Peng wrote:

> while a new ip_conntrack cache initiates, every member 
> infos[i](nf_ct_info structure) then be charged with the same address 
> value pointing to the ip_conntrack cache's begining address(it's the 
> address of its first member nf_conntrack structure naming ct_general also).

Right.. now I get why this construct is looking like it does. It is a 
tradeoff "wasting" some space per conntrack to limit the mount of fields 
needed in the skb.

By using this construct both the ctinfo and conntrack can be derived from
a single pointer in the skb.

For systems using conntrack a lot it would be more efficient to extend the
skb with one more field for ctinfo, but as it is good if the skb is the
same regardless if conntrack is enabled or not and this construct is a
good tradeoff.

It is however possible to reduce the size of this construct considerably 
to just one byte per ctinfo.

Thanks
Henrik

Re: ip_conntrack_get

[Jesse Peng]

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

Henrik Nordstrom wrote:

>On Tue, 9 Dec 2003, Jesse Peng wrote:
>
>  
>
>>while a new ip_conntrack cache initiates, every member 
>>infos[i](nf_ct_info structure) then be charged with the same address 
>>value pointing to the ip_conntrack cache's begining address(it's the 
>>address of its first member nf_conntrack structure naming ct_general also).
>>    
>>
>
>Right.. now I get why this construct is looking like it does. It is a 
>tradeoff "wasting" some space per conntrack to limit the mount of fields 
>needed in the skb.
>
>By using this construct both the ctinfo and conntrack can be derived from
>a single pointer in the skb.
>
>For systems using conntrack a lot it would be more efficient to extend the
>skb with one more field for ctinfo, but as it is good if the skb is the
>same regardless if conntrack is enabled or not and this construct is a
>good tradeoff.
>
>It is however possible to reduce the size of this construct considerably 
>to just one byte per ctinfo.
>
>Thanks
>Henrik
>
>  
>
As I never deeply think how this construct can be redesigned, after read 
your insight.. now I begin to figure out why the skbuff.h prevent 
including ip_conntrack.h, and why nf_conntrack defined in skbuff.h

Thanks
Jesse


[-- Attachment #2: Type: text/html, Size: 1570 bytes --]