On 26.11, Florian Westphal wrote: > Patrick McHardy <kaber@xxxxxxxxx> wrote: > > The way I see it we basically have two options for fixing this: > > > > * disable the generic protocol entirely > > That was the original v1 patch, BUT that means that we do not > support NAT for protocols without l4 tracker anymore (which > is why we did not remove generic protocol). Yeah that is quite undesirable. > > * add a helper for every protocol for which we support matching on the identity > > of a flow and load the helper automatically when conntrack is enabled and > > the match is used. > > Yes, but that might take a while. AFAICT we're only missing ah/esp/ipcomp, those should be relatively trivial to add, if we agree that this is the way to go. > The existing way (skip if module) is a compromise to attempt to not break > existing setups. > > If e.g. SCTP=n and user has -p sctp --dport 42 -j ACCEPT then all > sctp packets will match the generic entry for sctp, i.e. the --dport 42 > is redundant if an ESTABLISHED accept catchall is used. > Thats not nice, but the alternative is to break things when > NAT is used for that protocol... > > If we have SCTP=n and its not loaded, we skip the generic tracker and > users need to load the extra module. Granted, that breaks things as > well in some cases, but at least thats fixable without 'rebuild > kernel'... Yeah, my main concern is that this requires the user to know about protocol modules, details about how the distribution build the kernel etc. And the main reason for this problem to exists is exactly because users *don't* know about this, so I'm questioning whether this really solves it. The =y case is easy, it will work. The =m case should probably at least be handled automatically. And then =n case is impossible to solve correctly and therefore probably should not be possible. I agree with Pablo (in fact I might have convinced him of that :)) that this stuff is *way* to modular and its not only completely useless in many cases, as we see here it might even actively cause problems. I think the question during configuration should be "SCTP support y/n/m". We would then select the sctp match, build the SCTP conntrack into the conntrack core the SCTP NAT into the NAT core and the problem can not occur anymore. Same thing for other protocols. If the user selects n, no SCTP conntrack, no SCTP match. Alternatively, as I believe Pablo suggested, we can simply put all conntrack modules inside the core. -- 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
