Certainty Solutions

Brought to you by;
www.conserver.com
www.certaintysolutions.com

Terminal Server BREAK-off

http://www.conserver.com/consoles/breakoff.html
version 1.2a - updated 5/1/2001 - dkzh
(email to break-off at conserver.com)

This page had been a catch-all for any information related to our serial BREAK testing project. Unfortunately, we started to collect a lot of loosely related information, so the information is being turned into a collection of pages.

Here are links to these pages;

An overview of Serial BREAK

We've had Serial BREAK for decades. It was a method for one device to send a signal 'in band' (within the data stream) to signal the other device to start a reset sequence. This was commonly used for a computer to signal a reset of any attached modems.

On an asynchronous serial link, each character starts with a start bit, followed by the data and parity bits, and then finished with 1-2 stop bits. The BREAK signal is defined as the data signal being toggled and held for a lenght of time that is longer than an entire character (including the start and stop bits). Many of the serial chips (UARTS) today signal a BREAK using a time duration of two characters. Older implementations (VT Terminals) used a quarter-second (250 ms.) time duration.

  • You can see how the BREAK time becomes shorter as the serial port speed increases.

Sun Microsystems computers use the serial BREAK signal to request a machine to drop to the ROM Monitor prompt. This effectively suspends all active processes running on the machine at the time. You then have to get on the serial console, and type "go" to resume processing. If you type "boot", the machine will restart, without closing down any active processes, and could possibly corrupt data (just like cycling the power while the machine is in this suspended state).

  • If the serial console receives a BREAK signal, you can't log in via the network to recover.
  • If you are already logged in when the BREAK occurs, your session is suspended.

There are some workarounds to this if you are running Solaris;

  • 2.8.x - allows you to ignore serial BREAK, remap to a key sequence
  • 2.7.x - you can load a patch to remap to keys, available from SunSolve
  • 2.6.x - you can download a patch to ignore BREAK, from SunSolve.
  • 2.5.x and below - you're stuck with the problem

Some SGI computers, and NeXT boxes also suffer from receiving BREAK on the serial console ports.

Why do we care?

We consider remote access to serial ports to be a very valuable tool in administering many large enterprise networks, and many of our peers do as well. To that end, we normally deploy a logging console server application at sites which we need to service, and we have also deployed a number of terminal servers over the years to extend our administration reach throughout those networks. This includes enterprise networks, as well as remote networks in colocation facilities.

Unfortunately, many terminal servers have what we refer to as the BREAK problem. That is, the terminal server will send what appears to be a serial BREAK signal to any attached devices at inappropriate times (when the terminal server looses power, when the power is restored, or during the boot process of the terminal server). More problematic is the fact that many of the large sites we work in use Sun workstations and computers, so;

  • Sun servers usually respond to serial BREAK by suspending processes.
  • Terminal Servers can send BREAK to all attached devices at inappropriate times.
    • Some terminal servers can support 192 devices...so you could halt 192 Suns at once...
  • You have to get on each port and type "go" to get things running again.
    • Each server can support thousands of simultaneous users, who may lose work.
    • You need to wait for the terminal servers to accept remote connections again.
    • It takes time to remotely access each port, one at a time.
    • It's hard to automate this process.

Simply put, we don't want to give up the benefits that remote access to serial consoles brings us, so we want to know which terminal servers won't cause these problems. As a result of that need, we're putting a bunch of different equipment through the mill, and telling the Web what we find out.

More about BREAK

Conserver allows remote client users to invoke the terminal server to issue a BREAK on individual serial ports, which allows the system administrator to perform critical tasks without needed to be physically close to the equipment. This is one of the features that makes Conserver useful, and popular. To that end, we don't want to add devices in between the terminal servers and the attached servers to prevent BREAK from being passed through, because they would keep the administrator from sending a BREAK through when we want to send BREAK.

Some terminal server vendors reportedly include a mode, or line settings, which will keep the serial ports from sending BREAK. While it may keep the port from sending the signal at inappropriate times, if that mode/setting also keeps Conserver from sending the BREAK signal when we need to, this would not be a useful option.

NuData sells a device (NUD-4723 non-aborting serial cable) that you can attach in-line between serial consoles and the terminal server. The devices are $100 (US), and currently available through NuData at 1-800-844-5757. (The *-warehouse vendors no longer carry this part.)

ASP Technologies manufactures a commercial console server application called Vantage, but they also manufactures some interesting hardware dongles that prevent certain devices (Digi STS-1600, Xyplex terminal servers) from sending serial BREAK! For the Digi units it is a dongle that connects between the power supply and the SCSI-attached pod. For Xyplex terminal servers, they have a unit that installs inside the chassis, and you need to use a soldering iron to install it, but this could be cheaper and easier than spending $100 US per port for the NuData devices, and you would still be able to send BREAK when you want to.

This page is http://www.certaintysolutions.com/tech-advice/consoles/breakoff.html

(The most current information will be the BREAK-off page at Conserver.com.

Copyright 2000-2001, David K. Z. Harris, N6UOW
Questions? Comments? Additions? Email break-off @ Conserver.com.
(Don't harvest my address, I don't want SPAM!)

Developed on a PowerBook DUO 230!
Illustration Artwork: CLARIS DRAW Pro
Web Page Creation: CLARIS Home Page 2.0