Patrick McHardy <kaber@xxxxxxxxx> wrote: > Yeah, my main concern is that this requires the user to know about protocol > modules, details about how the distribution build the kernel etc. Yep, sucks. > 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. With you so far. > 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. So you'd propose that one can have SCTP_MATCH=y CONNTRACK=n but not: SCTP_MATCH=y CONNTRACK=y SCTP_CONNTRACK=n IOW, make SCTP_CONNTRACK a non-visible symbol that just glues sctp conntrack to the conntrack core when both conntrack and sctp match is selected. > Alternatively, as I believe Pablo suggested, we can simply put all conntrack > modules inside the core. I would prefer to NOT force people to use extra connection tracking code for sctp if they don't need it. Most distributions will ship with all of this as '=m', but IMHO its safe to assume that most users will in fact not use sctp (but conntrack for udp and tcp). -- 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
