On Wed, Oct 19, 2016 at 02:57:33PM +0200, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: [...] > > > and maybe also nf_conntrack_proto_gre.o, built into > > > nf_conntrack.ko? > > > > Please, keep gre back by now, I think this is quite specific of the > > pptp conntrack helper that we have in the tree and it only works for > > IPv4 and it cannot work with NAT either, it's very limited. So please > > start by building in dccp, sctp and udplite protocols. > > Wrt. udplite, I think it makes sense to merge it into udp one, I suspect > a lot of this becomes redundant after some refactoring. At quick glance, udplite is a copy and paste from udp trackers, except for the udplite_error() function. So glad to see this merged into UDP. > For sctp I am not so sure, it will add a dependency of conntrack > on crc32, but maybe thats not so important...? Actually, this would add a dependency for nf_nat, not for nf_conntrack. The real crc32c implementation details are placed behind the crypto infrastructure, I don't see any way we can skip this. We can still keep config NF_NAT_PROTO_SCTP around, just turn it into boolean toggle, so people can still compile this out if such dependency becomes a problem. I would also remove 'default IP_SCTP' from CONFIG_NF_CT_PROTO_SCTP since we don't need any local SCTP stack support to forward packets. Just to summarize: What we're discuss here is a good default configuration. After reading those RFCs that propose SCTP over UDP tunneling tricks to workaround firewalls on the Internet, my impression is that we may be probably responsible for this in some way. > Merging NAT makes sense, the external helper modules are very > small (~120 lines inlcuding boilerplate...). Correct, it's fairly small amount of code. -- 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
