On Wed, Jan 11, 2023 at 07:08:18PM +0100, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> 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.
