Tip echoing when it should not?

It appears that tip is mistakenly echoing characters when it
picks up a stale connection.

I've noticed this problem for a long time now, but this is
the clearest example so far of what seems like undesirable
behavior. 

Normally I keep a tip session running on a usb-serial adapter
to monitor the GPIO serial console of (several) Raspberry Pi
computers. The scheme is to ssh into one Pi, su to root and
run tip on the usb-serial adapter, thus getting a console
session that displays a login prompt and console messages on
the connected Pi.

From time to time a login session is left running, and then
the ssh session drops for reasons unclear but likely immaterial
to the puzzle.

On restarting the tip session at least some of the accumulated
console output spews forth. On the face of it that seems good,
since it lets me see output that would otherwise be lost. But,
after re-connecting to the console, it looks as if some of the
stale console output is being echoed back to the originating
console and interpreted by that shell (which remains running)
as a command. 

Here is an example.
root@www:/home/bob # tip ucom [ucom:dv=/dev/cuaU0:br#115200:pa=none:]
Stale lock on cuaU0 PID=1449... overriding.
connected
sW��cRSwh]
Apr 16 18:40:41 www sshd[42733]: error: maximum authentication attempts exceeded for root from 14.225.192.42 port 55170 ssh2 [preauth]
Apr 16 18:40:47 www sshd[42737]: error: maximum authentication attempts exceeded for invalid user admin from 14.225.192.42 port 50516 ssh2 [preauth]
[lots of old console login failure reports]
....
[roughly 100 lines of login failure messages]
....
bob@www:~ % Apr 16 13:32:18 www sshd[42185]: fatal: Timeout before authentication for 110.7.52.1xJ^s
Apr: No match.
bob@www:~ % 
bob@www:~ % load: 2.98 not a controlling terminal
load:: Too many arguments.
bob@www:~ % 
bob@www:~ % ^R
Modifier failed.
bob@www:~ % 
bob@www:~ % Apr 16 13:32:18 www sshd[42185]: fatal: Timeout before authentication for Þ×gs^R
Apr: No match.
bob@www:~ % 
bob@www:~ % ×^s×^PgcÒÖs×ëgsÒÖs×ëãcJÖ^@Apr 17 08:38:42 www sshd[45444]: error: Fssh_kex_exchange_identification: read: Connection reset by peer
Apr 17 08:45:19 www sshd[45466]: error: Fssh_kex_exchange_identification: read: Connection reset by peer

It looks like the final lines include error messages issued by the shell running on the
serial console. I didn't type them and wonder how input might be delivered to the shell.

Is it possible that the usb-serial adapter is echoing received characters when tip has
exited due to failure of the ssh session? If so, that seems highly undesirable, since
console messages containing valid commands could be acted acted upon with the priviledge
associated with the shell, which can be and is sometimes root.

Apologies in advance if this is a dumb idea, but I'm seeing lots of very naive ssh
attacks and starting to wonder if there's an ulterior motive for them. 

Thanks for reading,

bob prohaska