I’ve been playing with an idea that would involve running a machine over a delay-tolerant mesh network. The thing is, each packet is precious and needs to be pretty much self contained in that situation, while modern systems assume SSH-like continuous interaction with the user.
Has anyone heard of anything pre-existing that would work here? I figured if anyone would know about situations where each character is expensive, it would be you folks.
Like MOSH? https://mosh.org/ Mosh has some predictive output and will resume sessions automatically.
Or more like tmux/screen? Has some fancy “nohup” like functions.
That’s really helpful. Thank you! MOSH might work, I’ll have to play around with it.
Could you go into more detail about the tmux functions? If it’s a way to write everything to files instead of a STDOUT in a predictable way, that would be great, since each packet could be a (compressed) shell script that explicitly includes which data to send back, if any.
No, tmux does not redirect to a file. Though ‘>’ and ‘script’ do.
Tmux is like ‘screen’ and can be wrapped with ‘byobu’.
I mean, I guess you could just programmatically insert a > after every command. That’s actually a pretty good idea. It’s kind of obvious now that you mention it, haha!
It would be better if the tools expected to be used this way, but as a quick kludge for a project about something else it’s probably sufficient.
Mosh plus tmux is amazing.
Ask NASA
Do they post their software somewhere? What they use for space probes is exactly what I would need, but I kind of figured it would be a trade secret.
I was kidding. 😁 There’s nothing real time about C&C with space probes. And the ISS is close enough I doubt it’s an issue.
Yeah, I want not real time. The goal of having containers in the first place is to enable as much as possible without needing to put a human in the loop, since you have no idea how long each packet will spend in transit.
If I could emulate Curiosity’s onboard computer that would be a decent starting point.
In that case it might not hurt to reach out to some NASA email addresses. The people who write that stuff are, after all, nerds like us, and would probably be happy to share whatever they are allowed to share.
It’s funded by taxes so, security issues aside, there shouldn’t be a lot of trade secrets.
Government agencies, in my experience, tend to believe in security through obscurity; even the ones that don’t worry about spies as much as NASA. That said, maybe it’s worth a shot. I’ll have to figure out who’s the best person to bug.
The ‘ed’ editor was designed for high latency networks. I would pull on that thread. That is, in your shoes, I would read up on ‘ed’ and related tools.
Ed is great (in this context). I think there’s been posts about it on here before. It’s just a text editor, though.
Yeah. I’ve had mentors regail me of other tools they used alongside ‘Ed’, but I wasn’t listening very attentively. Hopefully that’s something that can be dug out of the history of the Internet.
I would definitely choose the old reliable stuff over something new and fancy, if I had this use case.
Delightful!
“Of course, on the system I administrate, vi is symlinked to ed. Emacs has been replaced by a shell script which 1) Generates a syslog message at level LOG_EMERG; 2) reduces the user’s disk quota by 100K; and 3) RUNS ED!!!”
Gave me a giggle. That 100k loss has got to hurt for a user who still tries to run ‘vi’ on a classic system, I imagine.
Edit:
Another gem:
“Ed is generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity.”
As long as you’re using TCP (what SSH uses) or a similar protocol, you should be able to deal with a situation like that. You’d mainly need to ensure that your client and server are tuned to meet your needs. With TCP, every packet is considered important and if the receiver does not acknowledge receipt, the sender will resend.
I’m not talking a lot of latency, I’m talking snail-mail levels. Hours probably won’t even be unusual, because hops will happen partly by sneakers net as people move around with their nodes. The concept is distributed burst radio for extreme censorship environments.
The point of the containers in the first place is to make as much as possible work offline, without the user having to be in the loop.
Oh that’s interesting. I might suggest looking at implementations of IP Over Avian Carrier (IPoAC). And I do mean that seriously. The idea started as an April Fools RFC but some people have actually implemented it. Basically, just using a different physical layer.
Yeah, that’s probably worth a look. Good suggestion. There’s also delay-tolerant protocols for space and similar, but I don’t know if any of them define an endpoint, as opposed to just a transport layer.
Indeed. I’d really suggest going for something based upon Internet Protocol, with any software that you need at endpoints to read and/or transmit. I might poke about at some ideas on the weekend (long holiday). What languages are you thinking to use?
Probably Rust, although I’m not married to it. I’m just at the planning stage right now, though.
One open question is if you can use a fairly standard transceiver like a Bluetooth chip, or if you need an SDR. Obviously they weren’t designed with this in mind, by maybe there’s a profile that’s close enough.
Packets should have a few kilobytes of payload so you can fit a postquantum cryptographic artifact. Thankfully, even with a BCH code, it seems doable to fit that much in a 1-second burst in a standard amateur radio voice channel, for testing. (In actual clandestine use I’d expect you’d want to go as wide as the hardware can support)
As envisioned there would be someone operating a hub, which might have actual network access through some means, and on which the containers run. They would send out runners to collect traffic from busy public spaces which might serve as hubs for burst activity, and dump outgoing packets, all without giving up any locations.
Accounts with their own small container would be opened by sending in a public key, and then further communication would be by standard symmetric algorithm - except in testing, because that’s an amateur radio no-no, so just signed cleartext. ID would be derived from signature fingerprint, as I have been thinking about it. I have a lightweight hash scheme in mind that would allow awarding of credit for retransmitting packets in a way that couldn’t be cheated.
You’d want to have some ability to detect and move around jamming, or just other people’s bursts. That’s more hardware research, basically.
