A Migrated BGP Router, a Real Throughput Bug, and a Hardware Store Fix
I moved the cloud side of my own network setup to a new, faster server and rebuilt the connection back to my home office from the ground up, which turned up two real bugs along the way. That led straight into finally figuring out why mlvpn-rs had been running slow for months — the real cause turned out to be my own internet provider. In between: a quick PC repair at the local Ace Hardware in Zion.
Moving my cloud router to a faster, unmetered server
The cloud side of my network setup — the part that announces my own address space out to the internet — moved to a brand-new server on a real unmetered 10-gigabit connection. I had to rebuild the whole thing from scratch on the new machine: the routing software, the tunnel back to my upstream provider, and mlvpn-rs itself for the link back to my home office. I cut over cleanly, with no overlap or conflicts while the old server was still running.
Two real bugs showed up once traffic was supposed to be flowing. First, the rule that sends my own address space back out to the internet had only ever been written down as a comment, never actually added — I added it for real, and traffic started moving. Second, and sneakier: the routing looked correct, but nothing was getting through. It turned out Docker, running on the same machine for an unrelated service, quietly blocks all forwarded traffic by default. You'd never notice unless you knew to look for it, since everything looks fine right up until a packet actually tries to leave the machine. I fixed it the right way, with a rule that's guaranteed to survive Docker restarting instead of one that fights Docker's own rules and gets silently wiped out. Then I proved it by rebooting the machine on purpose and checking that routing still worked.
Finally figuring out why mlvpn-rs was running slow
With the new cloud router up, the obvious question was why mlvpn-rs's own speed test kept reporting only 6–8 Mbps on a home connection that's rated for 45 Mbps upload. Nothing in the program's own numbers showed anything getting lost, which had made it look like an unsolved mystery for months. This time I captured the actual network traffic during a test and found the real problem: the program was trying to send data at nearly 400 Mbps — almost ten times what the connection could handle — with no attempt to pace itself. My internet provider's own equipment was quietly throwing away everything over the real limit before it ever left the building, invisible to anything running on my own machine.
I fixed it by having the program ramp up gradually instead of all at once — send a little, then a little more, then more again, until it finds the real ceiling, then back off just below it. It's the same idea as a careful driver easing onto a slippery road instead of flooring it and finding out the hard way. No manual tuning needed for any given connection. A second, more careful look at the code caught one more real problem before it shipped: if every single measurement attempt failed, the old version would still report a made-up number and treat it as the truth from then on, permanently throwing off how the program planned around that connection. Fixed, tested, and now running on both ends of my real connection, at home and in the cloud.
Smaller things
Fixed up a manager's PC at the local Ace Hardware here in Zion — a quick, in-person fix that was a nice change of pace from a week spent entirely in network settings and code.