Maybe a VPN will help smooth that out? Dunno. Wireguard maybe?
I’ve seen https://tailscale.com/ mentioned around Ars, maybe give that a try?
Assuming you’re referring to “still sucks for SSH, though. Connections just keep getting broken”, that’s an interesting supposition. I guess it would depend on what layer the VPN functions at and how the underlying session/packet transport works.
Yeah, was referring to maybe keeping the SSH connection live. Not sure if it actually will or not. Might be worth a try, since you were planning to VPN anyways.
Take the Mosh pill and leave SSH behind.
Caveat - doesn’t like agent forwarding but there’s a thing called guardian agent or something.l but I’ve not experimented with it.
That’s interesting. But it starts up it’s own listener instance. Is it’s codebase up to the level (or down, dunno) of the SSH server in terms of security and such? Including the in-flight and hand-off from the SSH server to the mosh-server instance?
Does it show you when it’s currently having connection issues, and so what you’ve just typed might not still be there? Does it ‘catch up’ with the output to your screen if you have connection issues, and then when connection is re-established? How about IP changes, does it handle those well?
I’m definitely going to put this on my list to investigate more fully, even if just out of curiosity.
Supposedly it does all the above and is as secure as ssh - but I’ve not investigated.
The downside I noticed beyond loss of ssh agent stuff is the loss of “mouse wheel scrollback” that you get by default in iTerm or similar.
There’s a solution involving screen and tmux but I haven’t bothered. When I need agent or scrollback I drop to using ssh instead.
It HAS handled ip changes and it does complain if it can’t connect at first.
Yeah, screen/tmux is great.
Screen/tmux is one of those things I know is great but I never quite have the motivation to actually learn it (same reason I still use nano instead of emacs/vi).
Maybe someday I’ll just force myself.
Or we could use a connection that doesn’t randomly misbehave on the internet. 
I’m hoping it improves over time with that - I expect it’s when jumping satellites with a gap between them or something (which happens).
But I won’t grumble too much about 172/40 (current speeds)!
I’ve not used it but read about it some time back. My impression is that lack of scroll buffer was a feature; rather than transmit all the bytes and do terminal stuff locally it does the terminal emulation locally and sends the diff since last upstate. Lower bandwidth to get the same displayed state.
I wouldn’t be surprised if you can translate mouse scroll to control characters and scroll remotely, but the local buffer isn’t filled by design.
Again this was some time ago.
Yeah, iTerm even asked me if I wanted to send “cursor control characters” when I scroll the mouse - but again, I don’t have time to dig into it and figure it out. If I do (or find a blog post describing how to get it to work) it would be pretty slick.
I have to say, being able to push up at 1-3MB/s and pull down at 10+MB/s is sort of nice!
I find that the best is getting to where your “latency” is such that you don’t task switch - a git push is fast enough that you don’t switch to the browser and get distracted.
One particular issue fixed, I think…
If you’re using certain router brands (Mikrotik is one) with Starlink, they get “stuck” on the 192.168.100.100 temporary address (handed out before the device is connected to satellites) with a 5 second lease. When the satellite gets a connection, it should hand out the “real” IP in the CGNAT range, but at least on Mikrotik, it keeps refreshing with the same invalid address. If you disable/reenable the DHCP client on Mikrotik, it works, but this is annoying - any time the satellite dish reboots, things get stuck on the useless IP. I’m not sure who’s in the wrong here, and I honestly don’t really care enough to dig out my bump on a wire and find out, but it’s still a “Oh, wake up, backup internet is down…” sort of annoyance.
In any case, I fixed it (I think…) with a simple Mikrotik script running every 30s.
:local starlinkip [ip dhcp-client get [find interface="ether1"] address];
:local badip 192.168.100.100/24;
:put "Got Starlink IP $starlinkip";
:if ($starlinkip = $badip) do={
:log info "Found Starlink Temporary IP $starlinkip, trying to refresh...";
/ip dhcp-client disable [find interface="ether1"];
/ip dhcp-client enable [find interface="ether1"];
}
Toss it in scheduler, and it should solve the problem soon enough. No worse than any other Starlink “Oh, hey, isn’t connected to anything…” beta outage.
That’s interesting. Did you report it to Starlink and Mikrotik? Maybe they just haven’t seen it, and so ant fix it, if they can.
I haven’t. I wouldn’t feel right doing that without tcpdumps from the exchange, and I haven’t been highly motivated to do that.
My understanding from some other reading is that the dish continues to respond to unicast DHCP requests with the old IP - “Hey, DHCP server, I have this IP, can I keep it?” successfully, while the broadcast requests - “Anyone out there, I’d like an IP!” starts responding with the new address. The router behavior of “unicode requests” is spec compliant and valid, so the issue is with the dish.
But it works with the provided Starlink router, so reports of the bug are likely to be entirely ignored. It’s a Musk company, after all, and they clearly know better than some end user with the “Oh, well, it might work…” configuration of a third party router.
And IPv6 apparently works. Doesn’t solve the random outages, but something else to mess with…
Now that you have multiple providers, a server you have root on, and time on your hands maybe you could setup something like:
Interesting… yeah, that might be worth dorking about with one one of the subnets!
Can you multihome/load balance the connections w/ failover?
https://lostdomain.org/2018/04/11/doing-dual-isp-load-balancing-with-ubiquiti-edgerouter/
for example.