Serial connections

[JMJ_coder]

Hello,

I am looking for information on serial connections (as in a serial console) - setting them up, what they are useful for, why use one, etc.

[J65nko]

The OpenBSD Faq has a nice section about serial consoles : http://www.openbsd.org/faq/faq7.html#SerCon
I install OpenBSD snapshots via serial console, just to have a log of what I have done.

The FreeBSD handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html

[BSDfan666]

OpenBSD's FAQ answers your question:
http://www.openbsd.org/faq/faq7.html#SerCon


Recording console output (for documentation).
Remote management.
Easier maintenance of a large quantity of machines
Providing a useful dmesg from machines which might otherwise be difficult to get one from.
Providing an accurate "trace" and "ps" output if your system crashes so developers can have a chance to fix the problem.


I use them for maintenance, but historically it was the only way to interface with Unix systems.

All terminals have a tty device associated with them.. on OpenBSD, the keyboard/mouse and monitor are presented to the system as several "vt100-compatible" terminal devices.

Example:
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
wsmouse0 at pmsi0 mux 0

/dev/ttyC0 being first console, /dev/ttyC5 the last, switching between virtual consoles is done via CTRL+ALT+Fn keys.

SSH/RSH/Telnet connections use use pseudo-terminals, aka "pty" devices..

Now, "getty" plays an important role on Unix systems, it manages the initialization of terminals and invokes the login(1) program when appropriate, by default, getty isn't usually listening on your serial ports...

The first serial port is typically "ttyp0", so to use that..

In /etc/ttys, I would change:
tty00 "/usr/libexec/getty std.9600" unknown off
to:
tty00 "/usr/libexec/getty std.9600" vt220 on secure

And that's about it... to use this port, you'll need a "null-modem" cable and terminal software on the remote system.. "secure" in the above line permits root login.

[phoenix]

My notes from setting up a serial console on FreeBSD 5+ to use the remote management cards in our servers:

Enabling a Serial Console
The following will allow you to use the Tyan SMDC hardware and Tyan TSO software to remotely connect to a FreeBSD box and control it as if you were sitting in front of it. It works at the hardware level, giving you remote access to the boot sequence, BIOS messages, hardware monitoring, and a serial console (over TCP/IP).

You'll need to configure the OS to use a serial console in order to see anything once the boot loader and kernel take over. The following instructions will get things working on FreeBSD:

Edit /boot/loader.conf to enable output to serial and video consoles simultaneously:
hint.sio.1.flags="0x30"
console="comconsole vidconsole"
comconsole_speed="19200"
boot_multicons="yes"
Edit /etc/make.conf to set the serial console speed (used when we recompile the boot blocks):
BOOT_COMCONSOLE_PORT=0x2F8
BOOT_COMCONSOLE_SPEED=19200
Edit /etc/ttys to enable the serial console and set the console speed used:
ttyd1 "/usr/libexec/getty std.19200" vt100 on secure
Rebuild the boot loader
# cd /usr/src/sys/boot
# make clean
# make depend
# make
# make install
Install the new boot blocks
Note: replace ad4 with the boot device node
bsdlabel -B /dev/ad4s1
Reboot
shutdown -r now
Voila!

All output will now go to the serial console and the video console simultaneously. Once the init process starts, a separate getty process will be loaded for the serial console. Connecting via the serial console will display a login screen, same as connecting via the video console, SSH, telnet, etc.

[ocicat]

...what they are useful for, why use one, etc.
Serial connections are good for controlling & monitoring headless systems in the absence of a network connection. Sun hardware is especially good of redirecting console output to a serial port if a keyboard & monitor are not detected at boot. In contrast, the classic Wintel hardware configuration is particularly bad at this especially if you want to access the BIOS configuration of a headless system at boot. This is why you will find the headless Wintel world depending on KVM's which emulate keyboard/video/mouse connections -- hooking up monitors & keyboards is the only way to gain this kind of control.

[ai-danno]

As a network administrator, I use serial connections on a daily basis, connecting to routers and switches in the lab getting them ready for production in the network.

OpenBSD makes it's easy to establish a serial connection from the command line in the Windows Hyperterminal fashion (without the clunkiness)-


cu -l cua00
establishes a serial connection on a db-9 serial port (known to the OS as "cua00") to your average Cisco or Juniper switch/router on the default 9600 bps. "man cu" ("cu" stands, I believe, for "Call Unix") for more. I showed this to one of my coworkers who's Unix-wary... his response was "that's all there is to it?"

[dk_netsvil]

Serial access to network hardware is a requirement since you will find it extremely rare, nigh impossible, to locate a piece of enterprise hardware with a web-based GUI. Managing Cisco routers/switches, HP switches, UPS units and managed power strips all require serial console access. Additionally, when there happens to be some network-related issue that prevents SSH access to a server I find that having yourself a serial backdoor to be very useful, especially at 3am when driving into the data center is the only other option.

Additionally you may find some servers can only be accessed via console, at least initially - some examples include Sun Netra T1s and SGI Origin servers, both of which are classified as "headless," meaning "no VGA port."

On BSD I also use the cu command, which I think stands for "call up a system," using the syntax (for a directly connected machine):

cu -s 9600 -l /dev/ttysomething

[phoenix]

Serial access to network hardware is a requirement since you will find it extremely rare, nigh impossible, to locate a piece of enterprise hardware with a web-based GUI. Managing Cisco routers/switches, HP switches, UPS units and managed power strips all require serial console access.

HP switches don't require console access. You can do everything via telnet/ssh/http. Console access is just one of many options.

[dk_netsvil]

I'll amend and state that, while other options like ssh and telnet exist for some devices, I prefer the console option in nearly all cases because it will be available if the device loses it's network configuration for some reason.

[ai-danno]

One tip I'll add here about my serial connections to my network devices- as much as possible, I change the baud rate to 38400. This gets rid of the clunky slowness at the (often) default rate of 9600. Makes it seem as fast as your average ssh or telnet session.

It also makes things a bit more confusing for the rogue individual who thinks they can just serial up to your device physically and see something. Not a real security measure, mind you, but more like a bump in the road.