On Thursday 2010-04-01 15:48, Patrick McHardy wrote: >Jan Engelhardt wrote: >> On Thursday 2010-04-01 15:22, Patrick McHardy wrote: >>>>>> Conntrack loops are prevented by using a dummy conntrack, just as >>>>>> NOTRACK does. >>>>> [...] >>>>>> - When the cloned packets gets XFRMed or tunneled, its status switches >>>>>> from "special" to "plain". Doing policy routing on them does not seem >>>>>> so far-fetched. >>>>> My question was about the case without conntrack. >>>> Hm. Do you have any suggestion in countering a case whereby a user >>>> does -I OUTPUT -j TEE without conntrack? >>>> >>>> Perhaps making nesting a feature that requires conntrack, such that the >>>> non-CT case can't loop? >>> If we drop the reentrancy thing, what should work is to prevent >>> using loopback as output device and using something similar to >>> the recursion counters tunnel devices used to have. >> >> Nah. I'm going to pick a bit from struct skbuff to indicate the >> packet was teed so as to avoid that loop. > >That's a bad idea, we shouldn't be adding new skb members for something >as peripheral as this module. I would have done this, which does not add a member: IP6CB(skb)->flags |= IPSKB_CLONED; >What's wrong with adding a reentrancy counter? Sounds like a plan. -- 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
