On 26.11, Florian Westphal wrote: > 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. Basically, although I wouldn't necessarily call it SCTP match but simply SCTP support (for all of netfilter) and enable the individual parts depending on their dependencies (CONNTRACK, X_TABLES, ...). This leaves the question of nft since we don't have explicit options for that and no protocol knowledge in the kernel. That might need a bit more thought, but generally I think the before mentioned solution would be a good idea. > > 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). I agree, it would be better to not force this code upon users. -- 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
