All of lore.kernel.org
 help / color / mirror / Atom feed
From: Duncan Roe <duncan_roe@optusnet.com.au>
To: Florian Westphal <fw@strlen.de>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>,
	Netfilter Development <netfilter-devel@vger.kernel.org>
Subject: Re: Documentation question (verdicts)
Date: Sat, 7 Dec 2019 22:49:09 +1100	[thread overview]
Message-ID: <20191207114909.GA928@dimstar.local.net> (raw)
In-Reply-To: <20191207111645.GB795@breakpoint.cc>

On Sat, Dec 07, 2019 at 12:16:45PM +0100, Florian Westphal wrote:
> Duncan Roe <duncan_roe@optusnet.com.au> wrote:
> > Hi Pablo,
> >
> > On Mon, Dec 02, 2019 at 09:26:23PM +1100, Duncan Roe wrote:
> > > Hi Pablo,
> > >
> > > Queue handling [DEPRECATED] in libnetfilter_queue.c documents these 3:
> > >
> > > > 278  *   - NF_ACCEPT the packet passes, continue iterations
> > > > 281  *   - NF_REPEAT iterate the same cycle once more
> > > > 282  *   - NF_STOP accept, but don't continue iterations
> > >
> > > In my tests, NF_REPEAT works as documented - the input hook presents the packet
> > > a second time. But, contrary to the above, the packet does not show again
> > > after NF_ACCEPT.
> > >
> > > Is that expected behaviour nowadays?
> > >
> > > And if so, does that make NF_STOP redundant?
> > >
> > > BTW if you'd like to try it, my test program nfq6 is a subdirectory at
> > > https://github.com/duncan-roe/nfq (nfq itself is an ad blocker).
> > >
> > > Cheers ... Duncan.
> >
> > Specifically I need to know whether to document NF_STOP as obsolete (same as
> > NF_ACCEPT).
>
> They are not the same.  STOP calls the okfn directly so packet will be
> done with the hook location.  NF_ACCEPT moves on to the next hook.
>
> table ip raw {
>         chain p1 {
>                 type filter hook prerouting priority -1000; policy accept;
>                 ip protocol icmp queue num 0 bypass
>         }
>
>         chain p2 {
>                 type filter hook prerouting priority filter; policy accept;
>                 ip protocol icmp meta mark 0x0000002a counter
>         }
> }
>
> If nfqueue tool sets mark 42 and ACCEPT, the counter will increment.
> If it uses STOP, the prerouting hook processing ends immediately
> and the packet will continue stack traversal, all further prerouting
> base chains are skipped.
>
> It will eventually appear in forward or input.

Thanks Florian.

So are you saying that the existing documentation:
> NF_STOP accept, but don't continue iterations
can be more clearly expressed by something like:
> NF_STOP accept, but skip any further base chains using the current hook
?

Cheers ... Duncan.

  reply	other threads:[~2019-12-07 11:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-02 10:26 Documentation question (verdicts) Duncan Roe
2019-12-07  1:28 ` Duncan Roe
2019-12-07 11:16   ` Florian Westphal
2019-12-07 11:49     ` Duncan Roe [this message]
2019-12-07 11:52       ` Florian Westphal

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=20191207114909.GA928@dimstar.local.net \
    --to=duncan_roe@optusnet.com.au \
    --cc=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@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.