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