Re: -current dropping ssh connections

On Thu, Jun 22, 2023 at 12:05:18AM +0100, Jamie Landeg-Jones wrote:
> bob prohaska <[email protected]> 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     [email protected]:/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