netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Gao Feng <gfree.wind@foxmail.com>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nf-next v2 1/1] netfilter: SYNPROXY: Return NF_STOLEN instead of NF_DROP during handshaking
Date: Wed, 19 Apr 2017 17:57:42 +0200	[thread overview]
Message-ID: <20170419155742.GA8562@salvia> (raw)
In-Reply-To: <001401d2b4da$dd757ba0$986072e0$@foxmail.com>

On Fri, Apr 14, 2017 at 12:52:05PM +0800, Gao Feng wrote:
> > -----Original Message-----
> > From: netfilter-devel-owner@vger.kernel.org
> > On Fri, Apr 14, 2017 at 07:04:44AM +0800, Gao Feng wrote:
> > > > -----Original Message-----
> > > > From: Pablo Neira Ayuso [mailto:pablo@netfilter.org]
> > > >
> > > > On Wed, Apr 12, 2017 at 10:14:50AM +0800, gfree.wind@foxmail.com
> > wrote:
> > > > >
> > > > > Current SYNPROXY codes return NF_DROP during normal TCP
> > > > > handshaking, it is not friendly to caller. Because the
> > > > > nf_hook_slow would treat the NF_DROP as an error, and return -EPERM.
> > > > > As a result, it may cause the top caller think it meets one error.
> > > > >
> > > > > So use NF_STOLEN instead of NF_DROP now because there is no error
> > > > > happened indeed, and free the skb directly.
> > > >
> > > > Is this really addressing a real problem? How did you reproduce it?
> > >
> > > We defined the NF_DROP and NF_STOLEN, I think we should use them
> > clearly.
> > > When NF_DROP happens, it means one error happened.
> > 
> > That's a valid concern. How did you tested this change?
> 
> The test is a little hacker. The following is my whole test process.
> 1. Add one "print" member in the struct sk_buff; it would be zero by
> default;
> 2. Add one log in the netif_receive_skb_internal 
> +       if (skb->print)
> +               pr_info("skb(%p) ret is %d\n", skb, ret);
> 3. the iptable rule is "iptables -A INPUT -p tcp --dport 12345 -m conntrack
> --ctstate NEW -j SYNPROXY"
> 
> Test NF_DROP with the original codes:
> 1. I comment out the "kfree_skb" in the NF_DROP handler of nf_hook_slow.
> 2. Add one log before return NF_DROP in the synproxy codes
> pr_info("skb(%p) is dropped\n", skb);
> 
> The result is following:
> [   71.765035] skb(ffff9a6208bd7500) is dropped
> [   71.765049] skb(ffff9a6208bd7500) ret is -1
> 
> Test NF_STOLEN with the patch:
> 1. I comment out the "consume_skb" before return NF_STOLEN;
> 2. Add the log before return NF_STOLEN in the synproxy codes
> pr_info("skb(%p) is stolen\n", skb);
> 
> The test result is following:
> [  221.564370] skb(ffff9a01214a8c00) is stolen
> [  221.564383] skb(ffff9a01214a8c00) ret is 0
> 
> To summary, netif_receive_skb would return -EPERM when Netfilter returns
> NF_DROP,
> but NF_STOLEN not.
> For the caller which cares about the return value of netif_receive_skb would
> treat it
> as one error.
> Like cfv_rx_poll() in drivers/net/caif/caif_virtio.c.
>                 err = netif_receive_skb(skb);
>                 if (unlikely(err)) {
>                         ++cfv->ndev->stats.rx_dropped;
>                 } else {
>                         ++cfv->ndev->stats.rx_packets;
>                         cfv->ndev->stats.rx_bytes += skb_len;
>                 }
> It would cause the driver increase the dropped counter.

OK, please resubmit. Thanks.

      reply	other threads:[~2017-04-19 15:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-12  2:14 [PATCH nf-next v2 1/1] netfilter: SYNPROXY: Return NF_STOLEN instead of NF_DROP during handshaking gfree.wind
2017-04-13 21:57 ` Pablo Neira Ayuso
2017-04-13 23:04   ` Gao Feng
2017-04-13 23:11     ` Pablo Neira Ayuso
2017-04-14  4:52       ` Gao Feng
2017-04-19 15:57         ` Pablo Neira Ayuso [this message]

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=20170419155742.GA8562@salvia \
    --to=pablo@netfilter.org \
    --cc=gfree.wind@foxmail.com \
    --cc=netfilter-devel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).