----- On Mar 3, 2017, at 5:01 PM, Florian Westphal fw@xxxxxxxxx wrote: > Andreas Schultz <aschultz@xxxxxxxx> wrote: >> ok, somewhat unexpected (or rather undocumented), but I can live >> with that. >> >> I've now experimented with NF_REPEAT to achieve something similar. >> Can I assume that NF_REPEAT should restart the current "netfilter hook*? > > Yes. > >> e.g. when we are somewhere in FILTER FORWARD, it will restart with the >> first rule of that hook? > > It restarts the hook, yes. > >> My experiments show that this works with nft when I don't modify the >> ruleset. However, when I modify the ruleset before returning NF_REPEAT, >> the packet will skip the current hook completely. > > Hmm, that shouldn't happen. > REPEAT should always just re-start the current hook. > If that hook gets deleted (and possibly re-created) while packet was > queued the kernel is supposed to drop the packet. I intentionally created an endless loop with NF_REPEAT. Without the nft modification it goes into the expected loop, but with the nft modification it does not (see below for log). >> I don't modify the chain the packet is currently traversing. I only add >> new chains and modify the vmap. > > The netfilter infrastructure is a layer below nftables/iptables so it > is not even aware of rule set modifications. > >> >> It also appears as if the nft trace infrastructure does not now how to >> >> deal with queues. The above rules lead to this annotated trace output: >> >> >> >> > trace id 10d53daf ip filter client_to_any packet: iif "upstream" oif "ens256" >> >> > ether saddr 00:50:56:96:9b:1c ether daddr 00:0c:29:46:1f:53 ether type ip6 >> >> >> >> That's rule #11... Where is the hit on the queue rule and the return?? >> > >> > No idea, I will have a closer look next week. >> > Glancing at the code it should work just fine. >> >> There might a event buffering issue. I have now sometimes seen the queueing >> trace. At other times the event is lost. So maybe the netlink buffer is not >> large enough? > > How many events are there...? > If there aren't hundreds of events going on that really should not be an > issue. The trace is really just the 10 or so events. Whether the queue event is in there or not seems to be purely random: trace id ed0492b0 ip filter client_to_any packet: iif "upstream" oif "ens256" ether saddr 00:50:56:96:9b:1c ether daddr 00:0c:29:46:1f:53 ether type ip6 trace id ed0492b0 ip filter client_to_any rule nftrace set 1 (verdict continue) trace id ed0492b0 ip filter client_to_any rule counter packets 0 bytes 0 queue num 0 (verdict queue) add chain ip filter CIn_1 add rule ip filter CIn_1 counter name "CIn_1_Session" add rule ip filter CIn_1 ip daddr 172.20.16.0/24 counter packets 0 bytes 0 accept add rule ip filter CIn_1 ip daddr 8.0.0.0/8 counter packets 0 bytes 0 accept add chain ip filter COut_1 add rule ip filter COut_1 counter name "COut_1_Session" add rule ip filter COut_1 ip saddr 172.20.16.0/24 counter packets 0 bytes 0 accept add rule ip filter COut_1 ip saddr 8.0.0.0/8 counter packets 0 bytes 0 accept trace id ed0492b0 ip mangle POSTROUTING verdict continue trace id ed0492b0 ip mangle POSTROUTING Regards Andreas -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
