[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4r3sqop-o651-6o1q-578-o4p519668073@vanv.qr>
Date: Wed, 12 Apr 2023 20:24:59 +0200 (CEST)
From: Jan Engelhardt <jengelh@...i.de>
To: Matthieu Baerts <matthieu.baerts@...sares.net>
cc: Jakub Kicinski <kuba@...nel.org>,
Pablo Neira Ayuso <pablo@...filter.org>,
netfilter-devel@...r.kernel.org, davem@...emloft.net,
netdev@...r.kernel.org, pabeni@...hat.com, edumazet@...gle.com,
mathew.j.martineau@...ux.intel.com, mptcp@...ts.linux.dev
Subject: Re: [PATCH net,v2] uapi: linux: restore IPPROTO_MAX to 256 and add
IPPROTO_UAPI_MAX
On Wednesday 2023-04-12 18:44, Matthieu Baerts wrote:
>
>> Makes me wonder why MPTCP got 262 instead of just 257.
>
>Just in case a uint8 is used somewhere, we fallback to TCP (6):
>
> IPPROTO_MPTCP & 0xff = IPPROTO_TCP
>
>Instead of IPPROTO_ICMP (1).
>
>We did that to be on the safe side, not knowing all the different
>userspace implementations :)
Silent failure? That's terrible.
int IPPROTO_MPTCP = 257;
socket(AF_INET, SOCK_STREAM, (uint8_t)IPPROTO_MPTCP);
on the other hand would immediately fail with EPROTONOSUPP
and make hidden uint8 truncation readily visible.
Powered by blists - more mailing lists