Date: Thu, 22 Jun 2023 09:38:47 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Jamie Landeg-Jones <jamie@catflap.org> Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org Subject: Re: -current dropping ssh connections Message-ID: <ZJR5FzEEFofoh8f1@www.zefox.net> In-Reply-To: <202306212305.35LN5ITH069587@donotpassgo.dyslexicfish.net> References: <ZJMyPquk32fXhT%2BI@www.zefox.net> <E84D47F1-4E75-4DA1-8EE2-3E2F36DF0EF1@yahoo.com> <ZJM7VXyWotSGwAtH@www.zefox.net> <202306212305.35LN5ITH069587@donotpassgo.dyslexicfish.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 22, 2023 at 12:05:18AM +0100, Jamie Landeg-Jones wrote: > bob prohaska <fbsd@www.zefox.net> wrote: > > > I can't detect any consistent pattern. For a while I thought load on the > > sshd-host end made a difference, but the latest disconnect was on an idle > > system with serial console output the only traffic on the dropped connection. > > Could it be that the serial connection is sending the ssh-escape sequence? > > Try adding "-e none" to the initial ssh connection command. That seems worth a try. The notion of an ssh escape (~. in this case) finding its way into the data stream is new to me. Since the last reboot to FreeBSD nemesis.zefox.com 14.0-CURRENT FreeBSD 14.0-CURRENT #70 main-476f61217b: Tue Jun 20 16:06:46 PDT 2023 bob@nemesis.zefox.com:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 the ssh-to-tip connection has stayed up with the end running tip unloaded. I'll try adding a load (buildworld) later today to see if that makes a difference. Sometimes stray characters do appear on the tip connection on re-establishment, for example: root@nemesis:/home/bob # tip ucom Stale lock on cuaU0 PID=1238... overriding. connected FreeBSD/arm (ns2.zefox.net) (ttyu0) login: � ѥ����ѥ��� �����ѥ������͕����ɕ��ѕ�����5)5)�Password: Login incorrect login: The actual display on the ssh client (A Pi4 running RasPiOS) is of charcters resembling a dark question mark in a white oval and small non-Latin characters which apparently can't be copied and pasted. They're less random that what's usually seen with a baud mismatch and at least sometimes (as the example above) seem to get mistaken for a login attempt or command by the serial console process being connected to. This sort of rubbish isn't seen after the connection comes up; it's only found on (re)-connection. Thanks for writing, bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZJR5FzEEFofoh8f1>