How to connect 2 AlphaServers using only the serial ports

[Geert Van Pamel]

I have 2 AlphaServers -- the first is fully operational into the network, the second does not have a network (yet). I can log into the second server using a serial cable from my laptop using KEAterm.

But when I am at home, and the second server is in the office, the serial cable is of no use.

The 2 AlphaServers are physically next to each other, and they have both 2 serial ports. Both are running Tru64 5.1B

I am wondering how I could connect from the first AlphaServer to the second using the serial console of both machines.

To be clear: I want to login to root from the first AlphaServer serial port 1 to the second AlphaServer serial port 0 using a (cross) serial cable... since the first AlphaServer is reachable from the network, I could still reach the console of the second AlphaServer when I am working from home...

What are the commands I could use? Which settings? Thanks!

[Steven Schweda · Accepted solution]

The usual command to talk to a serial port
for an outgoing connection is "tip". (See
"man tip".) Kermit might be good for this,
too.

Probably because no one uses "tip" any more,
the data in "/etc/remote" appear to be
pretty useless, as the most common device
name ("/dev/ttyd0") does not exist. I added
lines like:

tty00:dv=/dev/tty00:br#9600 # Upper port.
tty01:dv=/dev/tty01:br#9600 # Lower port.

(On my XP1000, the upper serial port is "0",
and the lower port is "1". I don't know
what's where on your (unidentified)
hardware.)

Pick a faster speed ("br" = "baud rate") if
you'd like, or override it on the "tip"
command line. If you'd like any exotic
options, you can create a "~/.tiprc" file.
For example:

urtx# cat ~/.tiprc
escape=#
urtx#

Then:

urtx# tip -v tty00
can't open log file
set escape=#
connected

I'm ALP. Who are you?

Username: sms
Password:

Welcome to VMS (Alpha) V7.3-2 on ALP.
<...>

the "0" serial port on the Tru64 system was
connected.>

alp $ logout
SMS logged out at 4-AUG-2006 00:23:49.89

my "tip" escape character has been set to
"#" by the "~/.tiprc" file.)>
[EOT]
urtx#


I haven't looked into the complaint about the
log file.


For the incoming side, you need to add a line
(or two) to "/etc/inittab", like:

tty00:34:respawn:/usr/sbin/getty /dev/tty00 9600 vt100

Again, a different speed could be specified.
See "man getty" for details.

And then "kill -HUP 1" to get the "init"
process to re-read the file (and start a
"getty" process on the specified port(s)).

After that, what could go wrong? (Well, you
could try to use "tip" on a line where
"getty" is running.)

Around here:

urtx# sizer -v
Compaq Tru64 UNIX V5.1B (Rev. 2650); Sat Jan 28 11:47:04 CST 2006

[Geert Van Pamel]

Thanks, Steven!

Your solution works (nearly) perfectly! Now I can login on the console on the server that has no network (even from home).

This is what I have done:

* Enabled "tip" on the networked server

tty01:dv=/dev/tty01:br#9600

* Connect a serial 9-pin cross cable from tty01 on the networked server to the target console tty00 port of the server without network

* tip tty01

connected
login: root
Password:

However the following does *not* work:

vi ~/.tiprc
escape=#

When I type the # when connected to the other server, the "local" system keeps asking me for the "remote" system's user/passsword -- The only option to is to kill the shell running the local "tip" with kill -9

If this last issue could be solved, I would be a very happy sysman.

[Geert Van Pamel]

Basically the solution described by Steven works.

I have tried to use a higher tty00 speed on the target console (9600 is really slow) but the system pretends that 9600 is the highest possible speed!

>>>set com1_baud ?
bad value - valid selections:
57600
...

>>>set com1_baud 57600
Embedded Remote Console only supports 9600 baud. Continue? (Y/[N]) n
bad value - com1_baud not modified

Why could a higher speed not be possible? HW limitation? Console settings? I am on an AlphaServer 1200

[Geert Van Pamel]

The "tip" utility seems only to exist for Tru64. I have also Linux servers... does something similar exist for Linux??

[Steven Schweda]

I thought that every real UNIX had a "tip",
so it's a mystery to me why Linux wouldn't.

Google did find this:

http://www.kevininscoe.com/geek/serial/linux/

Perhaps Kermit _is_ the best answer.

[Geert Van Pamel]

To avoid going to the data center when one of the two machines has a network problem, we can interconnect the 2 consoles with 2 serial cables and configure the "remote" console on each of the "local" systems.

(do this on both of the systems)
vi /etc/remote
...
# We want to use tip (serial console login)
tty01:dv=/dev/tty01:br#9600

Then we connect the "local" system tty01 to the "remote" console tty00, and vice versa -- using 2 normal 9-pin serial cables.

In case of a network problem on one of the 2 machines, we can still "tip" to the console via the (working) network of the other machine.

Actually, you can shutdown one of the servers, or stop the network, perform some work via the serial console, and reboot the system again, all from a remote telnet or ssh session via the "stand-by" system.

[Steven Schweda]

You might also consider using a (TCP/IP,
probably not LAT) terminal server for this
sort of thing. That way, anyone with a
network connection to the terminal server
could get to a serial port on any system.
(Well, any system which had a serial port
connected to a suitably configured port on
the terminal server.)

With a terminal server, you need only one
serial port per system, so it'd work with
more than two systems, too.

[Geert Van Pamel]

Steven,

Yes I know... a terminal server is the real solution... but for 2 serial null-modem cables I only pay 20 (?) euro, the implementation is straightforward, and actually the only thing I need for 2 servers. How much would a terminal server cost (2nd hand)?

For Linux Red Hat systems, the minicom program works nearly identical:

man minicom
minicom -o tty01

Ctrl-A Z O "Serial port setup"

You really helped me through!!

[Steven Schweda]

I run VMS on my primary system, so LAT is not
a limitation, and so I still use an old
DECserver 200/MC for my stuff. Thus, I
haven't looked for incredible bargains on
terminal servers lately. I assume that old
junk (like mine) is cheap, while good stuff
costs more.

As I recall, Tru64 offers LAT, too, so if it
were also available on Linux (which it might
be), you might be able to use old junk, too.