Matthieu Baerts
Matthieu Baerts
Maybe using `cmsg`? A userspace app would get a poll notification when something has changed with a socket (`fd`) it owns. If needed, another syscall could be used to retrieve...
@nrybowski is working on it A short documentation (in the wiki) could be useful!
* Validation of inbound / outbound ADD_ADDR on a different port * Validation of inbound / outbound MP_JOIN to this different port Linked to #54
Or is it OK to leave it open until it's forced closed by an interface being shut down?
From Mat in #18 : > We don't have a suitable eBPF hook yet. We've discussed adding BPF_CGROUP_SOCKET to allow per-cgroup override of proto in the socket() call.
Can be split in multiple subtasks but the default behaviour should be closed to what is done with TCP. We need to check what to do if [gs]etsockopt are used...
The idea would be to imitate what is done in TFO, using a cache: if a destination IP is known not to support TFO (MPTCP here), fallback. Note that now...
Without this PR, a warning is emitted when compiling libyaml with musl libc: ``` api.c: In function 'yaml_strdup': api.c:66:27: warning: implicit declaration of function 'strdup'; did you mean 'strcmp'? [-Wimplicit-function-declaration]...
Some conditions should rarely happen in `mptcp_skb_entail()`, e.g. `mptcp_is_data_fin()`, `mpcb->send_mptcpv1_mpcapable`, etc. Better to tell that to the compiler by adding `likely()` / `unlikely()` macros not to take the more costly...
When working on https://github.com/multipath-tcp/mptcp_net-next/commit/ee056f61817adcd5d21ed9ff999ca0d1f395a449 patch, Paolo noticed that the memory accounting for passible (listen) MPTCP sockets is not properly taken into account. For more details, see the first comment here...