Re: [libnetfilter_conntrack PATCH] conntrack: increase the length of `l4proto_map`

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Wed, Jan 11, 2023 at 07:08:18PM +0100, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > On Fri, Dec 23, 2022 at 12:38:06PM +0000, Jeremy Sowden wrote:
> > > With addition of MPTCP `IPPROTO_MAX` is greater than 256, so extend the
> > > array to account for the new upper bound.
> > 
> > Applied, thanks.
> > 
> > I don't expect we will ever see IPPROTO_MPTCP in this path though.
> > To my understanding, this definition is targeted at the
> > setsockopt/getsockopt() use-case. IP headers and the ctnetlink
> > interface also assumes 8-bits protocol numbers.
> 
> Yes, this is an uapi thing:
> 
> socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); vs.
> socket(AF_INET, SOCK_STREAM, IPPROTO_MPTCP);
> 
> Only second version results in a multipath-tcp aware socket.
> 
> If mptcp is active (both peers need to support it), tcp frames will
> have an 'mptcp' option, but its still tcp (6) on wire.

Thanks for confirming.

Probably I'll post a patch to add an internal __IPPROTO_MAX definition
that sticks to 255, so libnetfilter_conntrack maps don't start
increasing if more IPPROTO_* definitions show up in the future for the
setsockopt/getsockopt interface.