openssh unix dev - Oct 2025 - On the impossibility to use escape sequences when the networks hangs

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.

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

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.