snetd man page on IRIX

Man page or keyword search:  
man Server   31559 pages
apropos Keyword Search (all sections)
Output format
IRIX logo
[printable version]



SNETD(1M)							     SNETD(1M)

NAME
     snetd - DLPI network daemon

SYNOPSIS
     snetd [-nt] [ config_file | - ]

DESCRIPTION
     snetd configures a STREAMS network from a specification given in a
     configuration file whose format is described in the Configuration
     section.

     By default the configuration is taken from the file
     /etc/config/snetd.options. An alternative file may be specified as a
     command line argument (config_file).  The special filename '-' is taken
     to mean the standard input.

     Upon system startup, if the state of the snetd daemon is on, the daemon
     is started by /etc/init.d/network. You may use chkconfig(1M) to check the
     state of the daemon or to change its state.

     The -t option may be used to debug a configuration file.  It produces
     trace information indicating the sequence of opens, links, etc. performed
     by snetd to create the STREAMS architecture defined by the configuration.

     The -n option, which also implies -t , inhibits the actual building of
     the STREAMS network.

CONFIGURATION
     This section describes the configuration of the STREAMS network
     constructed by snetd.

     The file is in two sections, module and streams , separated by a line
     consisting of the character sequence '%%'.	 Blank lines may be used
     freely throughout the file, and a token (see below) beginning with an
     unquoted '#' (hash) denotes a comment which lasts till the end of the
     line.  In addition, a backslash (\) immediately preceding the end of a
     line results in the newline being treated as whitespace (except at the
     end of comment lines).

     Tokens consist either of

     a)	  a single occurrence of the special characters { '=', '{', ',', '}' }

     (Note:  '=' is not a special character within the brace-enclosed argument
     list of a control message; ',' is only a special character in this
     position.)

     b)	  strings of arbitrary characters enclosed in single or double quotes
	  (''' or '"'), but not containing a newline - each quoting character
	  quotes the other, for example, "foo 'bar'" or '"foo" bar'

									Page 1

SNETD(1M)							     SNETD(1M)

     (Newlines occurring within quoted strings will silently terminate the
     string.)

     c)	  sequences of non-whitespace characters not including any of the
	  special characters or quotes

     All strings are case-sensitive, and are silently truncated to 200
     characters.

     The modules section describes the individual modules and drivers from
     which the STREAMS network configuration will be built.

     tcp    dc	  /dev/tcp
     arp    m	  arp
     x25    dc	  /dev/x25
     lapb0  dc	  /dev/lapb0

     Each line (such as the examples above) consists of three tokens
     (separated by whitespace or tabs) as follows.

     The module identifier is the name by which the module or driver will be
     known in the streams section (see below).

     The module type is a sequence of character flags describing the module or
     driver.  The flag 'd' describes a STREAMS driver , whereas 'm' describes
     a module. The 'c' flag specifies a driver to be cloneable. (See the
     STREAMS Programmer's Guide for a detailed description of modules and
     drivers.)

     The module name is the character device name for a driver, or the
     pushable module name for a module.

     The streams section describes the architecture of the network in terms of
     how the previously defined modules and drivers are to be combined (by
     means of the appropriate PUSHes and LINKs) into streams.  Multiplexing
     and cloning are handled automatically by the snetd(1M) utility.

     ip	   arp	    IP_NET=89.0.0.3
     x25   lapb0    SHELL="x25tune -P -s A def.dte.x25" \
		    X25_SET_SNID={A, LC_LAPBDTE, , }

     Lines in this section (such as the above examples) are of the following
     form.

     The first two tokens on a line are names (module identifiers as defined
     in the previous section) of drivers or modules which are to form the
     upstream and downstream components respectively of a STREAMS link.

     Each link performed between token 1 and token 2 generates a mux_id
     (multiplexing identifier) which is associated with that link.  It is
     possible to override the generated link by replacing token 2 with an
     explicit mux_id, for example:

									Page 2

SNETD(1M)							     SNETD(1M)

     lapb0    1	    LL_SET_SNID=A \
		    SHELL="lltune -P -p lapb -s B -d /dev/lapb0 def.lapb"

     This sets the mux_id associated with the link to 1 .

     These names may be qualified by a suffix consisting of a colon (:) and a
     number (for example arp:1) to signify a particular instantiation of a
     module.  (An uninstantiated name is an abbreviation for name:0.)  Each
     instantiation of a module can be thought of as a separate block in a
     STREAMS Architecture diagram.  Separate instantiations would be
     appropriate for, say, a module pushed above more than one driver, but not
     for a cloneable multiplexed driver.

     Instantiations are used in the 'streams' section only, to instantiate
     modules defined in the 'modules' section.	The following networking
     example would run IP over two distinct networks:

     ip	      dc     /dev/ip
     arp      m	     arp
     ethr0    dc     /dev/ethr0
     ethr1    dc     /dev/ethr1

     %%

     ip	     arp:0   IP_NET=89.0.0.1
     arp:0   ethr0   ARP_TYPE

     ip	     arp:1   IP_NET=89.0.0.2
     arp:1   ethr1   ARP_TYPE

     The remainder of each line consists of a (possibly null) sequence of
     control actions to be performed on completion of the link in the order
     specified.

     Each control action is of the form function = argument-list, where the
     argument-list is either a single string argument or a comma-separated
     list enclosed in braces ({ and }).	 Control actions requiring no
     arguments may consist simply of the function component.  Arguments
     containing whitespace or any of the special characters listed above must
     be quoted.

     The following control actions are currently defined:

     IP_NET={internet-address, subnet-mask, forwb=boolean}

			 This specifies the network address and subnet mask
			 for a stream below IP, and whether broadcasts are to
			 be forwarded from other networks to that network.

			 This is typically used when a network is multiplexed
			 below an IP (Internet Protocol) driver.  The Internet
			 address and Subnet mask are given in standard

									Page 3

SNETD(1M)							     SNETD(1M)

			 Internet dot format, and may be omitted (supplied as
			 a null string) when not relevant, in which case they
			 will be passed as zero.  The broadcast flag is
			 specified as a boolean value:	y or n (for
			 'yes'/'true' - 'do forward' - or 'no'/'false' -
			 'don't forward'), or may be omitted in the default
			 case (don't forward).

			 Note:	A broadcast packet for transmission to a
			 network either originates from the host or has
			 previously been received from another network. The
			 first type is always transmitted.  The second type is
			 only transmitted if the forward broadcast flag forwb
			 is set to 'y'. This flag is only relevant when using
			 gateways.

			 In cases where only the network address is supplied,
			 the following syntax may be used

			      IP_NET=internet-address

     ARP_TYPE=trailers
			 This specifies that this stream is to be registered
			 with the network driver below as the stream on which
			 incoming IP packets are to be received.

			 In addition, trailers may take the value trailers or
			 notrailers (the default), to specify whether trailer
			 encapsulated packets should be sent on the network
			 interface.

     LL_SET_SNID=subnet-id

			 This registers the subnetwork identifier (subnet-id)
			 to be associated with this link.  The subnetwork
			 identifier provides a unique name for an outlet to a
			 board and its associated higher level streams.	 It is
			 a single alphanumeric character and is a mandatory
			 parameter.  The subnet-id correspond to the
			 associated minor device number , ie. minor 0 is 'A',
			 minor 1 is 'B', etc.

     X25_SET_SNID={subnet-id, class, local-SAP, loop-SAP}

			 This registers the subnetwork identifier to be
			 associated with this link, the class of the network
			 below the link, and the local- and loop-SAPs to be
			 associated with this subnetwork.

			 The class can be one of the following:

									Page 4

SNETD(1M)							     SNETD(1M)

			 LC_LLC1	LLC-1,
			 LC_LLC2	LLC-2,
			 LC_LAPBDTE	LAPB - DTE,
			 LC_LAPBXDTE	LAPB - DTE and extended addressing,
			 LC_LAPBDCE	LAPB - DCE,
			 LC_LAPBXCDE	LAPB - DCE and extended addressing.
			 LC_LAPDTE	LAP - DTE,
			 LC_LAPDCE	LAP - DCE,

			 The SAPs are only required for classes 'LC_LLC2' and
			 'LC_LLC1'. They are two digit hexadecimal numbers.
			 The SAPs must be even, non-zero and different.	 If
			 the class is 'LC_LLC2', and the SAPs are not present,
			 the defaults for local and loop SAPs are 0x7E and
			 0x70 respectively.  If the class is 'LC_LLC1', and
			 the SAP is not present, the default for local SAP is
			 0x7E.	For any other class, the SAPs are not used.

			 The subnet-id and class parameters are mandatory, but
			 the local-SAP and loop-SAP parameters are optional.
			 The subnet-id correspond to the associated minor
			 device number , ie. minor 0 is 'A', minor 1 is 'B',
			 etc.

     SHELL="command-string"

			 This allows calls to the shell.  Utilities may then
			 be called at an intermediate stage in the building of
			 the STREAMS network.  For example:

			 ip	 -	SHELL=" ixemap -Z; ixemap -P "

			 This particular shell call to the ixemap(1M) utility
			 deals with the IXE module internal table of X.25 and
			 Internet address associations (as described in
			 ixemapconf(4)).

			 A special dummy link exists, where no link is formed,
			 but the control action is executed.  This occurs when
			 token 2 is a hyphen ( '-' ) .

			 For example:

			 x25	 -	 SHELL="pvcmap -P"

			 which is simply a shell call to execute pvcmap .

EXAMPLES
     When the DLPI subsystem is installed, a sample configuration file is
     installed at /etc/config/snetd.options, if the file does not already
     exist.  The file contains sample configuration lines for three

									Page 5

SNETD(1M)							     SNETD(1M)

     interfaces: one token ring interface, one ethernet interface and one fddi
     interface. As 'sample' configuration lines, the configuration lines are
     commented out with an '#' sign at column one. To activate a particular
     interface, the '#' signs must be removed.	The sample configuration file
     installed by the product might contain the following network description
     depending on your system configuration.  Please note that the line
     numbers will not be in the shipped file but they are put in here for
     reference purposes.

     /*line1*/ #fv0    d       /dev/fv0
     /*line2*/ #ec0    d       /dev/ec0
     /*line3*/ #ipg0   d       /dev/ipg0
     /*line4*/ llc2    dc      /dev/llc2
     /*line5*/
     /*line6*/ %%
     /*line7*/
     /*line8*/ #llc2   fv0     LL_SET_SNID=A   \
     /*line9*/ #      SHELL="lltune -P -p llc2 -s A -d /dev/llc2 def.tokenring"
     /*line10*/#llc2   ec0     LL_SET_SNID=B   \
     /*line11*/#      SHELL="lltune -P -p llc2 -s B -d /dev/llc2 def.ether"
     /*line12*/#llc2   ipg0    LL_SET_SNID=C   \
     /*line13*/#      SHELL="lltune -P -p llc2 -s C -d /dev/llc2 def.fddi"

     To activate the token ring interface fv0, you need only take out the '#'
     signs at the beginning of the line #1, #8, and #9. Line 9 is to execute
     lltune(1M) command to set default LLC2 tuning parameters for this token
     ring interface.

     A typical configuration file for X.25 only, might contain the following
     network description.

     echo    m	     echo
     ec0     dc	     /dev/ec0
     lapb    dc	     /dev/lapb
     llc2    dc	     /dev/llc2
     wan0    dc	     /dev/wan0
     x25     dc	     /dev/x25

     %%

     llc2    ec0     LL_SET_SNID=C \
		     SHELL="lltune -P -p llc2 -s C -d /dev/llc2 def.llc2"
     x25     llc2    SHELL="x25tune -P -s C -d /dev/x25 -a 0000000000007E \
		     def.lan.x25"   X25_SET_SNID={C, LC_LLC2, 7E, 70}

     lapb    wan0    LL_SET_SNID=A \
		     SHELL="wantune -P -d /dev/wan0 -s A def.wan" \
		     SHELL="lltune -P -p lapb -s A -d /dev/lapb def.lapb"
     x25     lapb    SHELL="x25tune -P -s A -d /dev/x25 def.dte80.x25" \
		     X25_SET_SNID={A, LC_LAPBDTE, , }

									Page 6

SNETD(1M)							     SNETD(1M)

     lapb    wan0    LL_SET_SNID=B \
		     SHELL="wantune -P -d /dev/wan0 -s B def.wan" \
		     SHELL="lltune -P -p lapb -s B -d /dev/lapb def.lapb"
     x25     lapb    SHELL="x25tune -P -s B -d /dev/x25 def.dte80.x25" \
		     X25_SET_SNID={B, LC_LAPBDTE, , }

     x25     -	     SHELL="pvcmap -P"

     echo    ec0     ECHO_TYPE

     Here, wan0 and ec0 are WAN and Ethernet drivers respectively, and your
     real Ethernet driver may be ec0 , et0 , or enp0 , depending on your
     system configuration.  Note that the above is an example where lapb,
     llc2, wan0 and ec0 are in-kernel.	Instantiations are used.  Each
     instantiation can be thought of as a separate block in a STREAMS
     Architecture diagram.

     When TCP is to be run over X.25 a typical configuration file might
     contain the following extra entries to cater for the IP to X.25
     Encapsulation driver, IXE (see ixe(7)).

     ixe     dc	     /dev/ixe

     %%

     ip	     ixe     IP_NET={15.0.0.2, 255.0.0.0, forwb=n}
     ip	     ixe     IP_NET={16.0.0.2, 255.0.0.0, forwb=n}
     ixe     x25
     ixe     x25
     ixe     x25

     ip	     -	     SHELL="ixemap -Z" SHELL="ixemap -P" SHELL="ixetune"

FILES
     /etc/config/snetd
     /etc/config/snetd.options

SEE ALSO
     dlpi(7), lltune(1M), ixemap(1M), pvcmap(1M), ixemapconf(4), ixe(7).

									Page 7

[top]

List of man pages available for IRIX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net