Documentation question (verdicts)

Documentation question (verdicts)

[Duncan Roe]

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.

Re: Documentation question (verdicts)

[Duncan Roe]

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).

Cheers ... Duncan.

Re: Documentation question (verdicts)

[Florian Westphal]

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.

Re: Documentation question (verdicts)

[Duncan Roe]

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.

Re: Documentation question (verdicts)

[Florian Westphal]

Duncan Roe <duncan_roe@optusnet.com.au> wrote:
> 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
> ?

Yes, thats right.