Experimental Physics and
Industrial Control System

Michael Johnson <[email protected]> · Fri, 20 Aug 1999 12:14:09 -0400 (EDT)

	Hi,

	At Jefferson Lab, we have a two-pronged solution to the problem
of ioc booting/crashing :

	1) To monitor the systems at the console port, we use terminal
servers mounted at various places in the experimental hall.  A terminal
server has one network port (ethernet) and several serial ports.  It 
effectively multiplexes the network connection between the serial ports.
How it does this depends on the model.  We used to use DECServer 200/MC's :
these are big, do not fit easily in a rack, speak DECLAT rather than TCP/IP,
require a VAX to boot, and are not easily accessible via Unix scripts and
automated programs.  Now we use Digi Etherlites.  These are small, speak
TCP/IP, come with drivers for many Unix's and Java, and the 32 port version
is rack mountable and costs around $40.00 per serial port from our vendor.
This is not much more than a reconditioned DEC200.  We currently run
scripts and drivers on Solaris hosts which give the operator easy access
to the console ports (IE "connect ioc#1" instead of "tip /dev/cua/128").
The serial ports themselves are RJ45 jacks.  We run cat 5 (not needed for
serial communication at this speed, but convenient and cheap anyway) everywhere
and used RJ45-DSUB converters to connect to the consoles themselves.

	2) JLAB designed and build several "reset boards".  These are
single height VME boards with a microcontroller (Parallax BASIC-interpreting
PIC) and firmware written on site (by me ;).  The board has an RS422 
interface, basic hardware to pass along signals on the VME backplane like
a well-behaved board, and an output line on the reset pin of the VME 
backplane.  The principle of operation : we run 4 conductor flat line
to each reset board, daisy chaining them in a long line.  Each board listens
for its ID on the 422 line, and on certain commands sends a pulse to the
backplane resetting all.  Rather than run extra cable from the counting
room to the hall, we took advantage of existing network switches in the
hall and installed an Etherlite 422 (instead of 232) server.  The
command syntax of the boards is necessarily terse, but unix scripts
take care of connecting to the terminal server, and sending reset
commands to the appropriate reset board on a single command ("reset ioc#1").

	As for ioc's & security, I am not the expert, but I will point out
that you will always have some holes in security created by the fact that
the board needs unencrypted access to a server (tftp or rsh) to get
its kernel.  One partial solution : a switched and firewalled network.

		Thanks,

			Mike

----------------------------------------------------------------
Michael C Johnson	(email : [email protected])
Office : 757-269-5216	Pager : 757-849-5216
Jefferson Lab	(Thomas Jefferson National Accelerator Facility)
MS 12H
12000 Jefferson Avenue
Newport News, VA, 23606

On Fri, 20 Aug 1999 [email protected] wrote:

> Hi,
> 
> SLAC is tightening up security on its networks
> and so plans are in the works to disable 
> rlogin and telnet. SSH is intended to replace
> RSH commands such as rlogin,rsh,rcp ,etc and telnet.
> So does anyone know how I can use ssh to log onto
> and ioc. I thought that I had read about another
> mechanism to log onto an ioc other than rlogin and
> telnet, but I couldn't find it in the vxworks manual.
> 
> In addition we have the problem of not being
> able to log onto the ioc console if vxWorks doesn't boot
> because of some glitch in the network when rebooting. 
> Currently this requires a drive down to the
> ioc and a manual reboot. Although this doesn't happen 
> often, the remote reboot cabability is important.
> We do have a request into hardware to build a 
> something that will provide us with this functionality
> however this item is low on the priority list.  
> What are other people using to remotely reboot or
> connect to an ioc, if vxWorks hasn't booted.
> I'm looking for a cheaper solution than purchasing
> a sun station to connect to the ioc console port.
> 
>    - Thanks,
>         Kristi Luchini
> 
> PS. We are using vxWorks 5.3.1
>     VME and VXI crates (w/ mv167,niCpu030 cpu's)
>     Console ports connected to a local terminal.
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System