This is some bare-bones usage information on "srouted".  You should
have read the "README" already and compiled "srouted" as explained in
the "INSTALL" file.

RUNNING "srouted"
~~~~~~~~~~~~~~~~~

The "srouted" daemon doesn't run as a daemon!  More exactly, it
doesn't yet disown its controlling terminal, give itself a private
session, or write its tracing and error output to the system logs.

To invoke it, you will want to use a command like:

# setsid nohup ./srouted 2>/var/adm/srouted.log >/dev/null </dev/null &

The only currently supported command line option is "-t" which bumps
the trace level if it's less than 3, bumps the notification sublevel
while the trace level is equal to three, and resets the whole thing to
trace level 0 after the notification sublevel hits its maximum of 4.
"-t" can appear several times on the command line.


TRACE OUTPUT
~~~~~~~~~~~~

The following table summarizes the output you can expect to see for
various combinations of trace level and notification sublevel:

	tracelevel  tracenlevel   output
	----------  -----------   ---------------------------------
	     0          Any       Fatal errors only:  includes only
				  conditions that prevent "srouted"
				  from continuing operation.

				  (Strictly speaking, a special kind
				  of notice will also be displayed at
				  this tracelevel---namely, the route
				  table dump produced by a SIGUSR2, as
				  described below.)

	     1          Any       Fatal errors + warnings:  warnings
				  include conditions where a serious
				  problem has occurred, but "srouted"
				  is able to continue, either by
				  ignoring it or trying to work around
				  it.  (These may include reports on
				  erroneous packets received from
				  other network software.)

	     2          Any       Fatal errors + warnings + weak
				  warnings:  `weak' warnings include
				  conditions where "srouted" has 
				  encountered a valid, but odd,
				  situation.  These very often include
				  reports on unorthodox behaviour by
				  neighboring network software.

             3         Sublevel   Fatal errors + warnings + weak
				  warnings + notices:  notices include
				  all the usual debugging trace
				  output.  They report merely on
				  internal behaviour of "srouted", not
				  on any abnormal or erroneous
				  conditions.

				  Notices up to the given sublevel
				  will be produced.  See below for an
				  explanation of sublevels.

             3           0        Sublevel 0 notices:
				  Only the dullest notices.  Nothing
				  of interest will show up here.

             3           1        Sublevel 1 notices:
				  Route change notices, notices that
				  "srouted" is producing (gasp)
				  output, other rare notices.

             3           2        Sublevel 2 notices:
				  Everything about "srouted"'s actions
				  that won't fill up the logs too
				  fast.  This includes notices about
				  reception of packets and timer
				  expiration.

             3           3        Sublevel 3 notices:
				  Detail on processing of individual
				  routing entries in each received
				  packet.

             3           4        Sublevel 4 notices:
				  Information on "srouted"'s internal
				  scheduler, notes on "srouted"'s
				  input processing logic, timer
				  setting notices.


Notification sublevels 3 and 4 will probably lead to huge log files.
Notification sublevel 1 will capture most of the "interesting"
occurrences.


SIGNALLING "srouted"
~~~~~~~~~~~~~~~~~~~~

"srouted" responds to two signals.  

SIGUSR1 bumps the trace level, as described above.  Once the trace
level (and notification sublevel) has been bumped to its highest
level, it will roll back over to its lowest level.  A notice will be
placed in the log each time the trace level is changed.

SIGUSR2 causes "srouted" to place a copy of its internal routing table
into the logfile, regardless of the current notification level.  Most
fields are self-explanatory, though the "flags" field refers to the
flags beginning with the prefix "TBRTF_", as given in "table.h".


"srouted" SPEAKS?
~~~~~~~~~~~~~~~~~

"srouted" *does* produce output, as per the requirements in RFC 1058
for silent routing processes.  In addition to broadcasting an initial
request for the entire active routing table to each interface on
startup, "srouted" will respond (almost exactly as a non-silent
routing process would) to requests that come from ports other than the
standard routing ports.

This functionality has NEVER BEEN TESTED, so don't expect it to work.
