Remove subflow behaviour ?

[vandit86]

    @ossama-othman, 

could you please explain briefly what _mptcpd_pm_remove_subflow_ should do? Should it send some info (flag) to the peer, or just remove the selected subflow from the internal kernel subflow list?? I didn't notice any changes in the data flow when trying to remove subflow from the plugin. the _mptcpd_pm_addsubflow and _mptcpd_pm_setbackup functions acts as expected.

Originally posted by @vandit86 in https://github.com/intel/mptcpd/issues/221#issuecomment-1274868707

[vandit86]

Hi, Any update for this question?

[ossama-othman]

@vandit86 mptcpd_pm_remove_subflow() should trigger a shutdown/close of the underlying TCP connection for that subflow. Does your kernel log show any information or errors related to the subflow closure after calling mptcpd_pm_remove_subflow()? Were there any diagnostic messages on the mptcpd side?

[vandit86]

No error message appears on mptcpd side after calling remove subflow function.. Kernel logs also empty.. (observed by dmesg -w .. is this a way to watch MPTCP kernel logs? ) Also, I didn't see any changes on traffic flow by analyzing dump with wireshark.. I was expected to see TCP FIN on the subflow that should be closed.. Literally nothing happen..

So, this is how I try to remove subflow from the plugin, and this call produces no effect. But calling the _mptcpd_pm_setbackup function with the same params working well..

                if (mptcpd_pm_remove_subflow(pm,
                                            token,
                                            laddr,
                                            raddr) !=0)
                {
                    l_error ("Can't remove subflow in %u",
                    token);
                }

[ossama-othman]

(observed by dmesg -w .. is this a way to watch MPTCP kernel logs? )

Yes. On Linux distros that use systemd, you can also use journalctl -f since that would cover both kernel and mptcpd logs, assuming mptcpd is configured to log to the systemd journal.

I'll try to dig up anything on my end.

[vandit86]

Also, REMOVE_ADDR option is not sent to the peer if try to call _mptcpd_kpm_removeaddr during the active MPTCP connection. The endpoint is removed from the endpoints list, listed by ip tool, but no effect on active connection is observed.

/**
 * @brief Stop advertising network address to peers.
 *
 * @param[in] pm         The mptcpd path manager object.
 * @param[in] address_id MPTCP local address ID to be sent in the
 *                       MPTCP protocol @c REMOVE_ADDR option
 *                       corresponding to the local address that will
 *                       no longer be available.
 *
 * @return @c 0 if operation was successful. -1 or @c errno otherwise.
 */
MPTCPD_API int mptcpd_kpm_remove_addr(struct mptcpd_pm *pm,
                                      mptcpd_aid_t address_id);  

[mjmartineau]

Hi @vandit86 -

Which kernel version are you running? And what's the output of this command: sudo sysctl net.mptcp.pm_type

[vandit86]

Hi @mjmartineau

I've been experimenting with MPTCP and different kernel versions for a while.
Now I'm running kernel 5.19, compiled from export branch of _mptcpnet-next.. MPTCP is configured to run with userspace PM: _net.mptcp.pmtype=1, such that I can control everything from my plugin (i.e., change limits, create subflow, change subflow priority, and so on), except removing subflow..

By the way, in a new version v.6.1 (LTS), you have announced on github Wiki page the "privileged Netlink operations from user namespaces".. Can you please explain (or share link to read about this) the main differences from the previously implemented netlink operations and userspace functionalities.?

[vandit86]

IMPORTANT UPDATE : I just found out that _mptcpd_pm_removesubflow can only remove the initial subflow (the first one that establish connection). But has no effect on additional subflows created with _mptcpd_pm_addsubflow..