Ossama Othman
Ossama Othman
The corresponding kernel side issue is multipath-tcp/mptcp_net-next#117.
There is one change made since mptcpd 0.8 that could make a difference for the `mptcpd_kpm_add_addr()` call where the user supplied port was not included in the command message sent...
I'm not yet sure why issuing netlink PM commands from a thread other than the main thread would fail. Does a similar problem occur with the multipath-tcp.org kernel when issuing...
@mjmartineau I personally don't think it's good to build against the source tree of a dependency, but here's one way to build the sample plugin against a source tree without...
Getting mptcpd to pick up new installed plugin currently requires a restart of mptcpd. I'll document that in the [plugins wiki](https://github.com/intel/mptcpd/wiki/Plugins), too.
This enhancement request was originally for the `MPTCP_ATTR_IF_IDX` attribute in the multipath-tcp.org v0.95 kernel. Support for that kernel in mptcpd is now deprecated. However, the [mptcp_net-next](https://github.com/multipath-tcp/mptcp_net-next/blob/export/include/uapi/linux/mptcp.h) kernel also supports this...
One thing to keep in mind is that the existing MPTCP path management generic netlink API in the upstream kernel is meant to control the in-kernel (server-oriented) path manager, which...
The Valgrind build is failing because of legitimate memory leaks in two unit tests. The changes are behaving as expected.
> It would definitely help to document that autoconf dependency! Good point. It's really only needed if someone is building mptcpd from a git repository or is modifying the autoconf/automake...
I should probably bump the copyright year on the modified files.