On the impossibility to use escape sequences when the networks hangs

[Theo de Raadt]

Steffen Nurpmeso <steffen at sdaoden.eu> wrote:

> Damien Miller wrote in
>  <89d93aab-0510-31a4-9542-45a718702591 at mindrot.org>:
>  |On Mon, 13 Oct 2025, Dennis Clarke via openssh-unix-dev wrote:
>  |
>  |> Seems to work fine at the beginning of a line. :/
>  |
>  |This was improved relatively recently:
>  |
>  |commit fec014785de198b9a325d1b94e324bb958c5fe7b
>  |Author: djm at openbsd.org <djm at openbsd.org>
>  |Date:   Wed Apr 20 04:19:11 2022 +0000
>  |
>  |    upstream: Try to continue running local I/O for channels in state
>  |    
>  |    OPEN during SSH transport rekeying. The most visible benefit is that it
>  |    should make ~-escapes work in the client (e.g. to exit) if the \
>  |    connection
>  |    happened to have stalled during a rekey event. Based work by and \
>  |    ok dtucker@
>  |    
>  |    OpenBSD-Commit-ID: a66e8f254e92edd4ce09c9f750883ec8f1ea5f45
>  |
>  |Before this change (in OpenSSH 9.1), an unresponsive connection might
>  |get uninterruptibly stuck if it was in the process of rekeying but
>  |AFAIK that should no longer be the case.
> 
> Should i open a bug for that ^Z, the ^C inconsistency, and i
> do not know, it is a WireGuard VPN within which SSH is used,
> and at times no packets get through whatsoever, then no input is
> accepted at all, and ^C is not processed, too.

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.