mptcpd 0.4

This is a minor mptcpd release. It includes the following notable changes:

• Plugins may now inform peers that an address is no longer being advertised through the new mptcpd_pm_remove_addr() function. This corresponds to the MPTCP protocol REMOVE_ADDR option.

• Network monitoring related events are now propagated to plugins. Events are triggered upon the addition, update, and removal of a network interface (link), as well as the addition and removal of a network address. Plugins interested in receiving any of these events need only implement the corresponding callback in the mptcpd_plugin_ops API found in <mptcpd/plugin.h>.

• Stub implementations for unused mptcpd plugin operations are no longer needed. Simply set the unused field in the mptcpd_plugin_ops structure to NULL.

• This will be the last release to support the Linux 4.x based kernel on multipath-tcp.org kernel. Subsequent releases will support the new API found in the "multipath-tcp/mptcp_net-next" kernel on GitHub currently being used for development of patch submissions to the upstream Linux kernel network subsystem maintainers.

mptcpd 0.3

This is the Multipath TCP Daemon beta release. It includes the following notable changes:

• All known memory leaks have been fixed.

• A potential security hole related to logging of MPTCP connection tokens was closed. Logging of MPTCP connection tokens no longer occurs.

• Support for compiler-based address, leak, and undefined behavior sanitizers is now available, and may be enabled through corresponding configure script options. Run ./configure --help for the full list of options.

• Diagnostic messages will be issued if the Linux kernel is not properly configured to support a user space MPTCP path manager like mptcpd.

• Documentation on how to contribute to mptcpd is available in the CONTRIBUTING.md file.

• A pkg-config mptcpd.pc file is now generated and installed to allow plugin developers to more easily obtain the necessary mptcpd build related information, such as compiler and linker command line flags.

• The mptcpd plugin API dropped the mptcpd_addr type in favor of the standard sockaddr family of structures.

• Debugger-friendly optimization is now supported.

• ELL 0.27 or better is now required due to changes in the ELL generic netlink API.

mptcpd 0.2a

• This Multipath TCP Daemon alpha release replaces support for the deprecated MPTCP generic netlink API with the one found in the multipath-tcp.org 0.95+ kernel (see multipath-tcp/mptcp@4ea5dee), and has been verified to work with that kernel.
• Several actual and potential memory access violations were fixed in the mptcpd network monitor, path manager, and "sspi" plugin.
• The mptcp.service systemd service file now correctly grants the necessary privilege (CAP_NET_ADMIN) for proper operation of the mptcpd
  program.

mptcpd 0.1a

This is the initial (alpha) release of the Multipath TCP Daemon "mptcpd". It implements MPTCP path management in the user space by providing a framework that bridges user defined path management strategies - i.e. mptcpd plugins - with the Linux kernel side MPTCP implementation over a generic netlink interface.

The generic netlink interface employed by the Multipath TCP Daemon is based on an early proposal, and will be superseded by the interface available in the MPTCP development kernel, i.e.:
multipath-tcp/mptcp@4ea5dee

In addition to the kernel/user space path management bridging, the Multipath TCP Daemon also monitors changes to local network interfaces and addresses that path management strategies may choose to leverage. Currently, network interfaces and addresses may be queried (pulled). A network event notification mechanism for plugins is currently a work-in-progress.

A single-subflow-per-interface - "sspi" - plugin is included in the source distribution as a reference. It enforces a single subflow per network interface per MPTCP connection policy. Available local addresses are also sent to the kernel so that they may be advertised to the peer through a MPTCP ADD_ADDR option. The current implementation depends on the remote peer to initiate subflows, which may then be allowed or closed per this plugin's policy. Explicitly adding new subflows through this plugin is currently unsupported, but is expected to be implemented in the future.