On 12/04/2023 18:14, Jan Engelhardt wrote: > > On Wednesday 2023-04-12 17:22, Matthieu Baerts wrote: >>>> But I don't know how to >>>> make sure this will not have any impact on MPTCP on the userspace side, >>>> e.g. somewhere before calling the socket syscall, a check could be done >>>> to restrict the protocol number to IPPROTO_MAX and then breaking MPTCP >>>> support. >>> >>> Then again any code which stores the ipproto in an unsigned char will >>> be broken. A perfect solution is unlikely to exist. > > IPPROTO_MPTCP (262) is new, anything using MPTCP is practically new code > for the purposes of discussion, and when MPTCP support is added to some > application, you simply *have to* update any potential uint8 check. I hope such check doesn't exist :) IPPROTO_MPTCP is only used when creating the socket, with the "protocol" parameter which accepts an integer. >> I wonder if the root cause is not the fact we mix the usage of the >> protocol parameter from the socket syscall (int/s32) and the protocol >> field from the IP header (u8). >> >> To me, the enum is linked to the socket syscall, not the IP header. In >> this case, it would make sense to have a dedicated "MAX" macro for the >> IP header, no? > > IPPROTO_MAX (256) was the sensible maximum value [array size] > for both the IP header *and* the socket interface. > > Then the socket interface was extended, so IPPROTO_MAX, at the very > least, keeps the meanings it can keep, which is for the one for the > IP header. > 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 :) Cheers, Matt -- Tessares | Belgium | Hybrid Access Solutions www.tessares.net
