On 24.05.2011 21:03, Pablo Neira Ayuso wrote: > On 24/05/11 09:06, Patrick McHardy wrote: >> On 23.05.2011 18:13, Pablo Neira Ayuso wrote: >>> On 23/05/11 17:59, Jan Engelhardt wrote: >>>> On Monday 2011-05-23 17:47, Pablo Neira Ayuso wrote: >>>>> On 23/05/11 16:29, Patrick McHardy wrote: >>>>>> Wouldn't a flag to the CT target to skip the helper lookup work as well? >>>>> >>>>> Indeed. >>>> >>>> Yes, but how would xt_CT.ko convey to NFCT then that no helper is >>>> supposed to be used? Calling nf_ct_helper_ext_add, but then leave help >>>> at NULL? >>> >>> You can attach a template conntrack in the raw table with the CT target. >>> That template should have some status flag set to skip helper >>> allocation/assignation. >> >> Problem might be the second lookup done after NAT. We don't have the >> template available at that time. > > We'll have some IPS_NO_HELPER flag set for the conntrack at that time to > skip the helper assignation. > >> I don't like the dummy helper idea very much though, what I would >> prefer is an option to use only explicit helper assignment. That >> would be a more flexible option, additionally allowing to track >> protocols on any port without specifying each of them when loading >> the helper. > > I don't want to assign a dummy helper, but use a flag to skip helper > assignation, would you be OK with that idea? Sure, that sounds like something that would fit into the CT target. My idea other idea is to have a global option to disable helper lookups and *only* use explicit assignment, so you can specificy specifically for which addresses and ports to use helpers. > BTW, not related with this patch but I'd like to fix the current issue > with the userspace expectation support problem, still don't like my > patches to add a template and set one flag to explicitly tell conntrack > to allocate the helper CT extension? This is too much exposure of implementation in my opinion, userspace shouldn't have to care about extension areas. I'll have another look at your patches to see if I can come up with an alternative. -- 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
