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 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.
