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