Where We Left Off#

In March I wrote up building a router from scratch: a Protectli VP2420, a Quectel RM520N-GL modem card, a MediaTek MT7921 WiFi card, and a move from OPNsense to OpenWRT to stitch it all together.

This is the follow-up. Six months of that box as the only internet connection for work and everything else, through an international move and, as I write this, a hotel room in Germany. Some of the first post held up. Some of it needs correcting. And the most useful upgrade of the whole six months was not a component at all: a SIM card that holds eSIM profiles, which fixed the one part of travel internet the router itself never could.

Short version: the hardware has been boring in the best way. Nearly every hour I lost was to software, carriers, or my own stale config.

The Scorecard#

Corrections to the First Post#

I would rather correct the record than leave optimistic numbers sitting there.

The cellular numbers were generous#

I quoted 80-100 Mbps down on Rakuten. That was never the sustained reality. Measured properly (repeated runs, bound to the cellular interface, at different times of day, from different hardware and locations), LTE looked like this:

Perfectly usable for remote work, though not the 100 Mbps I signed for. Rakuten was still my best option at the time; the honest mean was just a long way from the marketing. Thankfully I worked 22:00 to 06:00 JST, so the congested hours were mostly someone else's problem.

It has never connected to 5G#

The modem is 5G. The plan was 5G. The antenna pair is 5G. The serving cell even advertised it. And the router spent its whole Rakuten life on LTE Band 3, because no n77 cell was ever reachable from where it sat. In April the network flatly refused the 5G registration; by July the modem would search and simply find nothing.

Here is the part I cannot explain: Rakuten's coverage map called the apartment a dead zone, which would settle it, except my phone, on the same carrier in the same room, received Rakuten 5G just fine. The signal was there. The router never saw it.

Relocation, and the Home/Travel Split#

Over the summer we moved back stateside, into a bigger home, and the WiFi card in the Protectli stopped being enough, for two reasons:

• Signal strength. The MT7921 and its two small antennas were sized for an apartment, not for covering an entire house.
• No real multi-band support. The MT7921 is a single radio, serving one band at a time: 2.4 GHz or 5 GHz, never both. A house full of IoT devices wants 2.4 GHz permanently; laptops and phones want 5 GHz. One card cannot give you both.

So WiFi at home now comes from a separate access point: my old Asus router running Asuswrt-Merlin, set to AP mode. The Protectli still owns DHCP, DNS, firewall, routing.. all of it. The Asus just moves packets over the air.

The nice side effect is the split this creates. The Asus is the home WiFi and it never moves, so the IoT devices stay joined to the same network whether the router is on its shelf or in a suitcase. The Protectli's own radio is now the travel WiFi, switched on only when we go nomad. Taking the router on a trip no longer means re-pairing a house full of smart plugs when I get back.

The AP still needed hand-tuning. Left on auto it chose a 160 MHz channel reaching into DFS space. Wider is not better when the signal is weak.

All of it lives in git#

A move like this touches everything at once: new WAN, new AP, radio off at home, radio back on for travel, cellular on or off depending on the country. That is exactly how you end up with a router nobody fully understands, including the person who configured it.

So none of it is done from memory. The whole router is managed from a git repo on my laptop, and the relocation, the AP swap, and the trip below are all just commits: what changed, when, and a known-good state to roll back to. The travel part is literally a checklist (radio on, cellular on, snapshot, and the reverse when we get home), because "why is there no WiFi" in a hotel room is not the moment to be remembering UCI syntax. The rest of the harness, and the hurdles that justified building it, are further down.

Field test: a hotel in Germany#

The checklist got its first real use almost immediately. We took a trip to Germany shortly after the move, and part of this post is being written from the hotel with the router on the desk.

The internet source for the whole trip is the cellular modem and nothing else. No hotel WiFi, no hotel ethernet. How that SIM got there is its own story.

It is doing exactly the job it was built for. Radio back on, every device we brought joins the same SSID it always does, and all of it sits on its own isolated LAN behind our own firewall and DNS rather than loose on the hotel network. Nothing had to be reconfigured per device. The router was the only thing that had to learn where it was.

The one thing that nearly stopped the show was not software at all: the router needs a wall socket, and German sockets are not American ones. For all the planning that went into bands, APNs, and failover, the most important travel accessory turned out to be the correct power plug. It is on the checklist now.

The Hurdles#

Roughly in the order they hurt.

1. The major-version upgrade (24.10 to 25.12)#

One upgrade swapped both the kernel (6.6 to 6.12) and the package manager (opkg to apk). Things I learned:

• Sysupgrade keeps your config, not your packages. I reinstalled 100+ packages afterwards, including the modem and WiFi drivers. Plan for the router to come back up without its WAN.
• LuCI custom commands vanished silently, even though the config file that holds them was preserved.
• WiFi went into a silent setup/teardown loop. No error, no log line. The driver and firmware were fine (I proved that by running hostapd by hand), so I shipped a small init script that bypassed OpenWRT's wifi scripts entirely. It worked. Then upstream fixed the bug, and my workaround and the fixed scripts each started a hostapd at boot and fought each other. I found the AP sitting on 2.4 GHz channel 1 at 20 MHz, days later.
• My backup scripts broke without telling me. They called opkg, which no longer existed, and quietly skipped the package inventory for two months. A backup you have not restored from is a hypothesis.

2. mwan3 and WireGuard both want to own routing#

I ran a full-tunnel WireGuard VPN for a while. The tunnel came up, handshook happily, and carried zero traffic. mwan3's policy rules sit at a higher priority than the main routing table, so every packet was steered out the raw WAN before the tunnel's default route was ever consulted.

The fix was to make the tunnel a first-class mwan3 interface with its own policy. A second, site-to-site tunnel then hit the same family of problem from a different angle: its endpoint got routed inside the first tunnel, because that tunnel already owned the default route when the new one came up.

Two smaller ones from the same config:

• Two per-device rules sat below the catch-all rule and had matched zero packets, ever. Rule order matters and nothing warns you.
• A policy named balanced was shaped as a failover. It never mixed links. The name had me convinced otherwise for weeks.

I eventually turned the full tunnel off. The exit was in Europe, which turned a 40 ms connection into 165 ms and capped it at about 19/10 Mbps. That is a VPN-exit problem, not a router problem, but it is the router that gets blamed.

3. The modem wedges, rarely but completely#

Twice the cellular data path died while the modem still reported itself registered on LTE.

After a SIM swap. I borrowed the SIM for a phone, put it back, and the router got 3-5 Mbps with a suspiciously flat +320 ms of latency. Signal was perfect. The same SIM did 20 Mbps in a phone. Everything on my side (WiFi, routing, shaping) checked out, because the problem was not on my side: the hot-swap re-attach had been handed a throttled session by the carrier core. A full modem reset produced a new carrier-side address and restored 22/16 Mbps at 40 ms.

The signature is worth memorising: single-digit Mbps, constant added latency, clean signal. Reset the modem before you touch a single config file. I now do it after every SIM reinsertion, and I confirm it worked by checking that the carrier-assigned address actually changed.

Overnight, on its own. The kernel logged a transmit queue timeout on wwan0, DHCP renewals failed, the lease expired, and mwan3, correctly, moved everything to the wired WAN. Signal that week had dropped from -85 to -117 dBm RSRP on the same cell, so something physical had shifted; weak RF under load is my best guess at the trigger.

Related gotchas:

• The modem shipped with SIM hot-swap detection disabled. Insert a SIM while it is powered and it reports NOT INSERTED forever. AT+QSIMDET=1,1 fixes that.
• An AT+CFUN=1,1 reboot sent over the serial port can silently do nothing. The QMI-level reset (uqmi --set-device-operating-mode reset) is the one I trust.

I wrapped all of this in a reset-modem.sh that proves the new session is genuinely new. It earned its keep within a week.

4. The 20 Mbps mystery#

Back stateside, the new place has gigabit fibre. I plugged it into the router. Everything topped out at 19 Mbps.

The culprit was me, from March: an SQM (CAKE) shaper on that port, tuned to 20/8 for the slow connection it used to carry. Shaper on: 18.6 / 7.3 Mbps. Shaper off: 884 / 939 Mbps. Nothing was broken. The router was doing precisely what I had asked it to, for a link that no longer existed.

On the cellular side I went the opposite way and added cake-autorate, which adjusts the shaper continuously from measured latency. A fixed cap on a cellular link is always wrong: too low at noon, too high on Sunday evening. Autorate stopped the evening bufferbloat without me retuning anything.

What I Built Around It#

The theme of every hurdle above is state I could not see: a stale shaper, a dead rule, a backup that was not backing up. The move added its own version: a router reshaped by a dozen small changes that existed only in my head. That is why the repo exists. It started as a folder of notes and turned into a small management harness. On top of the travel checklist you have already met:

• Snapshot before and after. One command pulls the full config, package list, and modem and network state off the router, and commits itself. Leaving home, coming home, before any change: snapshot.
• Drift check. I still click around in LuCI like everyone else. The drift script tells me when the live router no longer matches the last snapshot, so those clicks do not get lost.
• Custom files deploy from the repo. Anything I wrote myself gets edited in git and pushed out by a script, never hand-edited on the box.
• The AP too. The Asus is read-only from the repo's side: I configure it in its own UI, and a script captures its radio settings and clients so I have a before and after to compare.
• Upgrade and rollback are scripted, and each one takes a snapshot first. The router's own config is never blindly overwritten: the router is the truth for its settings, the repo is the truth for my custom files.
• Tests. Shellcheck and bats, because bash scripts that touch your only internet connection deserve them.
• Secrets live encrypted in-repo with git-crypt, behind a scanner that refuses to commit anything that looks like a credential.
• A scheduled CI job compares my installed packages against the OpenWRT feeds and keeps a living list of pending updates, flagging the security-relevant ones.

In the interest of honesty: as I write this, that list says 104 updates pending, 7 security-relevant, oldest ignored for 66 days, and I am two point releases behind. Building the dashboard turned out to be easier than acting on it. After the last major upgrade I am in no rush, but the number is there, climbing, which is the point.

The Real Problem Was Never the Router#

The whole reason for this build was: land in a country, put in a local SIM, have good internet. The router part works. "Put in a local SIM" is where trips have gone sideways.

It is hard to boil this down to cost versus performance, because those were never my deciding factors. These were:

Eligibility#

1. Nationality matters. Many plans are closed to foreigners, because the carrier wants a resident locked into a contract.
2. Some SIMs refuse to run in a modem. They check the device's IMEI and expect a phone.
3. Carriers push their own pocket WiFi instead. I do not trust those devices, and they are usually overpriced paperweights.
4. Physical SIMs are going away. They are becoming the premium option, and newer phones ship with no tray at all.
5. eSIMs are everywhere. Sold online, delivered instantly, and the barrier to issuing them is low enough that a friend of mine provisioned one for me in Japan. (The process was explained to me. I retained none of it.)

Time#

1. I work remotely. Unstable internet is a direct hit to my work. Yes, I could simply not travel.
2. Most physical SIMs now need in-person identity verification at a store. I have lost multiple days to vendors unwilling to deal with a foreigner.
3. After all that, I have still been throttled at undisclosed times and intervals, and had complete outages, with no information from the provider.

Service#

1. Most places really have one, maybe two, carriers worth using, because of who owns the towers.
2. Price-to-performance varies wildly between packages, and the fine print is usually where the bad deal lives.
3. Advertised coverage, "5G" or even "4G", may not include the one spot you work from, while a different package does.

Put those together and the answer is obvious: eSIMs solve eligibility and time almost completely. You buy one from a couch, in minutes, with no store visit and no passport photocopy, and if it is bad you buy a different one.

One problem. My router has a SIM slot, not an eSIM chip.

The Fix: a Physical SIM That Holds eSIMs#

It turns out you can buy a physical SIM card that is an eSIM chip: a removable eUICC. It sits in an ordinary SIM slot and looks like an ordinary SIM to whatever it is plugged into, but you can download eSIM profiles onto it and switch between them.

I bought the 9eSIM V3. About $24, holds up to 50 profiles, and works with any standard (GSMA) eSIM provider. Under the hood the companion app is built on NekokoLPA2, an open-source LPA (the "Local Profile Assistant"), which is the piece of software that downloads a profile from a carrier and writes it to the chip. It is MIT-licensed and runs on Android, iOS, macOS, Linux, and Windows, talking to the card through a phone's SIM slot or a USB smart-card reader.

That last part matters to me. The card follows the open eUICC standard, so it is not tied to the vendor's app. If the company disappears, any compatible LPA can still manage it.

How it fits the router#

[ eSIM provider ] -- QR / activation code -->  [ LPA app ]
                                                   |
                                    writes profile to the card
                                     (phone slot or USB reader)
                                                   |
                                             [ 9eSIM card ]
                                                   |
                                     moves into the router's SIM slot
                                                   |
                          [ RM520N-GL ] sees a normal SIM -> QMI -> wwan0

1. Buy an eSIM plan for wherever I am going.
2. Load it onto the card with the app.
3. Put the card in the router. The modem neither knows nor cares that the "SIM" is a downloaded profile.
4. Set the APN for that plan, and, per the lesson above, reset the modem after inserting the card.

Several plans can live on the card at once, so a multi-country trip is one card and a profile switch, not a bag of tiny plastic rectangles.

In the field: Germany#

This is not theoretical. It is how this post is reaching the internet right now. The SIM in the hotel story above is this card, and it is the trip's only uplink:

1. Bought an eSIM plan that fit what we needed.
2. Loaded it onto the card with the app.
3. Card into the router, APN set to exactly what the plan suggested.
4. Bam. Live.

No store, no ID check, no counter staff deciding whether they felt like helping a foreigner today. Compare that with the "multiple days lost" entry above. The whole process took less time than finding the right power adapter.

In use it has been easier than the physical-SIM route, and it performs about the same when it works well, which depends on the plan you bought far more than on the card.

Caveats#

• Modem-unfriendly plans are still modem-unfriendly. An eSIM plan that checks IMEI will be just as unhappy in a router as its plastic equivalent. The card solves getting a plan, not what the plan permits.
• You need something to write profiles with. A compatible phone, or a USB reader and a laptop.
• "Unlocked" does not mean open. My Pixel wrote to the card without complaint. My Japanese-market Sony, also carrier-unlocked, would not: its SIM interface appears to cooperate only with cards it considers authorised, and this one is not. I have not dug into exactly what is being enforced. I will say that Japanese carriers, like a lot of Japanese companies, have a long history of doing strange things in their own private interest, and this smells like one of them. If you plan to use a phone as your writer, test it before the trip.
• APNs are per plan. The modem will not guess. Keep the APN written down next to the profile name.

Would I Build It Again?#

Yes, with different expectations.

• The hardware was the easy part and has needed nothing since March.
• The software needs an owner. OpenWRT is excellent, and it will happily let you build a routing table that defeats itself. Snapshot before every change. Future-you has forgotten what present-you configured.
• Measure, then write it down. Every number I quoted from memory was wrong in the flattering direction.
• The SIM supply chain was the actual bottleneck, and one cheap card fixed more of my travel-internet pain than any component in the original build.

Updated troubleshooting reference#

Until next time,

✧~ Aqua ~✧#