Steffen Nurpmeso
2025-Oct-14  15:39 UTC
On the impossibility to use escape sequences when the networks hangs
Theo de Raadt wrote in <6240.1760455482 at cvs.openbsd.org>: |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. 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. --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)
Theo de Raadt
2025-Oct-14  15:46 UTC
On the impossibility to use escape sequences when the networks hangs
Steffen Nurpmeso <steffen at sdaoden.eu> wrote:> Theo de Raadt wrote in > <6240.1760455482 at cvs.openbsd.org>: > |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. > > 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.Again, I think you are quite confused about how this is supposed to work. Of course ^C processing won't kill the local client. The local tty running the ssh client is in some sort of raw mode, and the ^C is not processed by the kernel or shell, but is a regular character sent to the ssh client process and read as a character. That ssh client handles that ^C as a character to be sent the remote end. So of course it won't kill the local client. That is why the <newline>~ escape mechanism exists. The ssh processing continues in a buffer manner, and will see it, and can interact. I've not encountered a situation where <newline>~? doesn't work. In that help message, you will also see that <newline>~^C does not exist as an option. So what you are talking about isn't make any sense.
Steffen Nurpmeso
2025-Oct-14  15:47 UTC
On the impossibility to use escape sequences when the networks hangs
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. Look, i can easily reproduce it, though -vvv does not help: #?00.00 1/121|sdaoden:steffen$ debug3: obfuscate_keystroke_timing: stopping: chaff time expired (197 chaff packets sent) debug3: obfuscate_keystroke_timing: starting: interval ~20ms ^C #?1300.00 1/121|sdaoden:steffen$ debug3: obfuscate_keystroke_timing: stopping: chaff time expired (76 chaff packets sent) debug3: obfuscate_keystroke_timing: starting: interval ~20ms ^ disable packet transmission. And hit ^C several times in a row. debug3: obfuscate_keystroke_timing: stopping: chaff time expired (501 chaff packets sent) ^ then reenable packet transmission after dunno maybe 10 seconds ^C #?1300.00 1/121|sdaoden:steffen$ ^C #?1300.00 1/121|sdaoden:steffen$ ^C #?1300.00 1/121|sdaoden:steffen$ ^C #?1300.00 1/121|sdaoden:steffe^C zcz^C #?1300.00 1/121|sdaoden:steffen$ ^C #?1300.00 1/121|sdaoden:steffen$ ^C #?1300.00 1/121|sdaoden:steffen$ ^C #?1300.00 1/121|sdaoden:steffen$ ^ all these were in the input queue, i did not type at all. And, hey, i do not write a patch, i just got paraded by Denys Vlasenko who fixed a broken Dijkstra two-stack shell algorithm by shrinking the code, whereas i added 2000 bytes and complicated stack walks to fix it. I get more detailed error conditions (eg sh: line 0: ?: condition, invalid precedence (1:v2:v3=3) (rest: I3:I2=12)) instead of sh: arithmetic syntax error but i mean, that is not sufficient to heal my wounds. Off for cycling. --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)