make tmux & screen able to survive socket failure during session attached - Page 1
Forum section: electronics / general

author: DiTBho
author_rank: Super Contributor
timestamp: January 14, 2025, 10:32:25 pm
content: Usually if a socket error occurs when you re-attach a session you lose what you were doing.Code:# screen -R developmentdo stuffCTRL A D ---> de-attach ... (the process runs the background)...later...# screen -r development ---> re-attach=====Zaap socket error========Socket error might occur due to loss of wifi signal, either because the router or switch is turned off, or because there are serious noises, such as to cause packets to be lost and the tcp/ip timeout to be triggered.To partially solve this, I am using a RS422 <==> optical-fiber connection between the remote server and the local terminal.So I am working with GNU/Screen attached to /dev/ttyS3 (uart).This way my working session survives a socket failureIs there to do something similar with { screen, tmux }, on /dev/pts ? under ssh?I can patch/modify/recompile { screen, tmux, whatever ... } from sources

author: DiTBho
author_rank: Super Contributor
timestamp: January 14, 2025, 10:34:25 pm
content: ( GNU/Linux running on both local terminal and remote server )

author: JohanH
author_rank: Frequent Contributor
timestamp: January 14, 2025, 11:05:19 pm
content: Quote from: DiTBho on January 14, 2025, 10:32:25 pmI don't understand your use case. I've lost connection hundreds of times without losing any work/data, that's the whole point with running screen or tmux on the remote server. I have some vague memory that some socket error would have happened at some point, but it must be more than 10 years ago.

author: DiTBho
author_rank: Super Contributor
timestamp: January 14, 2025, 11:13:59 pm
content: Quote from: JohanH on January 14, 2025, 11:05:19 pmI never noticed it before because I've never had such a poor connection as these daysAs I said:No problem with detached session. Which is the point of using screen. You put a process in the background.The problem I have is when a re-attached something and then the ssh-connection is lost.Mobaxterm on Windows { XP, 10 } exposes the same problem.

author: DiTBho
author_rank: Super Contributor
timestamp: January 14, 2025, 11:17:58 pm
content: the error rate is up to 40% packets lost

author: DiTBho
author_rank: Super Contributor
timestamp: January 14, 2025, 11:26:09 pm
content: i did another experimentI unplugged the router cable between the terminal and the server, with a session attachedCode:macmini2-intel # screen -R dev2macmini2-intel # nano test.txtmacmini2-intel # CTRL A Dmacmini2-intel # screen -r dev2macmini2-intel # screen -listThere are screens on:16461.dev1 (Detached)19195.dev2 (Attached) <---------- I am here2 Sockets in /system/screen/S-root.waited 1 minut, which should be beyond the tcp timeoutreplugged the router cableCode:macmini2-intel # screen -listThere are screens on:16461.dev1 (Detached)19195.dev2 (Attached)2 Sockets in /system/screen/S-root.macmini2-intel # screen -r dev2no problem, nothing lostSo what the hell happens duing a serious network error?!?

author: Whales
author_rank: Super Contributor
timestamp: January 14, 2025, 11:44:30 pm
content: This does not sound like a network connectivity issue. screen and tmux should not forget your session for any network related reason, that's not how they work. That would be like saying you lost the contents of your apartment because there was an issue with the roads.Can you provide the exact error message that mentions sockets? All I can find in your post is this and I assume it's something you have hand written:> =====Zaap socket error========Keep in mind that "network sockets" are only one type of "socket", there are many non-network variants of sockets. Tmux & screen will be using local (file or unix sockets) for some of their comms; if these are breaking then you might have more serious issues on your host that will make other software misbehave too.

author: DiTBho
author_rank: Super Contributor
timestamp: January 15, 2025, 12:03:35 am
content: Quote from: Whales on January 14, 2025, 11:44:30 pmOn GNU/Linux, there is any error message when the connection is lost.On Windows, mobaxterm only says "network error".If there was an error message, I would have at least Googled it.Instead nothing, and dmesg doesn't say anything either.The kernel doesn't show any clues.When I reconnect over ssh, screen -list continues to list all the various entriesbut if the network connection has dropped on an attached-session it will be "zombied"I mean it's there but I cannot be re-attached as the PID of the process is not even present in the running processes.It's gone.Last week, with a wired-p2p-connection between the server and the terminal,both machiens were problem-free, with an uptime of 23 days, 24 hours a day.

author: DiTBho
author_rank: Super Contributor
timestamp: January 15, 2025, 12:15:57 am
content: Luckily I have a pair of fiber optic transceiverswhich are seen as serial we are talking about 100m of optical cablebetween where I am, and where the server isAnd luckily it works at 119200bpsenough to work more than decently with nano, vim, gcc ... etc.All in text console.Anyway, it should be fixed, because it's very annoying

author: Whales
author_rank: Super Contributor
timestamp: January 15, 2025, 03:49:08 am
content: Quote from: DiTBho on January 15, 2025, 12:03:35 amAre you describing what happens when you see the initial disconnection, or when you see "socket error"? Where did you get the words "socket error" from? The exact error messages and their exact context are very important, they help us greatly in understanding what has gone wrong.QuotePlease post a full copy of screen -list when this happens.QuoteI am not sure what you are trying to say.(1) Screen lists a PID(2) You can't re-attach to this PID (have you tried "screen -r -d ID" ? The -d is important)(3) The PID that screen lists is not longer on your system? (that's a serious bug if true)

author: ejeffrey
author_rank: Super Contributor
timestamp: January 15, 2025, 04:14:24 am
content: Yes if a connection is dropped without being reset or closed, the screen client can stick around for a long time. The default behavior of screen is to reattach to the first available disconnected screen instance. You need to use the -d or -D option to detach the zombie client.

author: DiTBho
author_rank: Super Contributor
timestamp: January 15, 2025, 03:43:09 pm
content: Code:Network error: Software caused connection abort

author: DiTBho
author_rank: Super Contributor
timestamp: January 15, 2025, 03:56:42 pm
content: Quote from: ejeffrey on January 15, 2025, 04:14:24 amGNU/screen was emerged without -d/-D options.Re-emerged. Now, it sucessfully resumes sessions!However ...... using MobaXterm (professional edition v21.5) as terminal on Windows 10 ... there's still something wrong.In this case, something kills the attached process.e.g. if under MabaXterm, connected to the remote GNU/Linux server via ssh, I run screen -R dev1, and then nano file.txt, ... if the network drops, the process GNU/nano is killed.This is really weird,I just found out that this only happens with a mobaxterm terminal on Windows.I will try later to grab more information and post here. I can't access that laptop at the moment.

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 15, 2025, 04:03:03 pm
content: The error is from MobaXterm, with the TCP/IP connection dropped due to inactivity. EnableSettings>Configuration>SSH>SSH Keepalivein MobaXterm.

author: Whales
author_rank: Super Contributor
timestamp: January 15, 2025, 07:43:18 pm
content: Quote from: DiTBho on January 15, 2025, 03:56:42 pmThat's super bad. That's not what you want at all.SSH keepalives should be unrelated to this problem.What distro are you on? Maybe it's one of the many systemd antifeatures?https://superuser.com/questions/1372963/how-do-i-keep-systemd-from-killing-my-tmux-sessions

author: madires
author_rank: Super Contributor
timestamp: January 15, 2025, 08:10:20 pm
content: Have you disabled TCPKeepAlive in /etc/ssh/sshd_config at the server side? The default setting is 'yes' and would be the right choice.

author: radiolistener
author_rank: Super Contributor
timestamp: January 16, 2025, 08:52:19 am
content: Quote from: DiTBho on January 15, 2025, 03:56:42 pmWhen the connection is unexpectedly dropped, the `nano` process on the remote machine is not terminated, it continues running in the background. The disconnection only affects your terminal SSH session. You can reconnect by starting a new terminal SSH session and attaching to the running `tmux` session that contains your `nano` process. All your work in nano is not lost, because it continue to run and you can finish your work from a new ssh session. The same all stdout/stderr output is not lost, it is stored and will be displayed when you reconnect again.

author: DiTBho
author_rank: Super Contributor
timestamp: January 16, 2025, 11:05:38 am
content: Quote from: radiolistener on January 16, 2025, 08:52:19 amIt shouldn't but it is! That's preciselytheproblemUsing MobaXterm (Professional, pay-version) as ssh-terminal, when the connection is unexpectedly dropped(1), the GNU/nano process on the remote machine IS terminated!ps -A | grep nano doesn't show GNU/Nano runningits pid is no more present in /proc/<pid>launched as nano file.txt, I see a backup copy file.txt.saveSomething somehow terminates it!It's fixed using a GNU/Linux laptop as ssh terminal.In this case the GNU/nano process was not terminated. I was still able to see its running PID, but before enabling the -d/-D options in GNU/Screen I was unable to resume the session.What happens with MobaXterm seems much more drastic, because seriously GNU/Nano crashes, and it also happens with VIM, Joe, ... I tried other text editors. They are all terminated.And you also have to manually delete the file that screen created for them (Screen says "defunct"), and that remains in ls /tmp/screen/$user like a corpseserver side (GNU/Linux), changes:Code:/etc/ssh/sshd_config- TCPKeepAlive no+ TCPKeepAlive yesterminal side (GNU/Linux), changes:recompiledapp-misc/screenwith -d/-D options.(1) edit:it happens witha: 802.11 wireless stack, default rate control Minstrel algorithm, connectionsb: wireless BATMAN-network mesh connectionsc: wired/copper ethernet, 100-baseT connectionsnever happened withd: wired/optical ethernet, 100-baseSX connections

author: DiTBho
author_rank: Super Contributor
timestamp: January 16, 2025, 11:14:37 am
content: Code:# screen -listThere are screens on:25443.idp (Detached)16461.nano (Defunct)19195.deve (Detached)3 Sockets in /tmp/screen/S-toorCode:# file /tmp/screen/S-toor/*/tmp/screen/S-toor/16461.nano: socket/tmp/screen/S-root/19195.deve: socket/tmp/screen/S-toor/25443.idp: socketCode:# ps -A | grep nanoso, the socket is still there, but there is no GNU/Nano running .... perplexed

author: radiolistener
author_rank: Super Contributor
timestamp: January 16, 2025, 11:34:54 am
content: Quote from: DiTBho on January 16, 2025, 11:05:38 amTechnically, this is possible if your terminal application (such as MobaXterm or another terminal you are using) sends unauthorized commands, like Ctrl+X, in response to network errors. However, this is not an issue with tmux, it is a problem with your terminal client. If the terminal application sends unauthorized commands to the remote computer, the remote system cannot prevent this and is forced to execute them.Did you tried other terminal clients, like PuTTY, Alacritty, etc?Quote from: DiTBho on January 16, 2025, 11:05:38 amIt confirms, that the issue with your terminal MobaXterm application. Just use normal termial application, for example Alacritty, or check its settings.In this case, there are no issues with tmux or sockets, the problem lies in the faulty behavior of your terminal client, which sends command to terminate your console app with no your request.

author: DiTBho
author_rank: Super Contributor
timestamp: January 16, 2025, 12:20:29 pm
content: Quote from: Nominal Animal on January 15, 2025, 04:03:03 pmApplied, relaunched!This solved the problem

author: DiTBho
author_rank: Super Contributor
timestamp: January 16, 2025, 12:30:09 pm
content: Quote from: radiolistener on January 16, 2025, 11:34:54 amIt seems "SSH Keepalive" in MobaXterm options solves the problem.This probably prevents unauthorized commands, such as Ctrl+X, from being sent in response to network errors

author: radiolistener
author_rank: Super Contributor
timestamp: January 16, 2025, 12:50:44 pm
content: Even if this option solves the issue with disconnections, it doesn't solve the problem with your SSH client app, which sends unrequested commands to the remote host during the connection loss event. So, I strongly suggest using a different SSH client that handles connection loss properly, without sending unwanted commands.

author: DiTBho
author_rank: Super Contributor
timestamp: January 17, 2025, 02:26:23 pm
content: Code:Network error: Software caused connection abortToday, again, network error on MobaXterm.Wifi connection lost for 2 minutes.Reconnect ... this time, thanks to the new "SSH Keepalive" option in MobaXterm, it worked!Code:macmini2-intel ~ # screen -listThere are screens on:25443.idp (Attached)16461.suppa (Detached)19195.deve (Detached)3 Sockets in /tmp/screen/S-root.I was attached to session 25443.idpCode:macmini2-intel ~ # screen -d idp[25443.idp detached.]macmini2-intel ~ # screen -r idp{app();return 0;macmini2-intel new # mygcc-beauty+ app.c: ok+ app.h: okmacmini2-intel new # make- generating interface public for app ... done- generating interface private for app ... done- compiling app ... done- linking to testGreat! Problem solvededit:I paid 60 euro for my MobaXterm Professional Edition, 1 license; it works very well with both vt-term and x11 stuff, and it's one of the few software accepted in various companies that put restrictions on the software you can/cannot install on your work Windows laptop, so I would have been very annoyed to have to replace it with something else.

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 17, 2025, 08:32:34 pm
content: Quote from: DiTBho on January 16, 2025, 12:30:09 pmMore specifically, Linux uses the standard Unix/POSIXtermios, where (by default)EOT (ASCII 004, Ctrl+D; termios.c_cc) flushes the outgoing buffer; and if sent at the beginning of a line,read()will return 0, signifying end-of-file/end-of-stream/end-of-transmission (assuming termios ICANON is set)ETX (ASCII 003, Ctrl+C; termios.c_cc) causes an INT signal to be sent to the processes having this as their controlling terminal (assuming termios ISIG is set)FS (ASCII 034; termios.c_cc) causes a QUIT signal to be sent to the processes having this as their controlling terminal (assuming termios ISIG is set)SUB (ASCII 032, Ctrl+Z; termios.c_cc) causes an TSTP signal to be sent to the processes having this as their controlling terminal (assuming termios ISIG is set)The standard SSH keepalive is sending null packets, essentially transferring no payload data but ensuring the other end is still in contact.You could compile and run the following stupid program I cobbled together, to log the exact cause of the error to the file you specify as the only command line parameter:Code:// SPDX-License-Identifier: CC0-1.0// Author: Nominal Animal, 2025//// Compile using e.g.// gcc -Wall -O2 this-file.c -o executable-name// and run using e.g.// ./executable-name /tmp/log-file-name//#define _POSIX_C_SOURCE 200809L#define _GNU_SOURCE#include <stdlib.h>#include <unistd.h>#include <sys/types.h>#include <sys/stat.h>#include <fcntl.h>#include <signal.h>#include <string.h>#include <time.h>#include <errno.h>static int wrpp(const int fd, const char *ptr, const char *const end) {const int saved_errno = errno;while (ptr < end) {ssize_t n = write(fd, ptr, (size_t)(end - ptr));if (n > 0) {ptr += n;} elseif (n != -1) {// This is not actually allowed, so treat it as EIO errorreturn EIO;} else {// Normally we'd retry on errno being EINTR, EAGAIN, or EWOULDBLOCKconst int retval = errno;errno = saved_errno;return retval;}}errno = saved_errno;return 0;}static int wrerr(const char *msg) {if (msg && *msg)return wrpp(STDOUT_FILENO, msg, msg + strlen(msg));elsereturn 0;}static int wrout(const char *msg) {if (msg && *msg)return wrpp(STDERR_FILENO, msg, msg + strlen(msg));elsereturn 0;}static int wr(int fd, const char *msg) {if (fd == -1)return EBADF;elseif (msg && *msg)return wrpp(fd, msg, msg + strlen(msg));elsereturn 0;}static volatile sig_atomic_t caught_int = 0;static volatile sig_atomic_t caught_hup = 0;static volatile sig_atomic_t caught_term = 0;static volatile sig_atomic_t caught_pipe = 0;static volatile sig_atomic_t caught_quit = 0;static volatile sig_atomic_t caught_tstp = 0;static void catch_int(int signo) { (void)signo; caught_int = 1; }static void catch_hup(int signo) { (void)signo; caught_hup = 1; }static void catch_term(int signo) { (void)signo; caught_term = 1; }static void catch_pipe(int signo) { (void)signo; caught_pipe = 1; }static void catch_quit(int signo) { (void)signo; caught_quit = 1; }static void catch_tstp(int signo) { (void)signo; caught_tstp = 1; }static const struct {const char *const name;void (*const handler)(int);const int signo;} signal_list[] = {{ "INT", catch_int, SIGINT },{ "HUP", catch_hup, SIGHUP },{ "TERM", catch_term, SIGTERM },{ "PIPE", catch_pipe, SIGPIPE },{ "QUIT", catch_quit, SIGQUIT },{ "TSTP", catch_tstp, SIGTSTP },};#define signal_list_count (sizeof signal_list / sizeof signal_list)static int catch_signal(int signo, void (*catcher)(int)) {struct sigaction act;memset(&act, 0, sizeof act);sigemptyset(&act.sa_mask);act.sa_handler = catcher;act.sa_flags = 0; // In particular, no SA_RESTARTif (sigaction(signo, &act, NULL) == -1)return errno;return 0;}static const char *timestamp(const char *errmsg) {static char buf;time_t now_time;struct tm now;size_t len;now_time = time(NULL);if (localtime_r(&now_time, &now) != &now) {errno = ENOTSUP;return errmsg;}len = strftime(buf, sizeof buf, "%Y%m%d %T", &now);if (len < 1 || len >= sizeof buf) {errno = ENOMEM;return errmsg;}return (const char *)buf;}int main(int argc, char *argv[]) {const char *arg0 = (argc > 0 && argv && argv && argv) ? argv : "(this)";int logfd;// Verify we have exactly two arguments.if (argc != 2 || !argv || !argv || !strcmp(argv, "-h") || !strcmp(argv, "--help")) {wrerr("\n""Usage: "); wrerr(arg0); wrerr(" [ -h | --help ]\n"" "); wrerr(arg0); wrerr(" LOGFILE\n""\n""This program runs until killed by a signal or loss of terminal,\n""saving the cause in write-only file LOGFILE.\n""\n");return EXIT_SUCCESS;}// Install signal handlers.for (size_t i = 0; i < signal_list_count; i++) {if (catch_signal(signal_list.signo, signal_list.handler)) {const char *msg = strerror(errno);const char *name = signal_list.name;wrerr("Cannot install SIG"); wrerr(name); wrerr(" signal handler: "); wrerr(msg); wrerr(".\n");return EXIT_FAILURE;}}// Open log file.do {logfd = open(argv, O_WRONLY | O_CREAT | O_TRUNC | O_NOCTTY | O_CLOEXEC, 0666);} while (logfd == -1 && errno == EINTR);if (logfd == -1) {const char *errmsg = strerror(errno);wrerr(argv); wrerr(": "); wrerr(errmsg); wrerr(".\n");return EXIT_FAILURE;}// Write started message to standard output and log file.{const char *const when = timestamp("");const char *const what = " Waiting for end of input or terminal to close.\n";wrout(when);wrout(what);wr(logfd, when);wr(logfd, what);}int err = 0;while (1) {char buf;ssize_t n;n = read(STDIN_FILENO, buf, sizeof buf);if (n > 0) {continue;} elseif (n == 0) {err = 0;break;} elseif (n != -1) {// Should never happenerr = EIO;break;} else {err = errno;break;}}{const char *const when = timestamp("");const char *const what = err ? strerror(err) : "End of input";wr(logfd, when);if (caught_int) wr(logfd, " SIGINT,");if (caught_hup) wr(logfd, " SIGHUP,");if (caught_term) wr(logfd, " SIGTERM,");if (caught_pipe) wr(logfd, " SIGPIPE,");if (caught_quit) wr(logfd, " SIGQUIT,");if (caught_tstp) wr(logfd, " SIGTSTP,");wr(logfd, " ");wr(logfd, what);wr(logfd, ".\n");fsync(logfd);close(logfd);}return EXIT_SUCCESS;}If you run it under tmux or screen with the MobaXtermSSH Keepaliveoption disabled, and manage to reproduce the problem, the log file would tell us exactly why the target process died.The above is not a good program for this at all: it would be much better for it to usesigwait()/sigwaitinfo()to catch all signals and log them to a file with a timestamp, also logging the number of characters received (when received!) from the terminal. However, I did it the silly-simple way, because DiTBho probably uses a MIPS target machine, and I didn't want to mix in stuff like pthreads and locking.

author: DiTBho
author_rank: Super Contributor
timestamp: January 17, 2025, 09:21:39 pm
content: Yes, rsp+, rb532a and rbm33gI need to buy a mini-rack, 10"

author: DiTBho
author_rank: Super Contributor
timestamp: January 18, 2025, 02:33:40 pm
content: Quote from: Nominal Animal on January 17, 2025, 08:32:34 pmCode:20250118 12:32:34 Waiting for end of input or terminal to close.20250118 12:32:37 SIGINT, Interrupted system call.rsp+ registered this during the experiment.Screen lost the session, the attached process got terminated

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 18, 2025, 03:24:30 pm
content: Quote from: DiTBho on January 18, 2025, 02:33:40 pmEwww!Yeah, MobaXterm (orsomething) injects an ETX (\x03) when the connection is lost, unless the SSH Keepalive setting is enabled.(In theory, it could be somewhere else in the process chain, but because the setting seems to fix the issue, I'd wager it is MobaXterm. There is a possibility it is actuallysshdon the Linux side, if the actual cause is that without keepalive, MobaXterm may sendincompleteSSH packets; i.e. that the SSH server kills the connection due to what it sees asbad data; the reason keepalive would fix this is that it somehow ensures that application-internal buffers are flushed to the TCP/IP connection through the TLS layer at packet boundaries... but to verify, I'd need to see MobaXterm sources, which aren't publicly available. Anyway, if one installed the handlers as SA_SIGINFO, with(int signo, siginfo_t *info, void *context), theninfo->si_codewould beSI_KERNELif it indeed came from the tty layer, orSI_USERif it was sent bykillwithinfo->si_pididentifying the sending process.)I posted the program and this post just to show the technique I use to solve these kinds of mysteries. It is a simple procedure, but can take an annoying amount of time (due to having to write the test program, and then reproduce the problem, then refine the catching program iteratively to find out further info –– myself not limited by spent time much nowadays), and it relies onreliablyreproducing the issue. One starts by identifying the way the problem occurs –– here, what signal kills the process; what kind of situation causes the target process to exit ––, then testing exactly how that happens (by obtaining further info from the killing signal), and finally by isolating the cause of that signal.In this case, we skipped directly to isolating the cause. I knew the error message was associated with MobaXterm (I know it because it has pretty good remote graphics support; X11, RDP, and VNC at least), and a quick search associated it with SSH keepalive, so I discovered the configuration setting involved.(A decade to almost two ago, I volunteered maintaining an installation of IHMC CmapServer – part ofCmapToolswritten in Java – for an university department of education, and often had to use a Windows workstation to connect to the Linux server using X11. I might have used MobaXterm around 2011, but am not absolutely certain. That installation was quite funky, too: the original instructions wanted to install the closed-source Java stuff as root on Linux, but paranoid me will not! So, I ran it as a non-privileged user in a sandbox-like environment, with Apache as a reverse proxy and providing SSL/TLS security for connections to the service. Worked like a charm quite reliably for years. Nowadays, I'd absolutely recommend implementing the client side in HTML+CSS+JavaScript with active server connections using WebSockets, with server side WebSocket stuff (collaboration) proxied via Nginx/Apache to a service daemon run unprivileged; could even write that in Python for portability. No Java.)

author: ejeffrey
author_rank: Super Contributor
timestamp: January 18, 2025, 05:57:48 pm
content: Quote from: DiTBho on January 15, 2025, 03:56:42 pmFrankly if it is possible you "accidentally" had a version of gnu screen that didn't support the -d/-D arguments your system is insane and there is no telling what other piece of software could be built or configured incorrectly.The terminal emulator is definitely suspect, but the dependence on SSH keepalives settings means it could also be a server side problem.Try installing a bog standard Debian system and see if you have the same problem with a mobaxterm client?

author: DiTBho
author_rank: Super Contributor
timestamp: January 18, 2025, 06:44:31 pm
content: Quote from: ejeffrey on January 18, 2025, 05:57:48 pmUmm, according to the Diary of Catalyst,app-misc/screenwas minimally profiled on December 5, 2009, and since then compiled accordingly with the minimum possible features. A sort of "light" version, which, for all these years, using home network with less than 10% of packet loss, never caused any problem.The problems started a few months ago, and most likely it is time to replace one or both wifi routers in the two rack cabinets that act as a bridge between where I am now, and where the remote computers are.When you have a list of USE-flags, and patches to be applied on several multi-libs - uc-libc is still as experimental as problematic on mips - it might happen that you want to compile stuff with the minimale dependencies and features possible.For example. We have been working on this issue for 20 years, and GNU/Linux on ip32r10k still has serious problems related to the speculative execution of mips r10k on a platform that is not cache-coherent ...So, most likely I copied and pasted the minimum GNU/Screen profile from there, as Screen and Bash are the only two things we run on the experimantal ram-rootfs kernels (init=/bin/bash), so most likely I applyied it to the other mips profiles of GNU/screen, which are instead stable and can be emerged full features, plus optimized for performances instead of for minimal space to reduce the cache pressure.Quote from: ejeffrey on January 18, 2025, 05:57:48 pm=net-misc/openssh-* from v5.5_p1-r2 (~2009) to v9.2_p1-r2 (~2024) to be investigated, I experimented the same behavior.Anyway, I have never had any problems using a GNU/Linux terminal.The problem only occured when using MobaXterm without the KeepAlive option enabled.I should try another Windows terminals.I will install it sooner or later. I don't always have my laptop available, it's a company one.Quote from: ejeffrey on January 18, 2025, 05:57:48 pmI don't "install GNU/Linux", I build everything from sources for different archs(1).(1) { mipsII/be, mipsIII/be, mipsIV/be, mips32r2/be, mips32r2/le, ppc32/be, ppc64/be, hppa2/be }.

author: ejeffrey
author_rank: Super Contributor
timestamp: January 18, 2025, 07:10:56 pm
content: Quote from: DiTBho on January 18, 2025, 06:44:31 pmIt's nothing about packet loss, it's about how you built screen with core features disabled. Who knows what else is wrong with your screen, SSH, terminal subsystem, and shell configurations.QuoteThe only thing that is guaranteed to be the problem is the network or routers. Screen, on a properly configured host is 100% immune to the problem you are having. Packet loss, dropped connections, stalled connections, or whatever. That is the entire point of the screen program and it works correctly for everyone else. The terminal client *could* be sending garbage that causes it to disconnect but I seriously doubt it. For no other reason that once the connection is dropped the client isn't in a position to send extra data even if it wanted to.QuoteIf you disable standard features because you don't know what they are, you are going to have problems.QuoteThat's exactly why I suggested you do so. If say it's 90% you have an improperly configured server and 10% the problem is the client. The fact that it "seemed to work" in the past doesn't mean anything. So the best course it to try against a known working system.

author: DiTBho
author_rank: Super Contributor
timestamp: January 18, 2025, 07:30:53 pm
content: QuoteAnd in fact it works perfectly with a GNU/Linux terminal!An attached process is only terminated if I use MobaXterm as terminal, and only if I don't use the "keep aware" option.QuoteThe Diary of Catalyst reports that /usr/sbin/sshd(net-misc/openssh) has always been compiled with the default profile, and runs with the default configuration.

author: DiTBho
author_rank: Super Contributor
timestamp: January 20, 2025, 10:52:33 am
content: Further experiment:MobaXterm without "keepalive", manifested the same behavior on an attached process to GNU/Screen with dropbear as ssh-server.Code:net-misc/dropbearLatest version available: 2024.85-r2Latest version installed: 2024.85-r2Homepage: https://matt.ucc.asn.au/dropbear/dropbear.htmlDescription: Small SSH 2 client/server designed for small memory environmentsOk, I think it's solved.I have to work on other development stuff now.