Tim Waugh wrote: > On Fri, 2009-12-04 at 11:22 +0100, Patrick McHardy wrote: >> There is one problem however, we already have the SNMP NAT helper, >> which also registers for the SNMP port. Those would clash if you >> add a second registration. > > Does that mean that even a simple copy of nf_conntrack_netbios_ns.c with > the port changed to 161 wouldn't work, or just that a more general > solution would be hard to implement? > > What's the solution to that? Must there be a single conntrack module to > handle both the SNMP broadcast queries and SNMP NAT? Correct, its not valid to have two helpers registered for the same tuple. The SNMP NAT helper is an exception among the helpers in that it doesn't register any expectations, but only rewrites packets. What you'd need to do is change it to not register a helper itself, but have your new module pass packets to the NAT module in case its loaded, just as the other conntrack helpers do. But as I said, the better way is to add generic broadcast tracking. It shouldn't be that much more work and I'm not sure I really want to add more workarounds like the netbios_ns helper since we'll have to deal with compatibility problems once we do add broadcast tracking. -- 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
