comments about ip_conntrack_in function

comments about ip_conntrack_in function

[Pablo Neira]

Hi Harald and list,

Having a look at the ip_conntrack_in function (please, see below), I 
noticed that:

a) I didn't find any helper that returns -1.

b) I didn't find a function proto->packet (which actually calls its 
respective protocol specific function) that returns NF_DROP. So the 
condition alike(NF_DROP) is always true. In fact, all the functions that 
I had a look at return -1 and NF_ACCEPT.

So, is considering that proto->packet is always going to return 
NF_ACCEPT and -1 an invalid assumption? Maybe the possible return values 
of this function could be restricted a bit more.
Anyway, in which case does returning NF_DROP make sense here?.

c) I don't know so much about the set_bit function and its 
implementation but, while setting the status of a conntrack already 
inserted, don't we need to write_lock the conntrack hash table?

--- snipped from ip_conntrack_in() ------
...
        ret = proto->packet(ct, *pskb, ctinfo);
        if (ret == -1) {
                /* Invalid */
                nf_conntrack_put((*pskb)->nfct);
                (*pskb)->nfct = NULL;
                return NF_ACCEPT;
        }

        if (ret != NF_DROP && ct->helper) {
                ret = ct->helper->help(*pskb, ct, ctinfo);
                if (ret == -1) {
                        /* Invalid */
                        nf_conntrack_put((*pskb)->nfct);
                        (*pskb)->nfct = NULL;
                        return NF_ACCEPT;
                }
        }
        if (set_reply)
                set_bit(IPS_SEEN_REPLY_BIT, &ct->status);

        return ret;

-------- end ------------

best regards,
Pablo

Re: comments about ip_conntrack_in function

[Pablo Neira]

Pablo Neira wrote:

> c) I don't know so much about the set_bit function and its 
> implementation but, while setting the status of a conntrack already 
> inserted, don't we need to write_lock the conntrack hash table?

please ignore this question.

Pablo