On the impossibility to use escape sequences when the networks hangs

[Steffen Nurpmeso]

Damien Miller wrote in
 <678cc9a1-1129-61d9-49e5-c8eac5c54547 at mindrot.org>:
 |On Tue, 14 Oct 2025, Steffen Nurpmeso wrote:
 |> Steffen Nurpmeso wrote in
 |>  <20251014153948.s43LKday at steffen%sdaoden.eu>:
 |>|Theo de Raadt wrote in
 |>| <6240.1760455482 at cvs.openbsd.org>:
 |>  ...
 |>||I think you are confused.  <newline>~[letter] parsing is in the client
 |>||character input side, and the server or the link to the server has \
 |>||nothing
 |>||to do with it.
 |>|
 |>|But input is impossible.  It is stuck.  Not even ^C processing
 |>|happens.  And, as i wrote, the code looks for newline (that much
 |>|i grasped before posting), and that i cannot input.
 |> 
 |> i mean ok that after ^C .. maybe some special shell does *not*
 |> "restart line processing" if it gets that, so maybe ssh cannot
 |> assume anything after that ^C; still, i cannot input even that.
 ...
 |of course. ^C, ^Z etc are processed *by the server*. If there is no
 |connectivity to the server then they can't be processed.
 |
 |~. is processed by the ssh client, so you should be able to use it
 |under most circumstances.
 |
 |Use [enter]~. to terminate a stuck ssh connection.

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 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.

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.

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.  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?

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)