On Sat, Dec 07, 2019 at 12:16:45PM +0100, Florian Westphal wrote: > Duncan Roe <duncan_roe@xxxxxxxxxxxxxxx> 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.
