All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira <pablo@eurodev.net>
To: netfilter-devel@lists.netfilter.org,
	Harald Welte <laforge@netfilter.org>
Subject: comments about ip_conntrack_in function
Date: Wed, 03 Mar 2004 01:44:07 +0100	[thread overview]
Message-ID: <40452A57.3060209@eurodev.net> (raw)

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

             reply	other threads:[~2004-03-03  0:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-03  0:44 Pablo Neira [this message]
2004-03-06  0:12 ` comments about ip_conntrack_in function Pablo Neira

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40452A57.3060209@eurodev.net \
    --to=pablo@eurodev.net \
    --cc=laforge@netfilter.org \
    --cc=netfilter-devel@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.