Hi, I don't know if br_nf_post_routing can be assigned a priority NF_BR_PRI_LAST-1. I couldn't find ip_refrag definition in 2.6.30. As br_netfilter.c invokes the NF_INET_POST_ROUTING hook.I was thinking if registering your module at NF_INET_POST_ROUTING (PF_INET) after ipt_post_routing_hook(mangle table), nf_nat_out(nat table) and before ipv4_confirm (conntrack) would help. Ofcourse this would mean your module would come into picture for routed packets too. Thanks GP On Fri, Apr 2, 2010 at 7:48 PM, Gareth Williams <gwilliams@xxxxxxxxxx> wrote: > Hello chaps. > > I have a module which hooks into the bridge on the post routing hook > (PF_BRIDGE). > > I also enable bridge netfilter to allow iptables rules to process > packets - I set rules on the post_routing chain (mangle table) to set > marks on packets. > > Unfortunately I cannot see these marks in my code because the priority > on the bridge_netfilter post routing hook is PRI_LAST. > > Since it is PRI_LAST I have no room to put my hook lower than it - so I > will never see these marks. > > The comment in br_netfilter.c for this hook says it has to be PRI_LAST > because ip_refrag() can return STOLEN - but does it really have to be > LAST??? Can't it be say, last-1 so I have at least some room to move my > module to see those marks? > > I know I could enable ebtables and do it that way but I am happy using > the conntrack facilities within the iptables framework to monitor > connections over the bridge. The product I am working on also has > limited power and adding yet another set of tables and hooks would just > cause more slowdown in the fast path - something I don't think we can > stand right now. > > Am I missing something obvious? > > Cheers for any advice. > > Gareth > -- > 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 > -- 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
