Many ways to contributes

There are many ways to contribute to MPTCP in general:

  • Reporting bugs
  • Testing the development version
  • Talking about it on social media, mailing lists, conferences, etc.
  • Sending supportive messages to other contributors
  • Helping new users on different platforms: mailing lists, IRC, external services
  • Asking to enable it by default on services (servers) and devices
  • Adding native MPTCP support in apps (or asking app developers to add native MPTCP support)
  • Improving this website
  • Improving mptcpd, and tools used to configure MPTCP, e.g. IPRoute2, NetworkManager, etc.
  • Sponsoring the maintainers (e.g. on GitHub for Matt)
  • etc.

And of course, contributing to the Linux kernel itself, see below.

Kernel development

This part is for kernel developers: modifying MPTCP in the Upstream Linux kernel. Patches with new features and bug fixes are of course welcome.

Testing the modifications

It is easy to build the kernel, the dependences, and start a VM thanks to MPTCP Upstream Virtme Docker. With just one command, you can get a prompt from a VM using the modified kernel or run the whole test suite. For more details, please see this page from our wiki.

Any push to a fork of the mptcp_net-next repository on GitHub will trigger the CI: look at the Actions tab in the fork repository to follow the progress, and show the results.

Patches are shared on the mailing list


Like many kernel subsystems, patches can be sent to the assigned mailing list (, and not via Pull Requests on GitHub. The idea is not to restrict access to people who have a GitHub account, and to have a decentralized system.

It is easy with b4

Sending patches by email is not difficult, no more than setting up a GitHub account, with the verification of the email address, a new SSH key, etc.

To help with this task, we recommend using b4. After having installed it, you need to either:


The workflow is then easy: use b4 prep to create a new branch, and b4 send to send your patches by email.

In short, once b4 has been installed and configured, the workflow looks like:

git switch export # or export-net for fixes
b4 prep -n <new branch name>
# edit your code
git add -p && git commit -s
./scripts/ -g HEAD ## check the output, fix issues with 'git commit --amend'
b4 prep --edit-cover # if you have more than one patch
b4 send --reflect # check if the mails you sent to yourself are OK
b4 send

Once sent, the patches will be tested by our CI. A report will then be posted on Patchwork. See the CI page on our wiki for more details.

Commit messages

Please always include the reason why a patch is needed: we can easily list the modifications by looking at the patch itself (diff), but understanding why a modification has been done, why it has been done this way and not another one, etc. is important context for reviewers and future maintenance. This information should appear in the commit message.

For more details, please check the kernel doc page.

Do not hesitate to look at the Git history to get some examples.

Code style

It is the same as the guidance for Netdev, see their FAQ for more details.


  • Designate your patch for a specific tree - [PATCH mptcp-net] or [PATCH mptcp-next], see the Patch prefixes page for more details.
  • For fixes, the Fixes: tag is required, regardless of the tree.
  • Don’t post large series (> 15 patches), break them up.
  • Don’t repost your patches within one 24h period.
  • Reverse Xmas tree for the variable declaration (from longest to shortest lines).
  • Use, e.g. ./scripts/ -g HEAD
  • Use shellcheck for the Shell scripts.
  • Keep the same style as the surrounding code.