Re: USB-serial adapter suggestions needed

On Jan 12, 2024, at 17:52, bob prohaska <fbsd@www.zefox.net> wrote:

> On Fri, Jan 12, 2024 at 05:18:25PM -0800, Mark Millard wrote:
>> Do you have the following sort of thing in each /etc/sysctl.conf ?
>> 
>> #
>> # Together this pair avoids swapping out the process kernel stacks.
>> # This avoids processes for interacting with the system from being
>> # hung-up by such swapping out of process kernel stacks (and other
>> # types of processes as well).
>> vm.swap_enabled=0
>> vm.swap_idle_enabled=0
> 
> Not on pelorus.zefox.org, www.zefox.com, nemesis.zefox.com, fixed now.
> The rest already had the setting.
> 
> While checking, I logged in as root on the serial consoles of each host.
> When I tried to log in to www.zefox.net the response was

This and http://www.zefox.net/~fbsd/tiptrouble/corrupt_mac do not
make clear the full chain of connections. In fact the presentation
seems inconsistent with other information so various things may
have changed.

Some context based on prior (out of date?) information:

  |-50.1.20.30 ns1.zefox.net Pi2 12.3 armv7 ftdi usb-serial----50.1.20.27
  |-50.1.20.29 ns2.zefox.net Pi2 12.3 armv7 2303 usb-serial----50.1.20.30
  |-50.1.20.27 www.zefox.net Pi2 12.3 armv7 2303 usb-serial----50.1.20.26

Was "pi4 RasPiOS workstation" involved as a starting place? If so, what
sequence gets to www.zefox.net from there? If not, where is the starting
direct login and what is the sequence to get to www.zefox.net the same
way you did?

Starting with what you showed via:

http://www.zefox.net/~fbsd/tiptrouble/corrupt_mac

(not knowing how you got there) . . .

QUOTE
FreeBSD/arm (www.zefox.net) (ttyu0)

login: root
Password:
Corrupted MAC on input.
ssh_dispatch_run_fatal: Connection to 50.1.20.29 port 22: message authentication code incorrect
END QUOTE

50.1.20.29 is supposedly ns2.zefox.net instead of www.zefox.net
or ns1.zefox.net according to http://www.zefox.net/~fbsd/netmap .
But . . .

QUOTE
[back to shell prompt on workstation, try to reconnect to terminal server]
bob@raspberrypi:~ $ ssh 50.1.20.29
Password for bob@ns1.zefox.net:
END QUOTE

That looks to also indicate that 50.1.20.29 got to ns1.zefox.net
instead of ns2.zefox.net .

Then there is a name referenced that not referenced at
http://www.zefox.net/~fbsd/netmap at all :

QUOTE
Last login: Thu Jan 11 11:02:27 2024 from gateway.zefox.net
END QUOTE

Then there is more text indicating ns1.zefox.net is what
50.1.20.29 got to:

QUOTE
FreeBSD 12.4-STABLE r373269 GENERIC 

Welcome to FreeBSD!

[MOTD snipped]

bob@ns1:~ % su
Password:
root@ns1:/home/bob # tip ucom
END QUOTE

If ns1.zefox.net is connected to the serial port of 50.1.20.27
and if 50.1.20.27 is actually www.zefox.net then you got back
to www.zefox.net again at this point, via access to the serial
console as the last stage of getting there.

QUOTE
Stale lock on cuaU0 PID=1460... overriding.
connected
)
Too many )'s.
END QUOTE

I'll not quote the other odd text. There were numerous
reference to "root@www:~ #" and to "Too many )'s." mixed
with other odd text. For all I know, the text may be
exposing the contents of arbitrary memory.

Whatever text directly followed is not shown. It might
have been a normal looking login to www.zefox.net for
all I know.

> . . .
> 
> I've seen this only once before, I think logging in to pelorus.zefox.org.
> Re-running ssh to the terminal server

ns1.zefox.net as 50.1.20.29 ?

> and tip to www.zefox.net

That suggests that 50.1.20.29 got to ns1.zefox.net which is
connected to the serial console port of www.zefox.net (as
50.1.20.27 ?).

> connected directly to a running console root shell. Apparently the
> login attempt started a root session on the console and detached
> the tip connection.

Not shown in http://www.zefox.net/~fbsd/tiptrouble/corrupt_mac .
Good to know.

> For some reason I find that rather sinister.

You may be suffering occasional hardware or software corruptions
of material that end up going over Ethernet. When it happens in
the right kind of place (possibly more rarely than corruptions
actually happen), you end up with the ssh session crashing.

The "Stale lock on cuaU0 PID=1460... overriding" sort of notice
may well explain the garbage text: the memory involved may well
only be known to be good when the lock status is reliable at
the time, instead of being overridden.

Figuring out the hardware vs. software contribution to corruptions
is likely much harder to do than getting to this point has been.
But now you at least have evidence of an example of the type of
thing that is sometimes going on.

The bugzilla material eventually needs to be updated with something
that can be followed and noting the possible occasional hardware or
software corruptions of material that end up going over Ethernet
that are now demonstrated to be able to cause the symptoms that
you have been seeing on occasion for so long.


===
Mark Millard
marklmi at yahoo.com