BondingShouldBeFree Open-source Network Aggregation & Redundancy Solution Announcement

arinc9 · May 18, 2026, 2:53pm

Hello everyone!

After two years of active development, I am proud to announce that BondingShouldBeFree, an open-source network aggregation and redundancy solution is ready for its first stable release.

The BondingShouldBeFree bonding solution is a set of programmes that utilises Multipath TCP (MPTCP), providing advanced network aggregation and redundancy capabilities.

This project leverages an upstream Linux kernel and is currently focused on supporting conventional Linux distributions and all OpenWrt-supported devices.

The main goal of BSBF bonding is to combine multiple internet connections into a single connection to improve both bandwidth throughput and network reliability. By aggregating multiple internet breakouts, users can achieve better performance and maintain connectivity as long as there is one working connection.

How to Use

This is a plug-and-play solution. All network interfaces on your router (Ethernet ports, SFP, etc.) are automatically converted to WAN with a DHCP client. Only one interface remains LAN to access the bonded network. The interface with the biggest number at the end, such as lan5, is made LAN. If there are no interfaces with a number at the end, the first found LAN network interface is used instead.

There is a web interface to monitor and manage internet connections. Management options are enabling or disabling bonding, setting rate limits on each internet connection (connection prioritising), making internet connections backup, and running speed tests. After install, you can access it at the link below. If your device uses a different LAN IP, replace 192.168.1.1 with your device's address.

http://192.168.1.1/bsbf-client-web/

For internet connections using Wi-Fi, PPPoE, and alike, you can configure a network entry for them as usual but put a metric between 1 and 8 that is not in use, and it will be included in the bond.

Install the bsbf-autoconf-dhcp and bsbf-autoconf-cellular packages to support auto-configuration of cellular modems, USB adapters, and Android and iOS tethering. MBIM or QMI modems will be added with the "internet" APN. Check the full package list here.

Installation

This solution is available on SNAPSHOT from 18/05/2026 and onwards, and OpenWrt 25.12.5 and later stable releases.

You need credentials from a server with the BSBF solution installed.

There are two methods to install the solution to an OpenWrt-supported device.

Running a shell command on a device running OpenWrt

Replace the server IPv4 address, server port, and UUID with yours below. Then run the command below. This command can be re-run to change the server and/or upgrade the solution.

apk add curl && curl -fsSL owrt.bondingshouldbefree.org | sh -s -- --server-ipv4 25.0.0.1 --server-port 16384 --uuid 60d210ef-7271-4dc9-9b93-01563608bf90

If the device runs out of storage at install, you can try to build an image instead by following the steps below.

Flashing an image

Head to the BondingShouldBeFree firmware selector. Put in your OpenWrt-supported device model. Put in your server IPv4 address, server port, and UUID, or request credentials, and press Request Build. Wait a minute or so for image generation to complete and then download the generated image for your device.

Details

Project page and documentation.

For usage, projects, discussions and hardware advice, feel free to join the Discord server.

Many thanks to Daniel (@dangowrt) for enabling MPTCP on the kernel by default for most OpenWrt devices, adding support and maintaining the mptcpize and ell packages, and bearing with me on many of my pull requests.

Dimi from Sovereign Hybrid Compute is kindly offering the US server free of charge. Check out his services.

Greetings to OpenMPTCPRouter.

I provide services to ISPs and other interested parties to implement the solution to their infrastructure. Contact me here.
Chester Arinc

25 May 2026 Update: The BSBF domain has changed to the one I own: bondingshouldbefree.org.

8 July 2026 Update: The free BSBF server credentials trial has concluded.

arinc9 · May 18, 2026, 3:03pm

Please check if your internet paths support MPTCP. You can see it on the BSBF Client Monitor as MPTCP SUPPORTED or MPTCP NOT SUPPORTED:

andrewjlamarche · May 18, 2026, 4:48pm

Hi! Interesting project. I have a few questions:

How does this differ from OpenMPTCPRouter?
What is used to encapsulate each link to the aggregation server?
How are links with varying bandwidth managed?
How are links with high latency managed?

arinc9 · May 19, 2026, 5:24am

Great questions Andrew!

My vision for this solution is to have it become THE network bonding solution.

I've built it around the approach of proper engineering: Removing more and more components whilst retaining the same functionality. Here are the key points I follow:

I don't make my own OpenWrt releases. The source code is in the official OpenWrt packages repository along with my own repo for conventional Linux distro support. So this solution is automatically shipped on every new OpenWrt release.
I don't do device support. I was able to automate configuration to accommodate every device with different features. So every OpenWrt-supported device is supported out of the box.
I use open-source components with an established development team instead of writing my own, where I can. The reason is long-term maintenance and having the benefit of the knowledge and expertise of the whole world, not just mine. And I contribute to these projects. I've got a few bug fixes credited to me on the MPTCP implementation in the Linux kernel, especially.

There's no encapsulation. Every TCP stream is proxied using MPTCP. And there's an MPTCP stream created for UDP payload. I use the VLESS protocol to that end. This protocol is also censorship-resistant so it allows the bonding solution to be used in more restrictive networks (China, Russia, Iran, and Turkiye to some extend come to mind).

This is the responsibility of the MPTCP implementation in the Linux kernel. I have tested the bandwidth I get under a wide range of setups (3 cellular, 2 cellular 1 fibre, 2 cellular, etc.). It's quite efficient in sending as much as each link can carry.

In addition to that, the BSBF Client Monitor has a connection prioritisation feature so you can change the priority of the links, meaning you can configure one link to a 100/100 Mbps rate limit, the other to 80/80 Mbps, and so on.

This is a good point, especially when 600ms RTT satellites are involved. You can manually set this kind of links as backup using the BSBF Client Monitor, so that they're only used when there's no other link available.

I do have a working solution for finding high latency links (compared to the other links in the system) and make them backup, but I don't yet find my design simple enough to be production-worthy.

hmh · May 21, 2026, 11:17am

It has been know for a long time that tunneling TCP over TCP (or, for that matter, anything with feedback control like QUIC or TCP) over TCP is a last-resort. There is a lot of literature proving it too, and documenting the effects.

E.g.: https://www.researchgate.net/publication/333313300_Effects_of_TCP_Transfer_Buffers_and_Congestion_Avoidance_Algorithms_on_the_End-to-End_Throughput_of_TCP-over-TCP_Tunnels

I don't think MPTCP can address that: it was conceived as something you enable on the endpoints, like e.g. Apple does to much of its stuff on iOS and its Cloud and you provide multiple global IP addresses to the endpoint (like one is supposed to do with IPv6 when multiple upstreams are available).

As for satellite, don't even try to guess how it will work unless you actually simulate one (hint: add the packet loss). High RTT is not the only problem.

arinc9 · May 21, 2026, 11:31am

That is precisely why this solution does not do that.

I have tested the solution in South Africa on multiple satellite setups (2 satellite 1 cellular, 2 satellite) it works fine.

hmh · May 21, 2026, 2:03pm

I may have misunderstood how it works, then. Can you point me to a technical description of what it is actually doing?

arinc9 · May 21, 2026, 2:19pm

Have you checked the documentation? Let me know if you have any questions about any specific section of the doc.

hmh · May 22, 2026, 11:01pm

I tried. I can't find any high-level documentation with an overview of the solution, protocols involved (and how), nothing other than mentions of MPTCP being used, so I assume I must be looking at the wrong place. Obviously I could just start downloading source and reading it to find out, but anything that wants to be the go-to solution for something ought to have appropriate introductory documentation somewhere.

Then I tried searching for OpenMPTCP, since that was brought up as something similar, and THAT has a pretty decent high-level explanation, and seems to do exactly what I feared: tunnel packets inside MPTCP streams. But that's exactly what you said your project doesn't do...

So, well, I am confused. But you don't have to bother with it. Just take this as a hint that you either need decent introductory / overview documentation on your project, or your introductory documentation might benefit from being more discoverable...

arinc9 · May 25, 2026, 1:21pm

Thanks. I've added a technical overview to the project documentation:

The core components of the BSBF solution are MPTCP, bsbf-mptcp, and xray. MPTCP provides network aggregation and redundancy. The implementation in mainline Linux is being used. bsbf-mptcp tracks connectivity and MPTCP support of interfaces, maintains the MPTCP endpoint table, and manages routes. Xray transparently proxies client TCP and UDP traffic delivered to it with nftables tproxy rule through a remote server.

The vless transport protocol is used on xray to proxy client traffic through the remote server without tunnelling. The vless protocol delivers UDP traffic by creating TCP streams. MPTCP is enabled on xray client outbound and server inbound. Therefore, client TCP and UDP traffic is delivered to the remote server using MPTCP. Xray on the remote server then uses TCP or UDP to proxy the client traffic to the described host.