Hacker News Reader

Comment by eikenberry | Hacker News Reader

+1... Given how much SSH is used for computer-to-computer communication it seems like there really should be a way to disable this when it isn't necessary.

View on HN

It looks like it is only applied for PTY sessions, which most computer-computer connections wouldn't be using.

https://github.com/openssh/openssh-portable/blob/d7950aca8ea...

In practice I've never felt this was an issue. But I can see how with extremely low bandwidth devices it might be, for instance LoRa over a 40 km link into some embedded device.

Hah no.

Nobody is running TCP on that link, let alone SSH.

https://github.com/markqvist/Reticulum

and RNode would be a better match.

In aerial robotics, 900MHz telemetry links (like Microhard) are standard. And running SSH over them is common practice I guess.

Why do you guess? I wouldn't expect SSH to be used on a telemetry link. Nor TCP, and probably not IP either.

Once upon a time I worked on a project where we SSH'd into a satellite for debugging and updates via your standard electronics hobbiest-tier 915mhz radio. Performance was not great but it worked and was cheap.

This is still done today in the Arducopter community over similar radio links.

I haven't heard much about the ArduCopter (and ArduPilot) projects for a decade, are those projects still at it? I used to run a quadroter I made myself a while back until I crashed it in a tree and decided to find cheaper hobbies...

They're alive and well and producing some pretty impressive software.

Crashing your drone is a learning experience ;)

Remote NSH over Mavlink is interesting, your drone is flying and you are talking to the controller in real time. Just don't type 'reboot'!

Well at least crashing drones into trees has never been cheaper hahaha. So it's super easy to get into nowadays, especially if it's just to play around with flight systems instead of going for pure performance.

ELRS?

You can run ELRS on 900 MHz but the bitrate is atrocious.

Nope this predated ELRS by a bit. I wasn't super involved with the RF stuff so not sure if we rolled our own or used an existing framework

what's wrong with tcp, on a crappy link, when guaranteed delivery is required? wasn't it invented when slow crappy links were the norm?

Because TCP interprets packet loss as congestion and slows down. If you're already on a slow, lossy wireless link, bandwidth can rapidly fall below the usability threshold. After decades of DARPA attending IETF meetings to find solutions for this exact problem [turns out there were a lot of V4 connections over microwave links in Iraq] there are somewhat standard ways of setting options on sockets to tell the OS to consider packet loss as packet loss and to avoid slowing down as quickly. But you have to know what these options are, and I'm pretty sure the OP's requirement of having `ssh foo.com` just work be complicated by TCP implementations defaulting to the "packet loss means congestion" behavior. Hmm... now that I think about it, I'm not even sure if the control plane options were integrated into the Linux kernel (or Mac or Wintel)

Life is difficult sometimes.

It will time out before your packet gets through, or it will retransmit faster than the link can send packets.

Reply on news.ycombinator.com