Daniel writes in with a question that started, as these things often do, with bad Wi-Fi. He's in Jerusalem, about to head to the US for a stretch, and he's been staring at the coverage map thinking the same thing everyone thinks eventually — why am I picking one carrier when I could be using all of them? His point is that this isn't a Jerusalem problem or a US problem. Every country with terrain and more than one telco has patchy coverage. Different carriers built out different areas, so everyone has dead zones, they just have them in different places. The obvious fix is to stop choosing and bond several carriers into a single link. And he's done his homework — he knows Multipath TCP has been in the Linux kernel for years, he knows broadcast crews bond half a dozen modems to get live video out of a field, and he knows this is proven technology that nobody has turned into something a normal person can buy. So he's got two questions. One, what's the cheapest thing that actually works today? If he's got a house with bad coverage and two carriers that each half-work, what's the realistic build — off-the-shelf hardware, open source, a cheap VPS to terminate the tunnel? Is that a weekend project or is he underestimating it? Two, why has nobody productised this? His hunch is that it's structural — an MVNO rides a single host network, and the bonding has to terminate in a box you ship anyway, so the product isn't a network, it's a hardware company that sells connectivity. Is that the real reason, or is it simpler than that and just nobody thinks the market is big enough? And a bonus question, if there's time — a phone has one radio, so none of this can happen on the handset. Has anyone shipped a multi-radio Android phone, and if not, is it silicon, power, or carrier politics?
That is a beautifully framed question. He's basically asking about the gap between what's technically possible and what's actually buyable, and that gap is where all the interesting stories live.
It is. And I should say, Daniel has lived this problem. He spent his pre-fiber days bonding DSL with cellular at two in the morning just to keep Zoom calls alive. So this isn't theoretical for him. He's been the guy staring at a dying connection wondering why the other carrier's tower, which is right there, can't help.
Right. And his instinct is correct — this is not a technology problem. It's a packaging problem. So let's start with what we're actually talking about, because the terminology matters here.
Go ahead, define it.
Cellular bonding is taking two or more independent internet connections — in this case, cellular modems on different carriers — and aggregating them into a single logical link. The key word is aggregating. This is not failover. Failover is when you're on connection A, it dies, and you switch to connection B. There's a gap, a reconnect, your Zoom call drops, your game disconnects. Bonding means both connections are active simultaneously, and your data is split across them at the packet level. If one carrier drops, the other one just keeps carrying packets, and your TCP session doesn't even notice.
And this is not exotic technology. This has existed in the Linux kernel since version three point seven, which shipped in December twenty twelve. That's fourteen years ago.
Fourteen years. And Apple has shipped Multipath TCP — that's MPTCP, the protocol that makes this work — in iOS since twenty thirteen. They use it for Siri and the App Store. Your iPhone, right now, will bond Wi-Fi and cellular for those specific services. If you're on Wi-Fi and it gets flaky, Siri doesn't drop — the phone has already sent those packets over cellular too, and whichever response arrives first wins.
So the technology is not just mature, it's shipping in the most mass-market consumer device on the planet. And yet, Daniel can't walk into a store and buy a box that bonds two SIM cards. That's the paradox. Let's unpack what it would actually take to build it yourself, and then we'll get into why nobody sells it.
Okay, the DIY build. Let me walk through the architecture first, because you have to understand what the parts are doing before you order anything. The core idea is you need a box at your house — or wherever the bad coverage is — that has at least two cellular modems, each with a SIM from a different carrier. That box takes your internet traffic and splits it across both modems using MPTCP. But here's the catch, and this is the part that trips people up — you can't just enable MPTCP and point it at the public internet. It doesn't work.
Why not?
Middleboxes. The internet is full of them — NAT gateways, firewalls, carrier-grade NAT on the cellular networks themselves. These devices inspect TCP packets and many of them mangle or strip the MPTCP option field. Cloudflare has documented this extensively. They found that a significant percentage of paths on the public internet will silently downgrade an MPTCP connection to plain old single-path TCP. You think you're bonding, but you're not. The connection works, so you don't notice — you just don't get the benefit.
So the bonding is happening in theory but not in practice, and you'd never know.
The fix is you need a termination point you control. A server somewhere — a VPS, a cheap cloud instance — that sits on the public internet with a clean connection, no middlebox interference, and terminates the MPTCP session. Your home box tunnels everything to that server, and the server reassembles the packets and sends them out to the real internet. From the perspective of whatever you're connecting to — a website, a Zoom call — it looks like a single connection coming from your VPS. They never see the bonding at all.
So the architecture is home box with two modems, tunnel to VPS, VPS talks to the world. That's three pieces.
Three pieces. Let me spec them out. For the home box, you've got options. The cheapest thing that actually works is a Raspberry Pi four or a used thin client — something like a Dell Wyse five-oh-seven-oh or an HP T-six-twenty. These are x86 boxes, they sip power, they've got USB ports for the modems, and they'll run Linux natively without the ARM compatibility headaches you sometimes get with a Pi. You can find these on eBay for roughly fifty to eighty dollars shipped. If you want new, a Raspberry Pi four with four gigs of RAM is about fifty-five dollars, plus a case and power supply — call it seventy dollars total.
And the modems?
This is where it gets real. You need USB LTE modems that present as a network interface, not as a serial modem. The gold standard for this is something like a Quectel EC twenty-five or a Sierra Wireless MC seven-four-five-five, but those are raw modules — you'd need a USB adapter board, and now you're soldering and dealing with antenna connectors. For a build that doesn't require a ham radio license and a degree in RF engineering, I'd recommend a Netgear LB eleven-twenty or a similar USB modem that works in "hostless" mode. The problem is finding one that's carrier-unlocked and supports the LTE bands you need in Israel and the US.
That sounds like the first real pain point.
It is. The modem choice is the hardest part of this build. You need to match bands to carriers, and the cheap AliExpress modems often lie about their band support. My honest recommendation — and this is going to sound like a cop-out but it's actually the pragmatic path — is to use two cheap Android phones in USB tethering mode. A used Moto G or a Samsung A-series, something with a clean USB-C port and known-good band support for your carriers. You plug them into your Linux box, enable USB tethering, and they show up as network interfaces. It's not elegant, but it works, and you're not fighting modem firmware.
So two used phones, each with a SIM from a different carrier, USB-tethered to a Linux box. That's the modem side. What's the software?
The software stack is surprisingly thin. You need a Linux distribution — Debian or Ubuntu Server, something stable — and you need to enable MPTCP in the kernel. On modern kernels, it's a sysctl flag. You set net dot mptcp dot enabled to one, and the kernel can now do multipath. Then you need mptcpd, which is the userspace path manager that tells the kernel which network interfaces to use as subflows. You configure it with the two USB network interfaces, and it handles the rest.
And the VPS side?
Any cheap VPS will do. A five-dollar-a-month instance from DigitalOcean, Linode, Vultr, or Hetzner. You want something with a public IP and decent bandwidth. Install the same Linux setup with MPTCP enabled, and run a simple proxy — HAProxy or nginx with the proxy protocol — that accepts MPTCP connections from your home box and forwards them to the internet. You're essentially building a single-purpose VPN that speaks MPTCP instead of WireGuard.
So that's the build. Linux box, two phones, two SIMs, a five-dollar VPS. What's the total cost?
Let's tally it. The Linux box — say a used Dell Wyse thin client — roughly sixty-five dollars on eBay. Two used Moto G phones, maybe forty dollars each if you hunt, so eighty dollars. Two prepaid SIM cards — in Israel you can get data-only plans from different carriers for maybe thirty shekels a month each, that's about eight dollars. The VPS is five dollars a month. So upfront hardware, you're looking at roughly a hundred and forty-five dollars, plus about thirteen dollars a month ongoing for the SIMs and the server.
That's not terrible. Is this a weekend project?
It's a weekend project if you're comfortable with Linux networking. If you've never edited a sysctl file or configured iptables, it's more like a fortnight. The assembly is straightforward — flash Linux, plug in the phones, enable tethering. The hard part is debugging. MPTCP is not widely used, so when something goes wrong, the error messages are sparse and the Stack Overflow threads are thin. You will spend time running tcpdump and staring at packet captures wondering why the second subflow isn't being established.
And the middlebox problem you mentioned — does the tunnel actually solve it?
It does, because you're not sending MPTCP over the public internet. The MPTCP session exists between your home box and your VPS. The cellular carriers just see a tunnel — it could be GRE, it could be WireGuard, it could be a plain TCP connection. The MPTCP option fields are inside the tunnel, where no middlebox can touch them. The VPS terminates the MPTCP and then sends clean single-path TCP out to the world. That's the trick.
So the build is real. The parts exist, the software exists, the cost is reasonable, and it works. Which brings us to Daniel's second question — why does he have to build it himself? Why can't he buy it?
This is where it gets interesting. There are actually two products on the market that do something close to this. One is Peplink, with their SpeedFusion protocol. Peplink makes routers that bond multiple WAN connections — cellular, satellite, whatever you've got — into a single logical link. They're the real deal. Broadcast crews use them, ships use them, RVs use them. But their routers start at several hundred dollars and go up to thousands. And SpeedFusion requires a second Peplink device at the other end to terminate the tunnel — or a cloud instance running their proprietary software. This is not a consumer product. This is enterprise and maritime.
And the other one?
Speedify. It's a VPN service that bonds whatever connections your device already has. If you're on a laptop with Wi-Fi and a tethered phone, Speedify will split your traffic across both. It's software-only, it's ten dollars a month, and it actually works pretty well. But it can't add radios to your device. If your phone only has one cellular modem — which it does — Speedify can't bond two carriers on the phone itself. It can bond your phone's hotspot with your laptop's Wi-Fi, but that's not the same use case.
So Peplink has the hardware but it's priced for enterprise, and Speedify has the software but it can't solve the single-radio problem. Nobody has put the pieces together for a consumer.
Right. And Daniel's hunch about why is largely correct. Let me walk through the structural problem. An MVNO — a mobile virtual network operator — rides on a single host network. They buy wholesale access from one carrier and resell it. They cannot offer bonding across multiple carriers because they don't have relationships with multiple carriers. And even if they did, the bonding has to happen somewhere — in a box you ship to the customer, or in software on the device. The product isn't a network. It's a hardware company that happens to sell connectivity.
So the business model is inverted from what a telco knows how to do. Telcos sell access. This product sells a box.
And the box has a bill of materials. It needs a CPU, it needs at least two modems, it needs antennas, it needs a power supply, it needs a case, it needs firmware that doesn't crash. You're not selling a SIM card with a markup of ninety percent. You're selling hardware with real costs, and then you have to support it when the customer plugs it in backwards or puts it in a basement with no signal.
This is the part where I think Daniel's analysis is right but incomplete. He said the product is a hardware company that sells connectivity. I think it's worse than that. The product is a hardware company that sells connectivity to a market that doesn't know it exists.
Say more.
The people who need this most are people with bad coverage. They live in rural areas, or they're in buildings with thick walls, or they travel through dead zones. They know their coverage is bad. They complain about it. But they don't know the term "cellular bonding." They don't know MPTCP exists. They don't know you can combine carriers. The marketing problem is enormous. You'd have to educate the market before you could sell to it, and that's expensive.
And the people who do know what bonding is — the tech-savvy crowd, the people listening to this podcast — they're the ones who will just build it themselves with a Raspberry Pi and two phones. They're not going to pay a premium for a polished product when the janky version works fine.
So your addressable market is the intersection of "has bad coverage," "knows what bonding is," "can't or won't build it themselves," and "is willing to pay for hardware." That's vanishingly small.
And there's a support problem Hilbert mentioned when we were talking about this earlier. The people who need this are the same people who can't troubleshoot it. If your customer is someone in a rural area with bad internet, and the bonding router stops working, what do they do? They call you. And you have to walk them through checking signal strength, swapping SIMs, rebooting modems — and they're already frustrated because their internet is down. The support cost per customer would be enormous.
The unit economics don't work at consumer price points. You'd have to charge enterprise prices, which puts you right back in Peplink's market.
Peplink already owns that market. They've been doing this for years. They have the patents, the firmware, the support infrastructure, the channel relationships. You're not going to out-Peplink Peplink on the low end, because their low end is already several hundred dollars, and below that there's no margin.
Let's talk about Daniel's bonus question, because it ties into this. A phone has one radio. Has anyone shipped a multi-radio Android phone?
No. And it's not for lack of trying — I'm sure engineers at Samsung and Qualcomm have sketched this on whiteboards. But there are three obstacles, and they're all dealbreakers. First, silicon. Qualcomm and MediaTek, who make the modem chips that go into phones, don't make dual-modem system-on-chips. Their entire architecture assumes one baseband processor talking to one RF front-end. To do two modems, you'd need two complete baseband stacks on the die, which doubles the silicon area, increases cost, and generates more heat.
Phones are thermally constrained already.
Massively. Which brings me to the second problem — power. A cellular radio is one of the most power-hungry components in a phone. When you're actively transmitting, the power amplifier is drawing significant current. Two radios means two power amplifiers, potentially transmitting simultaneously. Your battery life would be halved, and your phone would get hot enough to be uncomfortable to hold. The thermal throttling would probably kick in and reduce transmit power on both radios, negating the benefit.
And the third problem?
Carrier politics. Carriers certify phones for their networks. They test them, they approve the firmware, they control the update cycle in many cases. A phone that bonds across carriers is a phone that makes it harder for any one carrier to differentiate on coverage. Verizon doesn't want a phone that seamlessly switches to T-Mobile when Verizon's signal drops. That phone makes Verizon's coverage map look worse. Carriers have enormous leverage over phone manufacturers through their certification process and their retail channels. They would simply refuse to sell a multi-radio phone.
The obstacles are silicon, thermals, and politics. Any one of those might be solvable. All three together? That's a non-starter.
The dual-SIM phone is the compromise the industry landed on. Most dual-SIM phones are dual-standby — they have one radio, and they listen for pages from both SIMs by time-slicing. When you're on a call on SIM one, SIM two goes offline. Some newer phones have dual-SIM dual-active, which means two radios, but they're almost always configured as failover, not bonding. The second radio is there so you can receive a call on either number, not so you can split data across both.
The closest the market has come is a feature designed for people who want two phone numbers, not for people who want better coverage.
That's the story of cellular bonding in a nutshell. The technology exists. It's been in the Linux kernel for fourteen years. It ships in every iPhone. Broadcast crews use it daily. And yet, a normal person cannot buy it. The gap between "possible" and "buyable" is where this whole story lives.
I want to pull on one thread before we wrap up. Daniel mentioned eSIM in his thinking about this, and I think that's worth touching on. eSIM changes the provisioning side — you don't need physical SIM cards, you can download profiles over the air. But does it change the hardware side?
Not directly. eSIM is about authentication, not about radios. You still need the physical modem and RF front-end to talk to a carrier's tower. What eSIM does enable is faster switching between carriers — you could theoretically have profiles from multiple carriers stored on the device and switch between them in software. But switching is still failover, not bonding. You're still using one radio at a time.
ESIM makes failover more convenient, but it doesn't get us to bonding.
Not on current hardware. The interesting question is whether software-defined radios change this. If the RF front-end becomes programmable — if you can tune it to multiple frequencies simultaneously under software control — then you could potentially bond carriers with a single radio chain. But that's research-lab stuff. It's not shipping in phones, and it won't be for years.
Where does this leave us? Daniel asked three questions. What's the cheapest thing that works today? A Linux box with two tethered phones and a five-dollar VPS, roughly a hundred and forty-five dollars upfront and thirteen dollars a month. Is it a weekend project? Yes, if you know Linux networking. If not, budget a couple of weeks and be prepared to learn tcpdump. Why hasn't anyone productised this? Because the market is tiny, the support costs are high, the unit economics don't work at consumer prices, and the carriers don't want it to exist. And the multi-radio phone? Silicon, thermals, politics — pick all three.
That's the summary. But I think there's a deeper point here that's worth sitting with. Cellular bonding is a solved technical problem with an unsolved business problem. The technology has been ready since twenty twelve. The packaging hasn't materialised, and it may never materialise, because the incentives aren't aligned. The carriers don't want it, the manufacturers can't build it cheaply, and the customers who need it don't know it exists.
Which is a frustrating answer if you're Daniel, staring at two bars of signal from two different carriers, knowing that somewhere in the Linux kernel there's a flag you could set that would fix this.
But it's also a useful answer, because it tells you where to spend your energy. Don't wait for a product. It's not coming. Build the thing yourself, or buy a Peplink if you've got the budget. Those are the paths.
I think Hilbert has been wanting to jump in. Hilbert, you've been making a face.
He's been vibrating slightly. Go ahead, Hilbert.
Hilbert Flumingtop, our producer, spent six months in two thousand three as a field producer for a now-defunct sports network. He hauled a bonded modem rig to college football games — a box with four PCMCIA cellular cards and a custom Linux router that, he says, weighed more than the camera.
Four PCMCIA cards. That's a detail.
He says the technology hasn't changed as much as everyone thinks. His two thousand three rig did exactly what Peplink does today. The only difference is the cards got smaller and the software got prettier. He's been waiting twenty years for someone to sell this to normal people, and it still hasn't happened.
Twenty years. That's brutal.
He also says he still has the rig in his garage, and he's pretty sure it would still work if you could find a carrier with a 2G network still running. He's offered to bring it in.
I want to see this thing. I want to see a box of PCMCIA cards from two thousand three.
I think we have to make that happen. But Hilbert's point is the right one to end on. The technology hasn't changed because the technology was never the bottleneck. The bottleneck is the market structure, and market structures don't change just because the technology gets better.
That's the uncomfortable conclusion. Daniel's instinct was right — the parts exist. The gap between "possible" and "buyable" is where the interesting story lives, and it's rarely about technology. It's almost always about who pays, who benefits, and who would rather you didn't.
If you're sitting in a house with bad coverage and two carriers that each half-work, you've got options. They're not polished, they're not plug-and-play, but they exist. A Raspberry Pi, two old phones, a VPS, and a weekend of tinkering will get you a bonded connection. It won't be pretty, but it'll work.
Total approximate cost — about a hundred and forty-five dollars upfront for the hardware, roughly five hundred and thirty shekels, plus about thirteen dollars a month ongoing. That's forty-eight shekels a month for the SIMs and the server. Not free, but a lot cheaper than Starlink.
If you build this, send us a picture. We want to see the janky dual-phone rig. And if you've got a weird prompt of your own — something you want to build, something you want to understand, something that's been bugging you about why the world is arranged the way it is — send it in. The weirder the better.
Thanks to Hilbert Flumingtop for producing, and for the revelation that he was bonding cellular before the iPhone existed. This has been My Weird Prompts. I'm Herman Poppleberry.
I'm Corn. We'll be back next week with another one.
