mptcpd
mptcpd copied to clipboard
multipath-tcp
Command has no effect with upstream PM
mptcpd v0.8 kernel 5.15.0-rc7-mptcp
Hello,
I try to develop PM plugin based on addr_adv example.
I can handle all mptcp related events from path manager and network monitor through callback functions.
Hoverer, after I send any command to in-kernel PM, it passes through netlink_pm, but no result is observed.
For example, I have configured PM with ip mptcp tool, and it works as expected (add, delete, flush.. endpoits).
When calling in code
mptcpd_kpm_flush_addrs(pm)
function executed successfully (no errors, return 0), and I expect to observe the same behaviour as by ip mptcp tool, but nothing is changed on mptcp path manager configuration. Also, other mptcpd_kpm*_ commands don't affect PM.
Furthermore, mptcpd works well with mptcp v0 kernel (mptcp_org), so I can control PM from user space code.
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 to the kernel (see #127) but I'm not sure if that would address some of the behavior you encountered. Would you be able to try the master branch or apply the attached patch and see if that addresses the issues you're seeing? Note that the there were minor API changes to some of the functions in the mptcpd library since the 0.8 release.
0001-src-Append-port-to-add_addr-command-if-given.-127.patch.gz
OK, I figured out the problem.
Netlink_pm stops working as expected when I call these functions from a separate thread.
Now I need some advice to get around this issue. Should I always use the main mptcpd thread to interact with kernel ?
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 commands from a different thread?
Keep in mind that neither mptcpd nor the ELL library it uses are thread-safe. Your code will have to provide the necessary thread synchronization.
I'll try to reproduce the problem on my end.