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_add_subflow and mptcpd_pm_set_backup functions acts as expected.

Originally posted by @vandit86 in #221 (comment)

[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_set_backup 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_remove_addr 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 mptcp_net-next..
MPTCP is configured to run with userspace PM: net.mptcp.pm_type=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_remove_subflow can only remove the initial subflow (the first one that establish connection). But has no effect on additional subflows created with mptcpd_pm_add_subflow..