We've spent three episodes building out this whole travel router bonding stack — the GL.iNet devices, the OpenMPTCProuter builds, the SD-WAN landscape — and Daniel finally asks the question that was sitting right there the whole time. If you're one person with one Linux laptop, why are you carrying a separate router? Can you just plug a USB cellular modem straight into the laptop and bond that with the hotel Wi-Fi, terminate on a VPS or through Speedify, and call it a day?
Right. And he wants the hardware specifics — what standalone eSIM modems actually exist for this, which ones have genuinely embedded eSIM versus a SIM slot with marketing sleight of hand, and which have real Linux support versus a datasheet that says "Linux compatible" and means "we compiled a kernel module once in 2019."
He also wants the trade-off drawn plainly. What do you give up running bonding on the host instead of the router, and when is each one the right call. This is the episode where we find out whether the simpler path is real or a mirage.
So the core premise we've been operating under is that you solve bonding at the network edge — a dedicated box that sits between you and the internet, running the bonding client, managing the WAN interfaces, presenting a single connection to your devices. And for a family or a small office, that makes perfect sense. But for one person with one laptop, you're carrying a router, a power supply, cables, you're configuring a separate device, you're troubleshooting through a web interface on a different IP address. It's overhead.
And the alternative is conceptually cleaner. The laptop already has a Wi-Fi interface connected to the hotel. You add a second WAN interface — a USB cellular modem — and run the bonding client directly on the laptop. Now the laptop itself is the bonding appliance. Fewer boxes, fewer power bricks, fewer things to forget in a hotel room.
The question isn't whether this can work. The question is whether it works reliably enough to trust for a video call or a deadline, or whether it falls apart the moment you need it. And that breaks into three pieces: the hardware, the drivers, and the bonding software. Let's start with hardware, because this is where Daniel's question gets hard to answer.
What actually exists.
What actually exists. And the short answer is: almost nothing that does eSIM properly in a USB form factor with Linux support. The market for standalone USB cellular modems is tiny and weird. It's mostly industrial — telemetry, point-of-sale terminals, digital signage. Consumer USB modems were a thing in the 3G era and then smartphones ate the category. So what's left is modules designed to be soldered into laptops or embedded in routers, which third parties sometimes stick in USB enclosures.
So you're not buying a product, you're buying a module that someone put in a box.
And the most relevant one is the Quectel EM160R-GL. This uses the Qualcomm Snapdragon X55 chipset — same generation as the iPhone 12, so it's not cutting-edge but it's solid. It's an M.2 module that vendors like Inrico and a dozen generic sellers on Alibaba put in USB enclosures. You can find these for somewhere between eighty and a hundred twenty dollars. It supports LTE Cat 16, which is faster than most hotel Wi-Fi, and it has eSIM capability — but that's where the asterisk starts.
What kind of asterisk.
The eSIM capability is on the modem's chipset. The Snapdragon X55 can talk to an eUICC — the embedded SIM chip that stores profiles. But the EM160R-GL module itself doesn't have that chip soldered on. You need a separate eUICC, and Quectel sells one called the QSIM-01. It's a tiny add-on board. Almost none of the USB enclosure vendors include it. So what you're buying is a modem that can do eSIM if you also buy and integrate a separate chip. Out of the box, it's a physical SIM slot.
So "eSIM support" means the modem knows the protocol, but the actual chip that holds the profiles isn't there.
That's the story across the board. The Fibocom L860-GL is another one — it uses the Intel XMM 7560, it's the module that ships in some Lenovo and Dell laptops with built-in cellular. You can find it in USB dongles from third parties for sixty to ninety dollars. It has eSIM capability on paper. But the Linux support is... let's call it community-maintained at best. Fibocom provides a proprietary userspace daemon for eSIM provisioning, and that daemon doesn't exist on Linux. It's Windows-only.
And the generic thing from Amazon.
The "4G LTE USB dongle" for forty dollars. It's almost certainly a Mediatek chipset. No eSIM at all. Windows-only drivers, or at best a kernel module that someone reverse-engineered and abandoned two kernel versions ago. Avoid.
There's also the Huawei ME909s.
Right, the ME909s-120. This one shows up in a lot of forum threads because it's cheap and available, and it gets mislabeled as eSIM-capable. It's not. It's an older module, no eSIM, and on Linux it requires the option driver with a USB ID override — you have to manually tell the kernel "this device ID belongs to this driver." It works once you do that, but it's not plug-and-play, and it's not eSIM. So the honest hardware answer is: the Quectel EM160R-GL in a USB enclosure is your best bet, and you're still using a physical SIM unless you source and integrate the QSIM-01 yourself. The eSIM part of Daniel's question doesn't have a clean off-the-shelf answer in 2026.
That's the hardware. What about the driver side? Because "supported by the kernel" can mean a lot of things.
It means three different things, and vendors exploit the ambiguity constantly. Level one: the modem enumerates on the USB bus and the kernel recognizes it as a communications device. Level two: you can send AT commands and establish a data connection. Level three: every feature works — eSIM provisioning, profile switching, firmware updates, the whole stack. When a vendor says "Linux support," they almost always mean level one, sometimes level two, almost never level three.
And for the Quectel?
The Quectel modules are the best-supported option on Linux. The qmi_wwan kernel driver has supported them out of the box since kernel 5.4, which shipped in late 2019. If you're running any Linux distribution from the last five years, the modem shows up, ModemManager handles the QMI protocol for connection management, and you get a wwan0 interface you can use like any other network interface. That part works. What doesn't work is eSIM provisioning. ModemManager as of 2026 does not handle the LPA protocol — that's the Local Profile Assistant, the thing that downloads eSIM profiles from the carrier's SM-DP+ server. You need a proprietary tool or a manual process.
So you can use the modem, you can connect with a physical SIM, but you can't download an eSIM profile from Linux.
Correct. And for the Fibocom, it's worse — the modem requires a proprietary daemon that only exists on Windows, so you can't even get to a stable data connection on Linux without custom firmware and a lot of forum diving. The Huawei works with the option driver but no eSIM. So the real Linux support picture is: Quectel with a physical SIM works reliably. Everything else is varying degrees of pain.
And that's before we get to the bonding software.
Right. The bonding software is actually the least problematic part. Speedify has a native Linux client — it's a proper application, not a kernel module, and it bonds any network interfaces the OS can see. If your USB modem shows up as wwan0 and your hotel Wi-Fi is wlan0, Speedify sees both and bonds them. It handles the multipath logic, the packet duplication, the failover. You install it, you log in, it works. That path is real and supported.
And if you want to roll your own with a VPS?
OpenMPTCProuter can run on the laptop itself. You can deploy it as a Docker container or a native service, and it terminates on your own VPS running the OpenMPTCProuter server image. This gives you full control — you're not routing through Speedify's infrastructure, you're terminating on a machine you own. But you're also taking on more complexity. You're managing kernel routing tables, firewall rules, Multipath TCP kernel parameters. If a kernel update changes something in the qmi_wwan driver or the MPTCP stack, you're debugging it yourself.
So the software path exists in both flavors — the managed service and the self-hosted option. The bottleneck is the hardware and the eSIM provisioning.
And that brings us to the trade-off. What do you actually give up by doing bonding on the host instead of the router? There are four real costs.
Start with power.
Power and portability. When the bonding client runs on a travel router, that router sips maybe five watts. It sits on the desk, plugged in or running off a small battery, and your laptop connects to it over Wi-Fi. You can close the laptop, move to a different room, come back — the bonded connection stays up. With host-level bonding, the laptop has to stay on and connected. If you close the lid and the laptop suspends, both WAN interfaces drop and the tunnel dies. And you're running the cellular modem off the laptop's USB bus, which draws more power than Wi-Fi alone. Your battery life takes a hit.
How significant?
A USB cellular modem in active use draws somewhere between two and five watts. On a laptop that might normally get eight hours of battery, you're probably losing an hour, maybe ninety minutes. Not catastrophic, but noticeable.
Second cost.
Network isolation. On a travel router, the bonding appliance is a separate device with its own operating system. Your laptop's traffic goes through it, but the laptop itself isn't part of the bonding infrastructure. OS updates, background syncs, whatever random processes are phoning home — they all go through the bonded tunnel, sure, but they're just traffic. With host-level bonding, the bonding client is running on the same machine as everything else. If something goes wrong — a memory leak in the bonding client, a kernel panic triggered by a driver — your whole machine is affected. And from a security perspective, every process on your laptop has access to the bonded tunnel. That's probably fine for most use cases, but it's a different threat model.
Third.
Failover behavior. This one matters. On a travel router, if the bonding client crashes, the router can fall back to a single WAN interface. Most of these routers run OpenWrt or a similar embedded Linux — they have watchdog timers, they can restart services automatically, and the failover is transparent to your laptop because your laptop just sees a Wi-Fi network that's still there. On the host, if Speedify or OpenMPTCProuter crashes, you lose connectivity entirely until you notice and restart it. Your video call drops. Your SSH session dies. And you're the one who has to fix it, possibly while the other people on the call are waiting.
That's the one that would bite you at the worst moment.
It always does. And the fourth cost is multi-device support. A travel router bonds for every device on the network — your laptop, your phone, your tablet, your travel companion's devices. Host-level bonding covers exactly one machine. If that's all you need, it's not a cost. If you ever travel with someone else or want your phone on the bonded connection, it's a hard limitation.
So those are the costs. What do you gain?
Simplicity in hardware. No extra box to carry, configure, power, or troubleshoot. No separate web interface to log into. No wondering whether the router's firmware is up to date. It's just your laptop and a USB modem.
Cost. You said the modem is eighty to a hundred twenty dollars versus two to four hundred for a travel router with eSIM.
Right. And flexibility. You can swap modems — if a better one comes out, you unplug the old one and plug in the new one. If your laptop has a built-in cellular modem, you can use that instead and skip the USB dongle entirely. You can skip bonding when you don't need it — just use the hotel Wi-Fi and leave the modem in your bag. And you have much finer control over routing. With iptables or nftables, you can do split tunneling — route your Zoom traffic through the cellular link and everything else through Wi-Fi. You can integrate with the laptop's existing VPN setup. You're not limited by what the router's firmware exposes.
So the host-level approach gives you more control and fewer boxes, at the cost of power, isolation, failover behavior, and multi-device support.
That's the framework. And the real answer to Daniel's question — is this a real, supported path or something that falls apart under reliance — is that it depends on your tolerance for tinkering.
Break that down.
If you use a known-good Quectel modem with a physical SIM, ModemManager on a modern kernel, and Speedify's Linux client, this setup is about as reliable as the travel router approach. Speedify handles the bonding logic — the packet duplication, the seamless failover, the jitter compensation — and the modem just provides a network interface. You plug it in, ModemManager brings up the connection, Speedify sees wwan0 and bonds it with wlan0. That path works and I'd trust it for a video call.
It is. The eSIM part is where it gets messy. If you need eSIM — if you want to buy a data plan from an app instead of hunting down a physical SIM in every country — you're either sourcing the QSIM-01 module and integrating it yourself, or you're provisioning the eSIM on a phone and then... no, that doesn't work. The profile is tied to the eUICC.
So the eSIM dream of "land in a new country, buy a data plan in thirty seconds, and bond it with the hotel Wi-Fi" — that path doesn't exist on Linux with a USB modem in 2026.
Not off the shelf. The travel router handles this better because GL.iNet and similar vendors build the eSIM provisioning into their firmware. They've done the integration work. On a Linux laptop with a USB modem, you're doing that integration yourself.
And if you try the self-hosted route with OpenMPTCProuter on the laptop and your own VPS?
You're taking on more complexity. Kernel routing, firewall rules, MPTCP configuration, and the risk that a kernel update breaks something in the qmi_wwan driver or the MPTCP stack. The travel router approach is more "set and forget." The host approach is more "set and occasionally debug." If you're comfortable with that — if you're the kind of person who reads kernel changelogs and isn't fazed by a modem that stops enumerating after an update — it's viable. If you want it to just work, the travel router is the mature product and the USB modem direct-connect is the DIY alternative.
Let's put this in concrete scenarios. Digital nomad, one Linux laptop, comfortable with the command line.
Host-level bonding saves weight, saves cost, gives you more control. Use a Quectel EM160R-GL in a USB enclosure with a physical SIM, ModemManager, and Speedify. Accept that eSIM isn't happening yet. This is a real setup that works.
Family traveler with phones, tablets, and multiple laptops.
The travel router is the only sensible option. You're not running bonding clients on five devices. One router, one bonded connection, everything connects to it. The GL.iNet Mudi or Spitz with the built-in eSIM and Speedify or OpenMPTCProuter is the right call.
Business traveler who needs "it just works."
Neither approach is perfect, but the travel router is closer to plug-and-play. The GL.iNet devices handle eSIM provisioning through their own interface, the bonding client runs on the router, and your laptop just connects to Wi-Fi. If something goes wrong, you troubleshoot the router, not your laptop's kernel modules. For someone who can't afford to debug a driver at the start of a meeting, that's worth the extra hundred dollars and the extra thing in the bag.
So the simpler path is real, but it's not simpler in the way people expect. It shifts complexity from hardware configuration to software and network configuration. Different kind of complexity, not less of it.
That's the misconception we should name directly. People hear "skip the router" and think "fewer things to go wrong." But you're not removing complexity — you're moving it to a different layer. On the router, the complexity is in the initial setup. Once it's configured, it's an appliance. On the laptop, the complexity is ongoing — every kernel update, every ModemManager update, every time you plug the modem into a different USB port and it gets a different device name, you might have to touch something.
The other misconception is the eSIM one. "eSIM support" on a USB modem spec sheet means the chipset speaks the protocol. It does not mean you can buy the thing and download an eSIM profile. Almost none of these devices ship with the actual eUICC chip that stores profiles. You're getting a SIM slot and a promise.
And "Linux support" means the modem enumerates. It doesn't mean eSIM provisioning works, or that profile switching works, or that you won't need a Windows VM to do the initial setup. The datasheet and the reality are... let's say they're in different time zones.
Before we wrap this up, there's one more angle I want to hit. Hilbert.
Hilbert: The firmware's the thing nobody's talking about.
Go on.
Hilbert: I spent six months in 2019 as a remote field engineer for an agricultural IoT company. Drove around Nebraska with a laptop, a Sierra Wireless MC7455 in a USB enclosure, and a cooler full of sandwiches. Testing cellular connectivity in cornfields. The modem had a physical SIM from Verizon. No eSIM, nobody cared about eSIM. The problem was the firmware.
What happened with the firmware?
Hilbert: I had three modems — identical model, identical firmware revision, bought from the same distributor. All three worked perfectly on kernel 4.15. Kernel 5.0 shipped, and two of them stopped enumerating. Not "connected but slow." Not "intermittent." The kernel didn't see them at all. The third one worked fine. Same driver, same kernel, same USB port. The difference was a firmware revision that Sierra Wireless had shipped on some units and not others, and there was no way to check which one you had without a Windows tool.
That's the reliability gap. The travel router works because the router's firmware is a known, tested environment. The manufacturer tested that specific kernel version with that specific modem firmware. Your laptop kernel changes every few weeks, and nobody's testing it against your specific USB modem.
Hilbert: It's better now. The qmi_wwan driver is mainline, it's maintained, Quectel tests against it. But the eSIM provisioning path — the LPA protocol, the SM-DP+ addresses, the profile download — that's still not in ModemManager. You need a proprietary agent or you're doing it by hand. And if the modem firmware has a bug in the eSIM stack, you're waiting for a firmware update that might never come, because these modules get one firmware release, maybe two, and then the vendor moves on to the next chipset.
The hardware path exists, the software path exists, but the integration — the thing that makes it reliable across kernel updates and firmware revisions — that's still a gap.
Hilbert: The travel router hides that gap because the vendor did the integration. On a laptop, you're the integrator.
That's the real answer to Daniel's question about whether it falls apart under reliance. It doesn't fall apart if you stay within the tested path — known-good modem, known-good firmware, physical SIM, Speedify, don't update your kernel the morning of a big presentation. Step outside that path and you're in "works until it doesn't" territory.
Hilbert: I still have the one that worked. It's in a box somewhere.
The question I keep coming back to is whether the hardware ecosystem catches up. Apple put eSIM in the MacBooks in 2025. Qualcomm's Snapdragon X Elite reference designs have embedded cellular with eSIM. The need for a separate USB modem might disappear for a lot of people — the laptop just has cellular built in, and the bonding question becomes purely a software question.
That's where the real innovation is happening anyway. It's not in the modem form factor — it's in the bonding software. Speedify and OpenMPTCProuter are converging on the same problem from different directions. Speedify has the polished client and the managed infrastructure. OpenMPTCProuter gives you full control and self-hosting. The winner will be whichever one makes the setup invisible, regardless of whether the modem is USB, embedded, or in a travel router.
The modem is becoming a commodity. The bonding logic is where the value lives.
Right. And for now, the practical advice is: if you're one person with one Linux laptop and you're comfortable with the command line, the Quectel EM160R-GL with a physical SIM and Speedify is a real, working setup. It's not eSIM, but it bonds. If you need eSIM or you need multiple devices, the travel router is still the right call. And if you need it to just work without ever thinking about kernel versions or firmware revisions, the travel router is the only call.
The simpler path is real. It's just not as simple as it looks.
If you want the specific Quectel firmware versions that work with ModemManager, or the OpenMPTCProuter Docker config for host-level bonding, we'll have links in the show notes. And if you've tried this yourself — success or failure — we want to hear about it. The forum threads on this stuff are scattered across three different sites and half of them are from 2018. Real field reports would help.
Thanks to our producer Hilbert Flumingtop. This has been My Weird Prompts. Find us at my weird prompts dot com, and if you've got a weird prompt of your own, email the show at show at my weird prompts dot com.
We'll be back soon.
