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

On Oct 29, 2023, at 07:01, bob prohaska <fbsd@www.zefox.net> wrote:

> On Sat, Oct 28, 2023 at 04:11:53PM -0700, Mark Millard wrote:
>> So, if I understand correctly, the general structure here is something like:
>> 
>> RPi4B: ssh to RPi2 v1.1 #0 (to invent simple naming).
>> . . .
>> RPi2 v1.1 #0: tip ucom (which gets to RPi2 v1.1 #1)
>> . . .
>> (Does each RPi2 v1.1 get its own ssh session too? If yes: all from the same RPi4B?)
>> RPi2 v1.1 #1: tip ucom (which gets to RPi2 v1.1 #2)
>> . . .
>> (ssh session to RPi2 v1.1 #N ?)
>> RPi2 v1.1 #N: tip ucom (which gets to RPi2 v1.1 #0)
>> 
> 
> I think you've got the picture. Here's an ASCII-art diagram:
> http://www.zefox.net/~fbsd/netmap
> 
> Each connection originates on a single WiFi-connected Pi4 running RasPiOS (top right).
> The sessions are separate shells, each running in a tab in one lxterminal window.
> 
> 
>> (An accurate/complete indication of the sessions/connections
>> command sequence for the set up could be useful.)
>> 
> 
> Here's a verbatim sample, including MOTD and usbconfig output:
> bob@raspberrypi:~ $ ssh 50.1.20.26
> Password for bob@www.zefox.com:
> Last login: Sun Oct 29 03:34:28 2023 from 50.1.20.31
> FreeBSD 14.0-RC3 (GENERIC) #39 releng/14.0-n265368-c6cfdc130554-dirty: Fri Oct 27 21:27:20 PDT 2023
> 
 . . .
> bob@www:~ % su
> Password:
> # usbconfig
> ugen1.1: <DWCOTG OTG Root HUB> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
> ugen1.2: <vendor 0x0424 product 0x9514> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (2mA)
> ugen1.3: <vendor 0x0424 product 0xec00> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (2mA)
> ugen1.4: <FTDI USB - Serial> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (90mA)
> ugen1.5: <GenesysLogic USB2.0 Hub> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (100mA)
> ugen1.6: <JMicron External USB 3.0> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)
> # tip ucom
> Stale lock on cuaU0 PID=1272... overriding.
> connected
> 
> 
> FreeBSD/arm64 (pelorus.zefox.org) (ttyu0)
> 
> 
>> As I understand, you are seeing the ssh session abort, not just a tip
>> session abort.
>> 
> 
> That's correct. On the RasPiOS host I see simply
> client_loop: send disconnect: Broken pipe
> 
>> An interesting test might be having another ssh session paired with
>> each one that does a remote tip --but that is not used for any tip
>> or other activity beyond sitting at a shell prompt. The question for
>> each paired ssh session would be:
>> 
>> A) Do both ssh sessions of the pair fail/abort at the same time?
>> B) Does only one? If yes: is it always just the one that had used tip?
>> 
>> So, a comparison/contrast test.
>> 
> 
> At present I have only one usb-serial adapter per RPi2/3/4. However,
> that still gives me seven tip sessions up at any one time and the one
> on releng/14 drops reliably.

I take that wording to mean that the ssh session into:

50.1.20.26 www.zefox.com Pi2 releng/14

fails, 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?).

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.

It would be possible to do similarly on more than one target RPi*,
not just the releng/14 RPi2B v1.1 . The test would be for whichever
target RPi* happens to show the failure.

>> As I remember, there were notes about avoiding special character
>> sequences from getting special interpretations for ssh. That sort of
>> thing could be important to both ssh [-e none] and tip [-n] for
>> testing if that avoids some problems.
>> 
>> I've no clue if "tip -n -v" might report anything interesting around
>> a failure (via the -v).
> 
> I've tried ssh -e none, it didn't make an obvious difference. I overlooked 
> tip -v, will try it next time. As it happens the tip sessions sometimes
> come up "stuck", reporting a connection but refusing to display any 
> output. In that case it's useful to use ~~. to escape back to a root
> prompt, run usbconfig [-u 0 -a 4] power_off and then power_on to reset
> the usb-serial adapter, which generally gets a working connection. 
> I'll try tip -n -v at the next opportunity.


===
Mark Millard
marklmi at yahoo.com