On the impossibility to use escape sequences when the networks hangs

Damien Miller djm at mindrot.org
Thu Oct 16 11:28:10 AEDT 2025


On Thu, 16 Oct 2025, Steffen Nurpmeso wrote:

> But this only works at the beginning of a line.
> Only then the client turns this mechanism "hot".
> This condition requires that the network gets stuck at exactly
> that time, directly after i hit a newline, otherwise i sit
> completely helpless at the client prompt.

I don't follow. The escape sequence is processed entirely on the
client and shouldn't be affected by network interruptions.

If you can replicate a case where it's not working, then please
try to capture a debug trace so we can figure out what's going wrong.

> I mean i have a low
> ServerAliveInterval, which likely is the timer that then counts
> here, and ServerAliveCountMax is 3.  And i can fill the queue of
> unsent bytes "to Bagdad and way back".
> 
> And if i want to continue before the timeout exits the client,
> i need another terminal window; now it happened for whatever
> reason, i used TSTP to suspend the client only, and then
> 
>   $ ssh root at kent
>   Last login: Thu Oct 16 01:41:39 2025 from 203.0.113.1
>   #?0|kent:~# ^C
>   #?130|kent:~# ^C
>   #?130|kent:~# stty
>   speed 38400 baud; line = 0;
>   -brkint -imaxbel iutf8
>   #?0|kent:~#
>   [1]+  Stopped                    ssh root at kent
>   #?148|kent:nail.git$ fg
>   ssh root at kent
> 
> 
>   #?0|kent:~# stty
>   stty
>   speed 38400 baud; line = 0;
>   -brkint -imaxbel iutf8
>   #?0|kent:~# ^CConnection to kent closed.
> 
> I see no reason why after resume this ^C now suddenly causes the
> client to exit?  It surely is not the bash on the server which
> changed its behaviour?
> But that only was an accidental discovery.

I'm not following what you're trying to do here, sorry.

> In the end this is why i asked.  The network stuck, and my
> terminal did, too.  You can also not backspace back "like grazy"
> until you think you surely reached the start of the line, then hit
> RETURN for newline, to hotten the trigger, since all that is
> only line processing by the shell on the server side.

Similarly, I don't understand why backspacing comes into this.
The sequence is just [enter]~.

> Then again there is now that obfuscation
> timer and all the stuff, there is plenty of state surrounding that
> user input and the queue and the timer, right, what do i know,
> echo "poo, queue fills packets are stuck, if you type the escape
> in the next five seconds i will interpret it" and doing so surely
> isn't it, not even without the echo, is it?

Keystroke timing obfuscation is all client side too and turns itself
off after a few seconds of inactivity. There's very little chance it
could fill a queue unless it was already 99.999% full. It's on a
completely different path to escape handling and I can't see any
way the two could interact.

> So what, i do not know; likely all your internet connections are
> super stable, and if not, then simply let that single window hang,
> where is the problem.

No, I have connections that hang occasionally. I use the escape
sequence to terminate them and I haven't encountered cases where
it's failed for a while.

-d


More information about the openssh-unix-dev mailing list