|
U436296 Release Notes
.h5 ix36919
SLIP support has been added to AIX.
SLIPLOGIN(8)
(March 16, 1993)
SLIPLOGIN(8)
.h5 NAME
sliplogin - attach a serial line network interface
.h5 SYNOPSIS
sliplogin (-cia) (-p loginname )
(-t ttyname )
(-b baudrate )
(-h localhost )
(-r remotehost )
(-m mtu )
(-n netmask )
(-d dialstring )
.h5 DESCRIPTION
sliplogin is used to turn the terminal line on standard input
into a Serial Line IP (SLIP) link to a remote host. To do this, the program
searches the file /etc/slip.hosts for an entry matching loginname (which
defaults to the current login name if omitted). If a matching entry
is found, the line is configured appropriately for slip (8-bit transparent
i/o) and converted to SLIP line discipline. A shell script is then
invoked to initialize the slip interface with the appropriate local and
remote IP address, netmask, etc.
The usual initialization script is /etc/slip.login but, if particular
hosts need special initialization, the file /etc/slip.login.loginname will
be executed instead if it exists. The script is invoked with the
parameters:
slipunit
The unit number of the slip interface
assigned to this line. E.g., 0 for sl0.
speed
The speed of the line.
args
The arguments from the /etc/slip.hosts
entry, in order starting with loginname.
Only the super-user may attach a network interface. The interface
is automatically detached when the other end hangs up or the sliplogin
process dies. If the kernel slip module has been configured for it,
all routes through that interface will also disappear at the same time.
If there is other processing a site would like done on hang-up, the file
/etc/slip.logout or /etc/slip.logout.loginname is executed if it exists.
It is given the same arguments as the login script.
Format of /etc/slip.hosts
Comments (lines starting with a '#') and blank lines are ignored.
Other lines must start with a loginname but the remaining arguments can
be whatever is appropriate for the slip.login file that will be executed
for that name.
Arguments are separated by white space and follow normal
sh(1) quoting conventions (however, loginname cannot be quoted).
Usually, lines have the form:
loginname local-addr remote-addr
netmask mtu opt-args
where local-address and remote-address are the IP host names
or addresses of the local and remote ends of the slip line and netmask
is the appropriate IP netmask and mtu is the interface maximum transmission
unit. These arguments are
passed directly to ifconfig(8). Opt-args are optional arguments
used to configure the line.
It is also possible to use command line flags and arguments to specify
the items found in the slip.hosts file. If present, command line
arguments take precedence over values found in the file.
The options are
as follows:
-c
Use TCP header compression.
-i
Ignore ICMP packets. All ICMP packets will be discarded.
-a
Autoenable TCP header compression if it is detected
that the remote site is using it.
-p loginname
Use loginname instead of the current login.
-t ttyname Open
ttyname instead of the current terminal.
-b baudrate Set
the baud rate to baudrate.
-h localhost
Specify the IP address of the local host.
-r remotehost
Specify the IP address of the remote host.
-m mtu Set the
maximum packet size of the interface.
-n netmask
Set an IP address netmask. Not required if address is
not subnetted.
-d dialstring
Specify a dialstring for remote slip connections.
.h5 EXAMPLE
The normal use of sliplogin is to create a /etc/passwd entry
for each legal, remote slip site with sliplogin as the shell for that entry.
E.g.,
Sfoo : pjy6 : 2010 : 1 : slip line to foo
: /tmp : /etc/sliplogin sp
(Our convention is to name the account used by remote host hostname
as Shostname.) Then an entry is added to slip.hosts that looks like:
Sfoo 'hostname' foo
netmask
.sp
where 'hostname' will be evaluated by sh to the local host
name and netmask is the local host IP netmask.
Note that sliplogin must be setuid to root and, while not a
security hole, moral defectives can use it to place terminal
lines in an unusable state and/or deny access to legitimate
users of a remote slip line. To prevent this, a site can
create a group, say slip, that only the slip login accounts
are put in then make sure that /etc/sliplogin is in group
slip and mode 4550 (setuid root, only group slip can execute
binary).
.h5 DIAGNOSTICS
sliplogin logs various information to the system log daemon,
syslogd(8), with a facility code of daemon. The messages
are listed here, grouped by severity level.
Err Severity
ioctl (TCGETS):
reason
A TCGETS ioctl to get the line parameters failed.
ioctl (TCSETS):
reason
A TCSETS ioctl to set the line parameters failed.
/etc/slip.hosts:
reason
The /etc/slip.hosts file could not be opened.
access denied
for user
No entry for user was found in /etc/slip.hosts.
Notice Severity
attaching slip
unit unit for loginname
SLIP unit unit was successfully attached.
.h5 SEE ALSO
slattach(8),
syslogd(8)
SLATTACH
.h5 PURPOSE
Attaches serial lines as network interfaces.
.h5 SYNTAX
slattach ttyname ( baudrate )
.h5 DESCRIPTION
slattach is used to assign a tty line to a network interface,
and
to define the network source and
destination addresses. The
ttyname parameter is a string of
the form "ttyXX," or
"/dev/ttyXX." The optional baudrate parameter is used to set
the
speed of the connection. If not specified, the default
of 9600
is used.
Only the super-user may attach
a network interface.
To detach the interface, use 'ifconfig interface-name down after
killing off the slattach process. interface-name
is the name
that is shown by netstat
.h5 EXAMPLES
slattach ttyh8
slattach /dev/tty01
4800
.h5 RELATED INFORMATION
The following commands: "rc" and "netstat."
.h5 ix36920
Simple Network Management Protocol running on PS/2 gives
the capability to talk to Network Managers (Monitor Programs) based
on SNMP protocol. Eg: NetView, Open View (HP).
Simple Network Management
Protocol (SNMP)
.h6 About SNMP
This LPP is not a complete network management system.
This LPP provides a minimal agent functionality.
There are no Network Operation Center (NOC) / Network
Manager tools provided with the current SNMP LPP.
.h6 Requirements
To install and use SNMP, you must have the following:
AIX PS/2 TCP/IP License Program Product installed.
One or more of the following network interfaces :
Ethernet, Token Ring, X.25
.h6 Overview
The SNMP LPP provides the following servers, tools and
libraries and file formats.
The snmpd server acts as a management agent, implementing
the Simple Network Management Protocol for Berkeley UNIX
systems.
The snmpt server acts as a trap sink.
The unixd daemon is a SMUX peer to the SNMP agent.
The snmpi is a simple program to test snmpd.
pepsy - table driven replacement for posy/pepy
The libicompat library makes an attempt of providing an
interface for similar services under different operating
system
The libtsap library contains a set of routines which implement
transport services on top of the TCP.
The libpsap library contains a set of routines which implement
presentation syntax abstractions.
AIX PS/2 SNMP Logical Layers
NOC Tools
SNMP servers / MIB
TCP/IP
Network
.h6 Configuring SNMP
The SNMP servers can be started/stopped when the system comes
up
by including the stanzas for server daemons in /etc/rc.tcpip.
Also, the file /etc/services has to be edited if you choose to
assign different ports other than the existing port numbers for
the servers.
For further configuration, files and formats for SNMP read the
following text.
--------------------------------------------------------------
NAME
pepsy - table
driven replacement for posy/pepy
SYNOPSIS
pepsy (-A) (-a)
(-f) (-hoption) (-s) module.py
DESCRIPTION
The pepsy program
reads a description of a presentation
module and produces
definitions and tables for use with the
C programming
language. It is meant to be backwards
compatible with
the posy system. (So, pepsy will ignore any
pepy-style augmentations
in the input file.)
The '-A' (All)
switch directs pepsy to generate tables for
encoders, decoders,
and printers.
The '-a' switch
directs pepsy to augment the #include file
with commentary
text.
The '-f' switch
directs pepsy to generate C macros to deallocate
the structures
it defines.
The '-h' switch
enables additional heuristics when pepsy
generates a
C language structure definition. Option '0'
enables the
default heuristics. Enabling any other option
also results
in enabling option '0'. Option '1' enables
clever but non-unique
structure naming. Option '2' enables
the generation
of arrays rather than linked-lists whenever
possible.
Normally, pepsy
prints the name of each type as it works.
The '-s' switch
disables this behavior.
FILES
module.ph
extern type definitions from module
module_tables.c
initialized tables for processing module
module-types.h
C structure definitions from module
module_pre_defs.h
Preprocessor constants for each type in module
module_defs.h
macros to support pepy routines for module's types
SEE ALSO
pepy(1), posy(1),
The ISO Development
Environment: User's Manual
AUTHOR
Andrew Worsley,
CSIRO and UCL
--------------------------------------------------------------
NAME
snmpi - really
minimal SNMP initiator
SYNOPSIS
snmpi (-a agent)
(-c community) (-f file) (-p portno) (-d)
(-v) (-w)
DESCRIPTION
The snmpi program
is an extremely simple program, used to
test snmpd.
Once snmpd is started, to see if it's running,
do:
% snmpi dump
This should generate
voluminous output.
OPTIONS
The '-a' switch
sets the address of the SNMP agent. Either
a hostname,
an IP-address, or a transport address (using
Kille's string
syntax) may be used. The default is the
localhost.
Similarly, the '-p' switch sets the UDP port
number that
the agent resides on (if an IP-style address is
given, obviously).
The default is UDP port 161.
The '-c' switch
sets the community name for the SNMP
request.
The default is public.
The '-d' switch
enables debugging. This doesn't do anything
yet.
The '-f' switch
selects a file containing compiled MIB
module definitions.
The default is objects.defs.
The '-w' switch
enables watching. When SNMP messages are
exchanged, they
will be pretty-printed on the terminal if
the user is
watching.
The '-v' switch
enables verbose interaction. This doesn't
do anything
yet.
FILES
/usr/etc/objects.defs
MIB definitions
NOTE WELL
The names of
the objects in objects.defs are case sensitive.
This was necessary
to improve the efficiency of the hashing
algorithm used
for object lookup.
SEE ALSO
RFCs 1155, 1156,
and 1157.
S.E. Kille, A
string encoding of Presentation Address,
Research Note
RN/89/14, Department of Computer Science,
University College
London, (February, 1989).
AUTHOR
Marshall T.
Rose, Performance Systems International
This work was
partially supported by the U.S. Defense
Advanced Research
Projects Agency and the Rome Air Development
Center of the
U.S. Air Force Systems Command under contract
number F30602-88-C-0016.
Although this
package is distributed with the ISODE, it is
not an OSI program,
per se. Inasmuch as the continued survival
of the Internet
hinges on all nodes becoming network
manageable,
this package was developed using the ISODE and
is being freely
distributed with releases of Berkeley UNIX.
It must be stressed
that this package is not a complete network
management system.
In particular, whilst snmpd provides a
minimal agent
functionality, there are no Network
Operation Center
(NOC) tools--snmpi is a debugging aid only.
--------------------------------------------------------------
NAME
snmpd - SNMP
agent for BSD UNIX
SYNOPSIS
/etc/snmp/snmpd
(-b size) (-d) (-t) (-x) (-z) (-p portno)
(-a x121address) (-i pid) (-r) (-s)
(under /etc/rc.local)
DESCRIPTION
The snmpd server
acts as a management agent, implementing
the Simple Network
Management Protocol for Berkeley UNIX
systems.
Upon receipt of a message, it authenticates the
request, attempts
the operation, and then returns a
response.
The managed objects
manipulated by snmpd are defined in the
file snmpd.defs,
kept in the system administrator's area.
These objects
conform to the Internet-standard Management
Information
Base (commonly referred to as MIB-I), which is
defined in RFC
1156. The rules used for naming and describing
objects are
taken from the Internet-standard Structure
of Management
Information (SMI), which is defined in RFC
1155.
At present, snmpd
permits only a read-only SNMP access mode.
This restriction
may be lifted in the future.
Most objects
are realized via reading /dev/kmem. There are
some exceptions,
which can be set via a configuration file,
which is read
once, when the daemon starts.
TRANSPORTS
For a UDP-based
network service, the server listens on port
161 for SNMP
messages. The '-p' option overrides the
default UDP
port.
For an X.25-based
network service, the server implements the
transport class
0 protocol, decodes the connection request
packet, and
execs the appropriate program to enter the protocol
and provide
the service. The '-a' switch is used to
specify the
X.121 address of the local host - this overrides
the entry in
the isotailor file. In addition, the '-i'
switch is used
to specify the protocol ID to listen on - the
default is 03018200.
Note that on most X.25 implementations,
if the local
X.121 address is not present in the isotailor
file, then the
'-a' switch must be used in order for
the server to
receive incoming calls.
For a TP4-based
transport service, the server simply listens
to any incoming
connections for selector snmp.
By default, all
network services are enabled (if defined in
the configuration).
The '-t' option specifies TCP-only
operation, the
'-x' option specifies X.25-only operation,
and the '-z'
option specifies TP4-only operation.
SMUX
The agent supports
the SNMP Multiplexing (SMUX) protocol.
To disable this,
use the '-s' option.
CONFIGURATION
The snmpd.rc
file, which is kept in the system
administrator's
area, contains customization commands. This
file must be
owned by root unless the '-r' option is given.
At present,
the directives are:
community name
address access view
defines an SNMP community called 'name' with the indicated
level of 'access'. The 'address' token is either
a hostname, an IP-address, or a network address (using
Kille's string syntax). If present and a value other
than 0.0.0.0 is used, then incoming messages claiming
to belong to the named community must come from this
address. The 'access' token, if present, is one of
readOnly, readWrite, or none, and defaults to readOnly.
The 'view' token, if present, is an object identifier,
which names the corresponding view of MIB objects that
this community may access; otherwise, it defaults to a
view containing all variables known to the agent.
view name subtree
...
defines a collection of manageable objects with the
given object identifier as its name. All variables
scoped by the 'subtree' tokens, each an object identifier,
given in the directive are placed in the view. If
no subtress are listed, the view contains all variables
known to the agent.
proxy name domain
address community
defines an SNMP proxy relationship, in terms of a view
called 'name'. Management requests for this view will
be encapsulated via the access method for 'domain' and
sent to the named address/community. At present, only
the domain 'rfc1157' (SNMP over UDP) is supported, and
the format of the 'address' token is identical to that
used by the community directive.
logging ava ...
sets the logging parameters accordingly. The one or
more 'ava' tokens are of the form attribute=value. The
attributes are: file, which is the filename for the
log, this is interpreted relative to the ISODE logging
area, unless the value starts with a slash; size, which
takes an integer value describing the maximum file size
(in KBytes) that the log should be allowed to grow;
slevel, which takes a string value indicating which
events should be logged (one of none, fatal, exceptions,
notice, trace, pdus, debug, or all); dlevel,
which says which events should not be logged; sflags,
which takes a string value indicating logging options
should be enabled (one of close (to close the log after
each entry), create (to create the log if it does not
already exist), zero (to reset the log if the size is
exceeded), and tty (to log events to the user's terminal
in addition to the file)); and, dflags, which says
which logging options should be disabled.
trap name address
view
defines a trap sink for the SNMP community called
'name', on the indicated address, which is either a
hostname, an IP-address, or a network address (using
Kille's string syntax). Note that at present, traps
sinks must be reachable via UDP (the network address
must be an IP-address). By default, a view is not
named for the trap sink.
variable name
value
sets the named variable to the indicated value. At
present, these variables may be set: sysDescr, which
takes a string value describing the management agent;
sysObjectID, which takes an OBJECT IDENTIFIER value
containing similar information; sysContact, which takes
a string value describing the person responsible for
the node; sysName, which takes a string value giving an
administratively assigned name for the node; sysLocation,
which takes a string value describing the location of
the node; and, sysServices, which takes an
integer describing the services offered by the node.
See RFC 1156 for a more thorough explanation of these
objects. (The last four are defined in MIB-II, RFC
1158, the follow-on to RFC 1156.)
variable snmpEnableAuthTraps
( enabled | disabled )
enables (or disables) the generation of authentication
Failure traps.
variable interface
name ava ...
sets attributes for the named interface. The 'name'
token is an interface name as reported by netstat -i.
The one or more 'ava' tokens are of the form
attribute=value. At present, only three attributes may
be set for each interface: ifType, which takes an
integer value describing the kind of interface;
ifSpeed, which takes an integer value describing the
speed of the interface; and, ifAdminStatus, which takes
an integer value describing the adminstrative state of
the interface. See RFC 1156 for a more thorough
explanation of these objects.
DEBUG OPERATION
If snmpd is
started interactively, or if the '-d' switch is
given, then
debug mode is entered. In this case, all logging
activity is
displayed on the user's terminal. In addition,
the logging
information is more verbose.
The '-b' switch
can be used to specify the maximum message
size supported
by the daemon. (This is useful for testing
how management
stations recover from tooBig errors.)
FILES
/etc/snmp/snmpd.defs
MIB definitions
/etc/snmp/snmpd.rc
configuration file
/etc/snmp/tmp/snmpd.log
log file
/etc/snmpd.pid
daemon PID file
NOTE WELL
The names of
the objects in snmpd.defs are case sensitive.
This was necessary
to improve the efficiency of the hashing
algorithm used
for object lookup.
SEE ALSO
RFCs 1155, 1156,
and 1157.
S.E. Kille, A
string encoding of Presentation Address,
Research Note
RN/89/14, Department of Computer Science,
University College
London, (February, 1989).
AUTHOR
Marshall T.
Rose, Performance Systems International
This work was
partially supported by the U.S. Defense
Advanced Research
Projects Agency and the Rome Air Development
Center of the
U.S. Air Force Systems Command under contract
number F30602-88-C-0016.
Although this
package is distributed with the ISODE, it is
not an OSI program,
per se. Inasmuch as the continued survival
of the Internet
hinges on all nodes becoming network
manageable,
this package was developed using the ISODE and
is being freely
distributed with releases of Berkeley UNIX.
It must be stressed
that this package is not a complete network
management system.
In particular, whilst snmpd provides a
minimal agent
functionality, there are no Network
Operation Center
(NOC) tools--snmpi is a debugging aid only.
--------------------------------------------------------------
NAME
unixd - daemon
for UNIX MIB
SYNOPSIS
/etc/snmp/smux.unixd
(-d)
(under /etc/rc.local)
DESCRIPTION
The unixd daemon
is a SMUX peer to the SNMP agent,
snmpd (8c).
At present, it implements the mbuf subtree of
the UNIX MIB.
FILES
/etc/snmp/unixd.defs
MIB definitions
NOTE WELL
The names of
the various in unixd.defs are case sensitive.
This was necessary
to improve the efficiency of the hashing
algorithm used
for object lookup.
SEE ALSO
snmpd(8c)
AUTHOR
Marshall T.
Rose, Performance Systems International
This work was
partially supported by the U.S. Defense
Advanced Research
Projects Agency and the Rome Air Development
Center of the
U.S. Air Force Systems Command under contract
number F30602-88-C-0016.
Although this
package is distributed with the ISODE, it is
not an OSI program,
per se. Inasmuch as the continued survival
of the Internet
hinges on all nodes becoming network
manageable,
this package was developed using the ISODE and
is being freely
distributed with releases of Berkeley UNIX.
--------------------------------------------------------------
NAME
snmpt - SNMP
trap sink
SYNOPSIS
snmpt (-t) (-x)
(-z) (-p portno) (-a x121address) (-i pid)
(-f audit-file)
(under /etc/rc.local)
DESCRIPTION
The snmpt server
acts as a trap sink. Upon receipt of a
message, it
simply logs it to an audit-file.
TRANSPORTS
For a UDP-based
network service, the server listens on port
162 for SNMP
messages. The '-p' option overrides the
default UDP
port.
For an X.25-based
network service, the server implements the
transport class
0 protocol, decodes the connection request
packet, and
execs the appropriate program to enter the protocol
and provide
the service. The '-a' switch is used to
specify the
X.121 address of the local host - this overrides
the entry in
the isotailor file. In addition, the '-i'
switch is used
to specify the protocol ID to listen on - the
default is 03019000.
Note that on most X.25 implementations,
if the local
X.121 address is not present in the isotailor file,
then the '-a'
switch must be used in order for
the server to
receive incoming calls.
For a TP4-based
transport service, the server simply listens
to any incoming
connections for selector snmp-trap.
By default, all
network services are enabled (if defined in
the configuration).
The '-t' option specifies TCP-only
operation, the
'-x' option specifies X.25-only operation,
and the '-z'
option specifies TP4-only operation.
DEBUG OPERATION
If snmpt is
started interactively, or if the '-d' switch is
given, then
debug mode is entered. In this case, all logging
activity is
displayed on the user's terminal. In addition, the
logging information
is more verbose.
FILES
snmpt.log
log file
snmp.traps
trap file
/etc/snmpt.piddaemon
PID file
SEE ALSO
RFCs 1155, 1156,
and 1157.
AUTHOR
Marshall T.
Rose, PSI Inc. This work was partially
supported by
the U.S. Defense Advanced Research Projects
Agency and the
Rome Air Development Center of the U.S. Air
Force Systems
Command under contract number F30602-88-C-0016.
Although this
package is distributed with the ISODE, it is
not an OSI program,
per se. Inasmuch as the continued survival
of the Internet
hinges on all nodes becoming network
manageable,
this package was developed using the ISODE and
is being freely
distributed with releases of Berkeley UNIX.
It must be stressed
that this package is not a complete network
management system.
In particular, whilst snmpd provides a
minimal agent
functionality, there are no Network
Operation Center
(NOC) tools--snmpi is a debugging aid only.
--------------------------------------------------------------
NAME
isoaliases -
ISODE aliases database
DESCRIPTION
The isoaliases
file contains information regarding local
aliases for
either user-friendly names or distinguished
names for use
with the OSI Directory.
Items are separated
by any number of blanks and/or tab
characters.
However, double-quotes may be used to prevent
separation between
arguments. The character '#' at the
beginning of
a line indicates a comment line.
The first item
is the alias, a simple string. The second
item is the
value.
USER-SPECIFIC ALIASES
By default a
user-specific aliases database is consulted
before the system-wide
aliases file. The user-specific file
is called .isode_aliases
in the user's home directory.
FILES
/etc/snmp/isoaliases
ISODE aliases database
$HOME/.isode_aliases
user-specific aliases database
SEE ALSO
dsabuild(8c),
The ISO Development
Environment: User's Manual, Volume 1:
Application
Services, The ISODE Aliases Database.
AUTHOR
Marshall T.
Rose
--------------------------------------------------------------
NAME
isoentities
- ISODE entities database
DESCRIPTION
The isoentities
file contains information regarding the
known application-entity
titles (AETs). This file is used
by the stub-directory
service in ISODE.
NB : Use of this
database is deprecated. Consult the ISODE
User's Manual
for further information.
Entries are separated
by blank lines (or the end-of-file).
Items are separated
by any number of blanks and/or tab
characters,
though double-quotes may be used to prevent
separation between
arguments. The character '#' at the
beginning of
a line indicates a comment line.
Each entry consists
of four items: the first two, the designator
and qualifier,
for the object descriptor of the
application-entity
information (the distinguished designator
default is used
for a template entry); the third item is the
object identifier
of application-entity information in
dot notation
(if no application-entity information is desired
the string NULL
should be used instead); and the fourth item
is the
entire presentation address expressed using the
ISODE string
format. Note that since double-quotes are
often used in
the new string format, it is very important to
quote them correctly
in the isoentities file. Usually
preceding the
first character of the address with single
backslash is
adequate.
It is suggested
for readability purposes that a blank line
should seperate
entries.
Note that this
database is used by the stub-directory service
in ISODE.
A real directory uses an entirely different
mechanism for
resolving lookups. The stub-directory mechanism
in ISODE transforms
the internal AET notion (the object
identifiers)
into one which appears to have come from a real
directory (i.e.,
application-entity information).
RFC1085 SUPPORT
Since applications
using RFC1085 (the lightweight presentation
protocol) usually
demultiplex on the basis of TCP or
UDP port, a
further definition for the qualifier is placed
in /etc/services,
one of:
qualifier portno/lpp
qualifier portno/tcp
qualifier portno/udp
The first alternative
says that the service lives on both
TCP and UDP; the second alternative says that the service
lives on TCP
only; and, the third alternative says that the
service lives
on UDP only.
FILES
/etc/snmp/isoentities
ISODE entities database
SEE ALSO
isobjects(5),
isoservices(5),
The ISO Development
Environment: User's Manual, Volume 1:
Application
Services, The ISODE Entities Database.
AUTHOR
Marshall T.
Rose
with design
conceptualization by Stephen E. Kille, University
College London.
--------------------------------------------------------------
NAME
isomacros -
ISODE macros database
DESCRIPTION
The isomacros
file contains information regarding local macros
for network
addresses.
Items are separated
by any number of blanks and/or tab characters.
However, double-quotes
may be used to prevent
separation between
arguments. The character '#' at the
beginning of
a line indicates a comment line.
The first item
is the macro, a simple string. The second
item is the
prefix for the corresponding network address.
USER-SPECIFIC MACROS
By default a
user-specific macros database is consulted
before the system-wide
macros file. The user-specific file
is called .isode_macros
in the user's home directory.
FILES
/etc/snmp/isomacros
ISODE macros database
$HOME/.isode_macros
user-specific macros database
SEE ALSO
isoentities(5),
The ISO Development
Environment: User's Manual, Volume 1:
Application
Services, The ISODE Macros Database,
A string encoding
of Presentation Address, S.E. Kille
An Interim approach
to use of Network Addresses, S.E. Kille
AUTHOR
Marshall T.
Rose
--------------------------------------------------------------
NAME
isobjects -
ISODE objects database
DESCRIPTION
The isobjects
file contains information regarding the known
objects on the
host.
Items are separated
by any number of blanks and/or tab
characters.
However, double-quotes may be used to prevent
separation between
arguments. The character '#' at the
beginning of
a line indicates a comment line.
The first item
is the descriptor of the object, a simple
string.
The second item is the corresponding object identifier.
FILES
/etc/snmp/isobjects
ISODE objects database
SEE ALSO
isoentities(5),
isoservices(5),
The ISO Development
Environment: User's Manual, Volume 1:
Application
Services, The ISODE Objects Database.
AUTHOR
Marshall T.
Rose
--------------------------------------------------------------
NAME
isoservices
- ISODE services database
DESCRIPTION
The isoservices
file contains information regarding the
known services
on the host.
NB : Use of this
database is deprecated. Consult the ISODE
User's Manual
for further information.
Items are separated
by any number of blanks and/or tab
characters.
However, double-quotes may be used to prevent
separation between
arguments in the vector. The character
'#' at the beginning
of a line indicates a comment line.
Each line consists
of the name of the provider, a slash, and
the name of
the entity residing above the provider; the
selector used
to identify the entity to the provider; and,
the program
and argument vector to execvp when the service
is requested.
If the selector starts with a hash-mark ('#')
it is interpreted
numerically as a decimal short-word quantity;
otherwise if
it appears in double-quotes, it is interpreted
as an ascii
string, with the usual escape mechanisms
for introducing
non-printable characters; otherwise, it is
interpreted
as an exploded octet string.
FILES
/etc/snmp/isoservices
ISODE services database
SEE ALSO
isoentities(5),
isobjects(5),
The ISO Development
Environment: User's Manual, Volume 2:
Underlying Services,
The ISODE Service Database.
AUTHOR
Marshall T.
Rose
--------------------------------------------------------------
NAME
isotailor -
ISODE tailoring file
DESCRIPTION
The isotailor
file contains information used to run-time
configure the
ISODE distribution. Entries are separated by
end-of-line
(or the end-of-file). The character '#' at the
beginning of
a line indicates a comment line. The syntax
is:
variable: value
as in
sbindir: /usr/etc/
The entries come
in several types. There are general ISODE
configuration
parameters, operating system specific tailoring
and interface
specific tailoring parameters.
LOCAL ENVIRONMENT TAILORING
There are some
variables that are used to make up for
deficiencies
in operating systems, or to override the operating
system. These
are described as follows.
localname
This takes a string as a parameter and is used as the
name of the local host if the gethostname call (or
equivalent, e.g., uname) is not used. This will also
override any other run-time determination of the local
hostname.
binpath
This takes a string as a parameter and indicates the
directory where the ISODE user programs are kept (be
sure to use a trailing slash).
sbinpath
This takes a string as a parameter and indicates the
directory where the ISODE system programs are kept (be
sure to use a trailing slash).
etcpath
This takes a string as a parameter and indicates the
directory where the ISODE configuration files are kept
(be sure to use a trailing slash).
LOGGING TAILORING
There are a
number of options that can be set for each layer
of ISODE.
The first variable indicates the default logging
directory, the
other variables give information about each
log file.
logpath
This variable takes a string as a parameter and indicates
the directory where the ISODE log files are kept
(be sure to use a trailing slash).
The remaining
variables are all configured in the same way
and are in the
general format:
xyzlevel:
(none) (exceptions) (notice) (pdus) (trace) (debug) (all)
xyzfile:
filename
The filename
can be either the name of a file of a '-' in
which case the
standard error is used. If the filename contains
the string '%d'
then this is replaced by the current
process id.
The normal level
for this style of tailoring is to set
exceptions.
The other two values can be added in when debugging,
if so desired.
The current variables in this format
are as follows.
compatlevel native services subsystem
compatfile
addrlevel addressing subsystem
addrfile
tsaplevel transport level
tsapfile
ssaplevel session level
ssapfile
psaplevel presentation elements
psapfile
psap2level presentation level
psap2file
acsaplevel association control level
acsapfile
rtsaplevel reliable transfer level
rtsapfile
rosaplevel remote operations level
rosapfile
TRANSPORT STACK TAILORING
There are several
variables which can be used to en/disable
configured TS-stacks
and to define OSI communities and their
relationship
to this system.
TS-STACKS
ts_stacks
which takes one or more of the following values:
(tcp) (x25) (bridge) (tp4) (all)
indicates which TS-stacks should be enabled. This is
useful when multiple machines (with different interfaces)
share the same executables. For example, the
/etc/snmp/isotailor file is a normally symbolic link to
/private/etc/snmp/isotailor.
OSI COMMUNITIES
ts_interim
which takes one or more OSI community names as a value.
Each community name must be defined as a macro in the
isomacros (5) file.
ts_communities
which takes one or more of the following values:
(int-x25) (janet) (internet) (realns) (localTCP) (all)
This variable is used to distinguish membership in
various OSI communities. For example, a site with an
X.25 connection might be attached to the International
X.25 network, but not the JANET. Thus ts_stacks would
include x25, and ts_communities would include int-x25
but not janet. Note that the ordering of communities
is important: network addresses will be tried in the
order that their respective communities are listed with
this variable.
default_nsap_community
which takes an integer value, declaring the default
community to be used for NSAP addresses.
default_x25_community
declaring the default community to be used for X.25
(DTE) addresses.
default_tcp_community
declaring the default community to be used for TCP
(RFC1006) addresses.
TS-BRIDGE
These are the
parameters that are used in the Transport
Service Bridge
implementation.
tsb_communities
A list of pairs of values. The first of each value
should be a community as defined in the ts_communities
variable (obviously the values none and all are not
permissible). The second value of the pair should be a
presentation address using the ISODE string format.
When a call is to be placed and the network corresponds
to one of the communities given here, then a call
through the bridge given in the second variable will be
made automatically.
tsb_default_address
This variable contains a string encoded presentation
address which the bridge will listen on by default.
This should normally consist of a set of network
addresses with no selectors present.
Consider the
case of a host with access to both the Internet
and the International
X.25 network. This host might have
this entry in
its isotailor file:
tsb_default_address: Internet=sheriff+17004\|Int-X25(80)=23426020
017299+PID+03018000
This tells the
bridge to listen on two network endpoints.
Hosts in the
Internet community wishing to reach the
International
X.25 community would have this entry in their
isotailor file:
tsb_communities: int-x25 Internet=sheriff+17004
Similarly, hosts
in the International X.25 community wishing
to reach the
Internet community, would have the entry:
tsb_communities: internet Int-X25(80)=23426020017299+PID+03018000
INTERFACE SPECIFIC TAILORING
Most interfaces
that ISODE runs over have some form of
tailoring.
These are usually very dependent on the interface.
Each interface
which supports tailoring will now be
described.
General X.25 Tailoring
There are two
specific variables that can be used with any
X.25 interface.
x25_local_dte
This is the X.121 address that ISODE processes will
listen on by default. It may be a full X.121 address
or a sub-address.
x25_local_pid
This is the X.25 protocol ID that ISODE processes will
listen on by default. Traditionally, this is the first
four octets of the CUDF in hex-notation, e.g.,
03010100.
There are also
three variables for performing address
manipulation
as required by some network vendors.
x25_intl_zero
If this has the value 'on' then any international DTEs
(i.e. having non-local DNICs) will have a leading zero
introduced before being passed to the network.
x25_strip_dnic
If this has the value 'on' then any local DTEs (i.e.
having the local DNIC) will have this DNIC removed
before being passed to the network.
x25_dnic_prefix
This should be set to the local DNIC (the first four
digits of the DTE) of the host machine. It should only
be set if one or both of the previous two variables has
the value 'on'.
There are also
two variables for logging X.25 statistics.
x25level
Defines the level of logging to be used for X.25
statistics logging. (At present, only notice level
messages are generated.)
x25file
Defines the filename to be used for X.25 statistics
logging.
SUNLINK X.25
These setting
are only useful when SUN_X25 is defined along
with X25.
The effect of these parameters is more fully
documented in
the Sun manuals.
reverse_charge
Set to 1 or 0 to enable/disable reverse charging.
recvpktsize
sendpktsize
This should be set to one of 0 (default), 16, 32, 64,
128, 256, 512 or 1024 to set the send/receive packet
size.
recvwndsize
sendwndsize
This sets the send/receive window sizes. Legal values
are 0 (default), 7 and 127.
recvthruput
sendthruput
This sets the sending/receiving throughput values.
Legal values are 0 (default) 75, 150, 300, 600, 1200,
2400, 4800, 9600, 19200, 48000.
cug_req
Closed user group request. Set to either 0 or 1.
cug_index
Sets the closed user group index number.
fast_select_type
Sets the fast select parameters. Either 0, 1 or 2.
rpoa_req
rpoa Recognised private operating agency parameters.
CAMTEC CCL
These are used
when the Camtec X.25 is accessed via the CCL
(sockets) mechanism.
x25_outgoing_port
This selects which port on the Camtec card will be used
for outgoing calls, and takes the value A, B or #. A
and B are the two X.21 WAN interfaces and # is the Ethernet.
Listening is automatically done on all three
ports.
BRIDGE X.25
These are parameters
that are used in the tp0bridge implementation.
x25_bridge_host
The host machine that is running the tp0bridge.
x25_bridge_port
This is the TCP port that is to be used for bridging.
The default is 146, which should be in defined in
/etc/services.
x25_bridge_addr
The X.121 address of the remote host.
x25_bridge_listen
The X.121 address to listen on for incoming calls, on
the remote host.
x25_bridge_pid
The protocol ID used for listening along with the
previous address. This is encoded as a string of eight
hex digits.
x25_bridge_discrim
A string used to discriminate the network. When
attempting to place an X.25 call with BRIDGE_X25 and
real X25 configured in, this string is used to decide
which interface to use. If the string is empty, the
bridge will be used. If it is set to '-' the bridge
will not be used. If the string is anything else, it
is compared against the called X.121 address. If there
is a match, then the bridge is used, otherwise the real
interface is used.
DIRECTORY SERVICES TAILORING
There are two
variables that can be tailored:
ns_enable
This takes either the string on or off as a parameter.
If on, then the user-friendly nameservice" will be used
to perform name/address resolution. If the nameservice
lookup fails, the stub-directory will be used as a
fallback.
ns_address
This is the transport address of the nameservice. It
is specified using the ISODE string format, e.g.,
Internet=wp.psi.com+17006
which indicates that the nameservice lives in the
TCP/IP communications domain on TCP port 17006 at host
wp.psi.com. The nameservice is accessed via the OSI
CO-mode transport service, so other kinds of addresses
(e.g., X.25 addresses can be used as well).
PROGRAM-SPECIFIC TAILORING
By default a
program-specific tailoring file is consulted
before the system-wide
tailoring file. The program-specific
file is called
.myname_tailor in the user's home directory,
where myname
is the name that the program was invoked with.
FILES
/etc/snmp/isotailor
ISODE tailoring file
$HOME/.myname_tailor
program-specific tailoring file
SEE ALSO
The ISO Development
Environment: User's Manual, Volume 2:
Underlying Services,
The ISODE Tailoring File.
AUTHORS
Marshall T.
Rose
Simon Walton,
University College London
--------------------------------------------------------------
NAME
libicompat -
compatibility library
SYNOPSIS
cc ... -licompat
DESCRIPTION
The libicompat
library makes an attempt of providing an
interface for
similar services under different operating
systems.
Currently, the library works on most variants of
Berkeley UNIX
and AT&T UNIX.
FILES
None
DIAGNOSTICS
AUTHOR
Marshall T.
Rose
BUGS
To misquote
M.A. Padlipsky, sometimes when you try to make
an apple look
like an orange you get back something that
smells like
a lemon.
--------------------------------------------------------------
NAME
libtsap - Transport
Services library
SYNOPSIS
#include <isode/tsap.h>
cc ... -ltsap
DESCRIPTION
The libtsap
library contains a set of routines which implement
transport services
on top of the TCP. In essence, they
implement a
Transport Service Access Point (TSAP) interface
to the native
TCP/IP implementation on Berkeley UNIX.
Although the
ISO model is symmetric, the TCP/IP model (and
this implementation)
is based on a client/server paradigm
and hence asymmetric.
The information herein is skeletal:
consult the
User's Manual for actual examples of how ISO
servers and
clients are coded and interact with the libtsap
library.
ADDRESSES
TSAP addresses
are represented by the TSAPaddr structure.
This contains
one more more network addresses, and a
transport-selector
as found in the isoservices (5) database.
SERVER INITIALIZATION
A program providing
an ISO service is invoked under
tsapd (8c),
with the argument vector listed in the ISODE
services database.
The server's very first action is to
re-capture the
TSAP state as recorded by tsapd. This is
accomplished
by calling TInit. Information returned by this
call is equivalent
to the parameters passed by a
T-CONNECTION.INDICATION
event. If the call is successful,
the program
can then examine the argument vector that was
passed via execvp
(it's important to call TInit prior to
reading argc
and argv). If the call to TInit is not successful,
information
returned by the call indicates the reason for failure.
After examining
the information provided by TInit (and possibly
the argument
vector), the server should either accept
or reject the
connection. If accepting, the TConnResponse
routine is called
(which corresponds to the
T-CONNECT.RESPONSE
action). If the call is successful, the
interaction
is henceforth symmetric. If un-successful,
information
returned by the call indicates the reason for
failure.
If rejecting, the TDiscRequest routine is called
(which corresponds
to the T-DISCONNECT.REQUEST action), and
the program
may exit.
CLIENT INITIALIZATION
A program requesting
an ISO service calls TConnRequest
(which corresponds
to the T-CONNECT.REQUEST action). If
successful,
the interaction is henceforth symmetric. If
un-successful,
information returned by the call indicates
the reason for
failure.
TRANSPORT-DESCRIPTORS
Once a connection
has been established via a successful
return from
TConnResponse (for servers) or TConnRequest (for
clients), a
connection is referenced by a small integer
(returned in
a structure passed to these calls) called a
transport-descriptor.
The transport-descriptor appears as
an argument
to the peer routines described below.
By default, events
associated with a transport-descriptor
are synchronous
in nature: activity in the network won't
generate an
INDICATION event without program first asking to
be told of any
activity. To mark a transport-descriptor as
asynchronous,
a call to TSetIndications is made with the
addresses of
an integer function to handle these events:
routine events
func1 T-DATA.INDICATION, T-EXPEDITED DATA.INDICATION
func2 T-DISCONNECT.INDICATION
Upon a successful
return from TSetIndications, these functions
will be called
as appropriate in this fashion:
(*func1) (sd, tx);
(*func2) (sd, td);
where sd is the
transport-descriptor, tx is a pointer to a
TSAPdata structure,
and td is a pointer to a TSAPdisconnect
structure.
Any value returned by these functions is
ignored.
Note well: the
-ltsap library uses the SIGEMT signal to provide
this interface.
Programs loaded with -ltsap that use
asynchronous
transport-descriptors should NOT use SIGEMT for
other purposes.
For synchronous
multiplexing of several connections, the
routine TSelectMask
updates a file-descriptor mask and
counter for
use with select (2).
PEER
As a rule, a
fatal failure (consult the User's Manual) on
return from
any of these routines is equivalent to a
T-DISCONNECT.INDICATION.
routine action
TDataRequest T-DATA.REQUEST
TExpdRequest T-EXPEDITED-DATA.REQUEST
TWriteRequest T-WRITE.REQUEST (write user data vectors)
TReadRequest T-READ.REQUEST (synchronous read)
TDiscRequest T-DISCONNECT.REQUEST
Note that the
TReadRequest routine returns data from the
peer by allocating
memory. It should be freed before the
structure is
re-used.
Finally, the
routine TErrString takes a failure code from a
TSAPdisconnect
structure and returns a null-terminated
diagnostic string.
Also, the routine TLocalHostName returns a
null-terminated
string denoting the name of the localhost.
FILES
/etc/snmp/isoservices
ISODE services database
SEE ALSO
isoc(1c), isoservices(5),
isod(8c), isore(8c), tsapd(8c),
The ISO Development
Environment: User's Manual,
RFC1006: ISO
Transport Services on top of the TCP, Version:
3,
ISO 8072: Information
Processing Systems -- Open Systems
Interconnection
-- Transport Service Definition,
CCITT Recommendation
X.214: Transport Service Definition for
Open Systems
Interconnection (OSI) for CCITT Applications
DIAGNOSTICS
All routines
return the manifest constant NOTOK (-1) on
error.
In addition, those routines which take a pointer to
a TSAPdisconnect
structure fill-in the structure as
appropriate.
AUTHORS
Marshall T.
Rose
Dwight E. Cass,
Northrop Research and Technology Center
BUGS
Do not confuse
transport-descriptors with file-descriptors.
Unlike file-descriptors
which are implemented by the kernel,
transport-descriptors
do not work across forks and execs.
--------------------------------------------------------------
NAME
libpsap - asn.1
presentation services library
SYNOPSIS
#include <isode/psap.h>
cc ... -lpsap
DESCRIPTION
the libpsap
library contains a set of routines which
implement presentation
syntax abstractions. two primary objects
are manipulated:
presentation elements and presentation
streams.
PRESENTATION STREAMS
a stream is
an object, similar to a file* object in
stdio (3), which
is used to read and write elements. a
stream is created
by calling ps_alloc with the address of an
integer-valued
routine that will initialize certain
stream-dependent
variables (presently, the read and write
routines).
two standard initialization routines are available:
std_open, which
is used for presentation streams connected to
stdio objects;
and, str_open, which is used for
presentation
streams connected to string objects. after
ps_alloc successfully
returns, final initialization is
performed, usually
by calling either std_setup with the stdio
object to be
bound; or, str_setup with the string object to
be bound.
after the setup routine successfully returns, the
presentation
stream is ready for reading or writing.
currently streams
which have been initialized by these routines
are uni-directional.
This might change in a future
distribution.
Streams which have been initialized by
std_open and
str_open will automatically allocate additional
resources when
necessary, to the limits allowed by the
operating system
(e.g., repeated calls to a stream connected
to a string
object will result in additional memory being
allocated from
UNIX).
Low-level I/O
is done from/to the stream by the macros
ps_read and
ps_write. These both call an internal routine
which switches
to the object-specific read or write routine
as appropriate.
This internal routine, ps_io, implements
the consistent
presentation stream abstraction.
Finally, when
a stream has been exhausted, it can be closed
and de-allocated
with ps_free.
The user may
implement additional stream objects. Examine
the source to
the std_ and str_ routines to understand the
internal protocol
and uniform interface.
TRANSLATION
The routine
ps2pe can be used to read the next presentation
element from
a stream. This routine returns a pointer to
the element
or NULLPE on error. Similarly, pe2ps can be
used to write
a presentation element at the end of the
stream.
This returns returns OK if all went well, NOTOK
otherwise.
On errors with either routine, the ps_errno
field of the
stream can be consulted to see what happened.
When writing
to a presentation stream, the variable
ps_len_strategy
controls how long CONStructor types are
represented.
If this variable is equal to PS_LEN_SPAG (the
default), then
the indefinite form is used whenever the
length field
of the element can not be represented in one
octet.
If PS_LEN_INDF, then the indefinite form is used
regardless of
the length of the element. Otherwise, if
PS_LEN_LONG,
then the indefinite form is never used.
For debugging
purposes, instead of treating a presentation
stream as a
binary object, the routines pl2pe and pe2pl can
be used.
These translate between presentation lists and
presentation
elements. A list is an ASCII text representation,
with a simple
LISP-like syntax which contains semantic
information
identical to its presentation stream counterpart.
PRESENTATION ELEMENTS
Once a presentation
stream has been initialized and elements
are being read,
there are several routines that can be used
to translate
between the machine-independent representation
of the element
and machine-specific objects such as
integers, strings,
and the like. It is extremely important
that programs
use these routines to perform the translation
between objects.
They have been carefully coded to present
a simple, uniform
interface between machine-specifics and
the machine-independent
presentation protocol.
A new element
can be created with pe_alloc, and de-allocated
with pe_free
(see the warning in the BUGS section below).
Two elements
can be compared with pe_cmp, and an element can
be copied with
pe_cpy.
A boolean is
an integer taking on the values 0 or 1. The
routine prim2bool
takes an element and returns the boolean
value encoded
therein. Similarly, bool2prim takes a boolean
and returns
an element which encodes that value.
An integer is
a signed-quantity, whose precision is specific
to a particular
host. The routine prim2int takes an element
and returns
the integer value encoded therein (if the value
is NOTOK, check
the pe_errno field of the element to see if
there was an
error). The routine int2prim performs the
inverse operation.
An octetstring
is a pair of values, a character pointer and
an integer length.
The pointer addresses the first octet in
the string (which
need not be null-terminated), the length
indicates how
many octets are in the string. The routine
prim2oct takes
an element and allocates a new string
containing the
value encoded therein. The routine oct2prim
performs the
inverse operation, copying the original string
(and not de-allocating
it).
A bitvector is
an arbitrarily long string of bits with three
operations:
bit_on which turns the indicated bit on, bit_off
which turns
the indicated bit off, and, bit_test which
returns a boolean
value telling if the indicated bit was on.
The routine
prim2bit takes an element and builds such an
abstraction
containing the value encoded therein. The
routine bit2prim
performs the inverse operation.
A timestring
represents a date/time in many forms. Consult
<isode/psap.h>
for the elements in this structure. The
routines prim2utc
and utc2prim are used to translate between a
machine-specific
internal form and the machine-independent
form.
Two list disciplines
are implemented: sets, in which each
member is distinguished
by a unique identifier; and,
sequences, in
which each element is distinguished by its
offset from
the head of the list. On both types of lists,
the macro first_member
returns the first member in the list,
while next_member
returns the next member.
The routines
prim2set and set2prim are used to translate
between presentation
elements and the set list; set_add may
be called to
add a new member to the set; set_del may be
called to remove
the identified member from the set; and,
set_find may
be called to locate the identified member.
The routines
prim2seq and seq2prim are used to translate
between presentation
elements and the sequence list; seq_add
may be called
to add a new element to the sequence; seq_del
may be called
to remove the identified element from the
sequence; and,
seq_find may be called to locate the
identified element.
With both lists,
a convenient way of stepping through all
the members
is:
for (p = first_member (pe); p; p = next_member (pe, p))
switch (discriminator) {
....
}
where discriminator
is:
PE_ID (p -> pe_class, p -> pe_id)
for sets, and:
p -> pe_offset
for sequences.
FILES
None
SEE ALSO
pepy(1),
The ISO Development
Environment: User's Manual,
ISO 8825: Information
Processing -- Open Systems
Interconnection
-- Specification of basic encoding rules for
Abstract Syntax
Notation One (ASN.1),
CCITT Recommendation
X.409: Message Handling Systems:
Presentation
Transfer Syntax and Notation
DIAGNOSTICS
Most routines
either return the manifest constant NULL (0) or NOTOK (-1) on error.
In addition, routines called with a pointer to a presentation stream also
update the ps_errno field of the stream on error. The routine ps_error
returns
a null-termianted diagnostic string when given the value of this
field. Similarly, routines called with a pointer to a
presentation
element also update the pe_errno field of the
stream on error.
The routine pe_error returns a
null-termianted
diagnostic string when given the value of
this field.
AUTHOR
Marshall T.
Rose
BUGS
A virtual presentation
element option should be available to avoid reading everything in-core
during parsing.
When using pe_free
on an element, care must be taken to remove any references to that element
in other structures. For example, if you have a sequence containing a sequence,
and you free the child sequence, be sure to zero-out the parent's pointer
to the child, otherwise subsequent calls using the parent will go romping
through hyperspace.
9595 Main Page
|