TU Braunschweig,
Computer Science,
Operating Systems and Computer Networks
Frequently Asked Questions about Scotty
Table of Contents:
What is Scotty?
Scotty is an extension for the
Tool Command
Language (Tcl) which provides access to various TCP/IP network
protocols. The protocol interfaces allow to retrieve a buch of
information needed to write simple but powerful network management
scripts in Tcl. Scotty includes its own SNMP protocol stack, a SNMP
MIB parser as well as a GDMO MIB parser and an interface to the CMIP
protocol implementation called OSIMIS. You can also query the domain
name system (DNS), send ICMP requests, use generic TCP/UDP services,
invoke selected SUN RPCs, send and serve HTTP requests, and more.
What is the latest Scotty version?
The current Scotty version is 2.0.2. This version is based on Tcl7.4 and
Tk4.0. Older versions based on Tcl7.3 and Tk3.6 are not supported anymore.
Please make sure that you are using version 2.0.2 or later if you ask us
for help.
How do I get the sources of Scotty?
You can get the sources via ftp from
ftp.ibr.cs.tu-bs.de in
/pub/local/tkined.
Are there any binary distributions available?
Making binary distributions takes time and our experience is that
binary distribution do not reduce the number of questions per week
because most systems simply look too different. Therefore, we do not
provide binary distributions.
Is there a mailing list for Scotty?
There is a mailing list for the discussion of all topics related to
Tkined and Scotty. Just send a message to tkined-request@ibr.cs.tu-bs.de
to join this list. Messages that should appear on the list should be
send to tkined@ibr.cs.tu-bs.de.
There archive of the mailing list is accessible via the world wide web:
Are there any mirror sites for Scotty?
The following list of mirror sites may be incomplete and out of
date. If you have any corrections or additions, please send a short
note to schoenw@ibr.cs.tu-bs.de.
Are there any known portability problems?
Scotty should compile out of the box on many UNIX systems. We have
compiled Scotty on SunOS and Linux (our development platforms),
FreeBSD, HPUX, AIX and on Solaris. We had reports that it runs on
other machines as well. However, some machines required some special
attention. Send additional porting notes to schoenw@ibr.cs.tu-bs.de
so that they can be added to the list below.
- Ultrix
Some (or all?) Ultrix versions get problems if <sys/socket.h> or
<netdb> is included more than once. We suggest to fix the
/usr/include/sys/socket.h header by adding
#ifndef _SYS_SOCKET_H_
#define _SYS_SOCKET_H_
#endif
around the header. This makes sure that you can include <sys/socket.h>
multiple times and it does not hurt anything. The <netdb> header is
fixed accordingly by adding
#ifndef _NETDB_H_
#define _NETDB_H_
#endif
- Solaris
Depending on your local configuration, you will probably get error messages
from ld.so.1 when you start up scotty. The problem here is that the dynamic
linker is unable to find the appropriate shared libraries. To fix this
problem, you can set the environment variables, e.g.
setenv LD_RUN_PATH /usr/openwin/lib
setenv LD_LIBRARY_PATH /usr/openwin/lib
to point to the directories where the shared libraries can be found. For more
details consult your ld(1) man page.
Why are scotty scripts not exiting after an error?
Scotty is completely event driven. The basic event loop is very simple:
static void
EventLoop(interp)
Tcl_Interp *interp;
{
while (Tk_DoOneEvent(0)) {
/* empty loop body */
}
}
This loop stops if Tk_DoOneEvent() returns 0. This happens if there
are no more timer events registered in the event loop and there are no
file descriptors left to listen to. A scotty script therefore exits if
all file event handlers (this includes all SNMP sessions) are closed
and if there are no timer events left.
All Tcl code is evaluated in Tk_DoOneEvent(). If the evaluation stops
due to an error, Tk_DoOneEvent() will try to call the tkerror Tcl proc.
It is defined in /usr/local/lib/scotty/init.tcl:
proc tkerror {msg} {
global errorInfo
puts stderr $errorInfo
}
You can redefine this default error handler to do whatever you like,
e.g. exiting your script after printing the error message.
How is the Scotty extension related to other SNMP extensions for Tcl?
The SNMP extension in the current Scotty version is written from
scratch to directly support our Tcl SNMP API. A small note on the
history on Tcl SNMP extensions is available
via WWW for those who want to know more about why things are the way
they are.
How do I add another SNMP MIB to Scotty?
Lets assume that you want to add a MIB definition for your toaster
that is stored in the file toaster.mib. The first step is to feed the
MIB definition into Scottys mib parser to check whether Scotty is
happy with the MIB.
mib load toaster.mib
If there are errors, please check whether the MIB is broken or if
Scottys parser is unable to read the MIB file. You can tell Scotty to
load this MIB automatically by moving the MIB file into the site
specific directory, e.g. /usr/local/lib/scotty/site/toaster.mib. Now
edit or create a site specific initialization file
/usr/local/lib/scotty/site/init.tcl and add a line like:
lappend scotty_mibs $scotty_lib/site/toaster.mib
The global variable scotty_mibs holds a list of all the
MIB files that are loaded automatically. However, if you call
the mib load command before any other mib command and
before you create any snmp sessions, you will only get a very limited
set of MIBs loaded. This allows to reduce overhead if you know that
you only need a few specific MIB files.
How do I change a community string for a large number of hosts?
The answer is to make use of snmp alias definitions. The solution is
to define an alias for you community string in one of the scotty
startup file, e.g.
snmp alias local "-community foobar"
The trick is to use this alias whenever you create a SNMP session
handle for a device in your community, e.g.
snmp session -address $host -alias local
By using this indirection, you can easily change the community string
of a large number of devices by just changing one line in the startup
file
How can I decide if a device is a router or a multihomed device?
Below is some sample code that takes a SNMP session handle and returns
a boolean value (or a Tcl error if an SNMP operation fails).
proc IsMultiHomed {s} {
set ifNumber [lindex [lindex [$s get ifNumber.0] 0] 2]
if {$ifNumber == 1} {
return 0
}
set cnt 0
$s walk vbl ifType {
if {[lindex [lindex $vbl 0] 2] != "softwareLoopback"} {
incr cnt
}
}
return [expr $cnt > 1]
}
proc IsRouter {s} {
set ipForwarding [lindex [lindex [$s get ipForwarding.0] 0] 2]
if {$ipForwarding == "forwarding"} {
return [IsMultiHomed $s]
}
return 0
}
How fast is a Scotty script compared to a native implementation?
This largely depends on what you are doing. Here are the results of a
very small example. Lets assume you are running a news server and you
want to get the number of news reader by counting the entries in the
tclConnTable where tcpConnLocalPort is 119 (the nntp port number). We
have written a Scotty script and a C program based on the CMU library to count
established tcp connections to a given port. Below are some results
(no idx means that Scotty had to parse the MIB files during startup):
SparcStation 20:
1.0 real 0.2 user 0.1 sys (native version)
0.8 real 0.1 user 0.1 sys (script version)
1.5 real 0.3 user 0.2 sys (script version, no idx)
Sparc SLC:
2.6 real 1.1 user 0.6 sys (native version)
2.1 real 0.8 user 0.5 sys (script version)
3.4 real 1.5 user 0.7 sys (script version, no idx)
The Scotty script is 24 lines and 82 words (without comments) and the
native version is 125 lines and 295 words (without comments). The native
binary (dynamically linked, stripped) is about 100 KB on a Sparc and
a Scotty interpreter only containing the SNMP extension is about 300 KB
on a Sparc (dynamically linked, stripped).
How can I get Scotty to answer requests for MIB-2 objects?
You can't. The Scotty SNMP agent is not meant to replace a standard
MIB-2 agent. The basic idea is to use Scotty as an additional,
programmable agent. For this purpose, you can either run Scotty on a
different port or (if supported by your standard agent) in a native
proxy relationship.
What is Tkined?
Tkined is a network editor based
on the Tk toolkit. It has a Tcl API that allows various applications to
use Tkined as a GUI.
How does a Scotty script use Tkined?
There is a special Tcl command called ined. The command
options are described in the
Tkined man page.
Are there any Tkined scripts based on Scotty?
Below is a list of the scripts contained in the scotty distribution.
- IP Troubleshooter
- A collection of commands to test various TCP/IP services and to
retrieve status and configuration information.
- IP Monitor
- Some commands to monitor reachability / round trip times and
host performance as reported by an rstat daemon.
- IP Layout
- Commands to set the attributes of a Tkined object, to set the
icons based on DNS information and a simple layout algorithm
to structure large sets of nodes.
- IP Discover
- A script to discover the topology of an IP network or to find
routes through the internet and to display them using Tkined
objects.
- SNMP Troubleshooter
- Some commands to retrieve MIB-II information.
- SNMP Monitor
- A command to monitor MIB variables in stripcharts.
- SNMP Browser
- A MIB browser that can display the definition of MIB variables,
walk MIB subtrees and start monitor jobs for selected variables.
- Event Filter
- A simple event handling mechanism has been build on top of the
syslog daemon. The Scotty sources include a replacement for
your vendor supplied syslog daemon which can forward incoming
messages using a TCP connection. This script allows you to
filter these messages and to action if a filter matches.
- Remote Tkined Access
- A very new feature that allows you to connect a Tkined editor
(slave) to an already running (master) Tkined editor. All
changes on the map can be forwarded from the master to its slaves.
Jürgen Schönwälder / schoenw@ibr.cs.tu-bs.de
(Last update: 10 November 95)