Re: Stable/14 dropping ssh connections to FT232 usb-serial adapter
Date: Sat, 28 Oct 2023 23:11:53 UTC
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) (An accurate/complete indication of the sessions/connections command sequence for the set up could be useful.) As I understand, you are seeing the ssh session abort, not just a tip session abort. 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. 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). === Mark Millard marklmi at yahoo.com