Adaptive Tunnel MTU, Another Self-Inflicted Outage, and a Real ISO Builder
I gave mlvpn-rs a way to file its own support tickets and fixed a speed cap it's had since the start. Along the way I found a real data-loss bug in a different service, and locked myself out of my own machine again.
mlvpn-rs can now file its own support tickets
mlvpn-rs — my VPN that bonds several internet connections into one faster, more reliable link — already had a way to dump its own health and logs to a file, by hand or automatically when a link got bad. It couldn't turn that into an actual support ticket, though. I wired it into the same support-ticket service OmniBridge started using last week, so it can file a ticket by itself now, whether I ask it to or it decides to on its own, and even if the whole program crashes. That last part took two tries: the first version tried to send the report and quit at the same time, so the report usually never made it out before the program was already gone. I only caught that by actually crashing it on purpose and watching whether the report showed up. Fixed it so it waits briefly for the report to go out before it finishes shutting down.
Fixing a speed cap that's been there since day one
The bigger fix: mlvpn-rs has always limited the size of the data packets it sends through the tunnel to a conservative number, and never raised that limit even when the connections underneath could handle more. My own internet links can carry bigger packets just fine, so that old limit was quietly slowing things down for no good reason. Now it checks what the real connections can carry and raises the limit to match, and it keeps re-checking every 30 seconds instead of just once at startup, so it adjusts if a connection changes while it's running.
Two bugs showed up while building that. The first: it sized its own memory for packets once, at startup, so if the limit went up later it would have tried to hand itself packets too big to fit. Caught that one in review before it ever shipped. The second was trickier: actually resizing a live connection needs a special permission that the program normally gives up right after it starts, for safety. I fixed it to keep just that one narrow permission instead of none, and tested it for real — watched it keep that one permission and successfully resize a real connection while running.
A real data-loss bug, found in a completely different program
Making room for mlvpn-rs's new ticket type meant changing a rule in the support-ticket database too — and that change turned out to be more dangerous than it looked. The first version of the fix used the standard way of changing that kind of database rule: build a new copy of the table, move the old rows into it, and swap it in. That swap quietly deleted every existing support-ticket conversation the moment it ran against the real, live database, because of how a related table was set up. Real customer data, gone, on a service people actually use. I only caught it by checking the real numbers on the live server afterward, not by trusting that the tests passed. Fixed it with a safer, narrower version of the same change, and this time proved it by breaking a copy of the database on purpose first, then showing the fix stops it. There was no backup to restore from, so that data is gone for good — a hard reminder to think through what a "routine" database change actually touches before running it against something live.
I locked myself out of my own machine, again
While testing the connection-resize fix directly, I deliberately slowed down my dev machine's own internal network connection to see if the code handled it. A bug in my test briefly cut that connection to zero instead of just slowing it, which I caught and fixed in seconds — but not before it knocked out the browser-based terminal I use to reach that machine, which happened to be using that same internal connection without my realizing it. My last self-inflicted outage was about being careless with a live customer system; this one was just my own machine, and it still locked me out until I fell back to a plain remote login to fix it. Tracked it down and fixed it for good — the connection itself had actually disappeared, not just slowed down — and everything came back clean.
Smaller things
Got a dedicated build machine working for something I'd wanted for a while: an installable OmniBridge disc, so someone can hand a USB stick to a brand-new computer and get a working system, instead of installing a package by hand. New build server, one special permission that only the hosting system's own admin account could grant, and I settled an open question from the original plan — whether the disc-building tool would work without full admin rights — by actually running a complete build and getting a real, working disc out the other side.