Re: Stable/14 dropping ssh connections to FT232 usb-serial adapter

On Sun, Oct 29, 2023 at 11:47:14AM -0700, Mark Millard wrote:
> 
> I take that wording to mean that the ssh session into:
> 
> 50.1.20.26 www.zefox.com Pi2 releng/14
> 
> fails, 

Correct.

> not the ssh session into:
> 
> 50.1.20.27 www.zefox.net Pi2 12.3 2303 usb-serial----50.1.20.26
> 
> If I have that wrong, my wording below would need adjustment.
> 
> So my suggestion would be to have an extra ssh session to the releng/14
> RPi2B v1.1 in order to see if both ssh's have problems at the same time.
> I'm not suggesting a 2nd serial connection: the extra ssh session would
> just sit at a releng/14 shell prompt, for example.
> 
> On failure, a question would be if the extra ssh session can still
> execute commands in that shell or not.
> 
> If only one ssh session of the pair fails, repeated testing to check if
> it is always the same one of the pair would be appropriate (always and
> only the one doing tip?).
> 

As a rule, in addition to the ssh session running tip there's also an
ssh session running other tasks, often in the background, like buildworld.
Those didn't normally drop.

> This might help issolate if tip is involved in initiating the ssh falure
> or not. tip would likely stop if the ssh session failed for other reasons.
> 
> I recommend the experiments be with "ssh -e none" and "tip -n -v", even if
> the likes of, say, "tip -n" is unreasonable in general use.
> 
> > There are usually half a dozen ssh connections
> > running interactive shells from the RasPiOS host to random FreeBSD Pi's
> > and as a rule they only drop when I crash or reboot the RasPiOS host.
> 
> I'm not really after what happens across multiple RPi*'s in my
> suggestion. I'm after the pair of ssh sessions into the same
> RPi* instead --just for the target RPi* that gets the failure.

At the moment the relevant ssh session uses -e none and tip uses -n -v,
and the session stayed up all night.

However, there's another change: When preparing to post the link to the
network/serial map it dawned on me that the host in question was still
on the wired LAN (for configuration), not the public WAN. To my thinking
that really shouldn't matter but maybe it does, and the wired WAN is the
ultimate destination for the host anyway, so I moved it. The wired LAN
doesn't see much use, so its performance isn't well characterized. 

Apologies for the last-minute revelation 8-(

Thanks for writing,

bob prohaska