SPPPCONTROL(8)						    BSD System Manager's Manual 					    SPPPCONTROL(8)

NAME

     spppcontrol -- display or set parameters for an sppp interface

SYNOPSIS

     spppcontrol [-v] ifname [parameter[=value]] [...]

DESCRIPTION

     The sppp(4) driver might require a number of additional arguments or optional parameters besides the settings that can be adjusted with
     ifconfig(8).  These are things like authentication protocol parameters, but also other tunable configuration variables.  The spppcontrol
     utility can be used to display the current settings, or adjust these parameters as required.

     For whatever intent spppcontrol is being called, at least the parameter ifname needs to be specified, naming the interface for which the set-
     tings are to be performed or displayed.  Use ifconfig(8), or netstat(1) to see which interfaces are available.

     If no other parameter is given, spppcontrol will just list the current settings for ifname and exit.  The reported settings include the cur-
     rent PPP phase the interface is in, which can be one of the names dead, establish, authenticate, network, or terminate.  If an authentication
     protocol is configured for the interface, the name of the protocol to be used, as well as the system name to be used or expected will be dis-
     played, plus any possible options to the authentication protocol if applicable.  Note that the authentication secrets (sometimes also called
     keys) are not being returned by the underlying system call, and are thus not displayed.

     If any additional parameter is supplied, superuser privileges are required, and the command works in the ``set'' mode.  This is normally done
     quietly, unless the option -v is also enabled, which will cause a final printout of the settings as described above once all other actions
     have been taken.  Use of this mode will be rejected if the interface is currently in any other phase than dead.  Note that you can force an
     interface into dead phase by calling ifconfig(8) with the parameter down.

     The currently supported parameters include:

	   authproto=protoname
		   Set both, his and my authentication protocol to protoname.  The protocol name can be one of ``chap'', ``pap'', or ``none''.	In
		   the latter case, the use of an authentication protocol will be turned off for the named interface.  This has the side-effect of
		   clearing the other authentication-related parameters for this interface as well (i.e., system name and authentication secret
		   will be forgotten).

	   myauthproto=protoname
		   Same as above, but only for my end of the link.  I.e., this is the protocol when remote is authenticator, and I am the peer
		   required to authenticate.

	   hisauthproto=protoname
		   Same as above, but only for his end of the link.

	   myauthname=name
		   Set my system name for the authentication protocol.

	   hisauthname=name
		   Set his system name for the authentication protocol.  For CHAP, this will only be used as a hint, causing a warning message if
		   remote did supply a different name.	For PAP, it is the name remote must use to authenticate himself (in connection with his
		   secret).

	   myauthsecret=secret
		   Set my secret (key, password) for use in the authentication phase.  For CHAP, this will be used to compute the response hash
		   value, based on remote's challenge.	For PAP, it will be transmitted as plain text together with the system name.  Do not for-
		   get to quote the secrets from the shell if they contain shell metacharacters (or white space).

	   myauthkey=secret
		   Same as above.

	   hisauthsecret=secret
		   Same as above, to be used if we are an authenticator and the remote peer needs to authenticate.

	   hisauthkey=secret
		   Same as above.

	   callin  Require remote to authenticate himself only when he is calling in, but not when we are caller.  This is required for some peers
		   that do not implement the authentication protocols symmetrically (like Ascend routers, for example).

	   always  The opposite of callin.  Require remote to always authenticate, regardless of which side is placing the call.  This is the
		   default, and will not be explicitly displayed in the ``list'' mode.

	   norechallenge
		   Only meaningful with CHAP.  Do not re-challenge peer once the initial CHAP handshake was successful.  Used to work around bro-
		   ken peer implementations that cannot grok being re-challenged once the connection is up.

	   rechallenge
		   With CHAP, send re-challenges at random intervals while the connection is in network phase.	(The intervals are currently in
		   the range of 300 through approximately 800 seconds.)  This is the default, and will not be explicitly displayed in the ``list''
		   mode.

	   lcp-timeout=timeout-value
		   Allows to change the value of the LCP restart timer.  Values are specified in milliseconds.	The value must be between 10 and
		   20000 ms, defaulting to 3000 ms.

	   enable-vj
		   Enable negotiation of Van Jacobsen header compression.  (Enabled by default.)

	   disable-vj
		   Disable negotiation of Van Jacobsen header compression.

	   enable-ipv6
		   Enable negotiation of the IPv6 network control protocol.  (Enabled by default if the kernel has IPv6 enabled.)

	   disable-ipv6
		   Disable negotiation of the IPv6 network control protocol.  Since every IPv4 interface in an IPv6-enabled kernel automatically
		   gets an IPv6 address assigned, this option provides for a way to administratively prevent the link from attempting to negotiate
		   IPv6.  Note that initialization of an IPv6 interface causes a multicast packet to be sent, which can cause unwanted traffic
		   costs (for dial-on-demand interfaces).

EXAMPLES

     # spppcontrol bppp0
     bppp0:  phase=dead
	     myauthproto=chap myauthname="uriah"
	     hisauthproto=chap hisauthname="ifb-gw" norechallenge
	     lcp-timeout=3000
	     enable-vj
	     enable-ipv6

     Display the settings for bppp0.  The interface is currently in dead phase, i.e., the LCP layer is down, and no traffic is possible.  Both
     ends of the connection use the CHAP protocol, my end tells remote the system name ``uriah'', and remote is expected to authenticate by the
     name ``ifb-gw''.  Once the initial CHAP handshake was successful, no further CHAP challenges will be transmitted.	There are supposedly some
     known CHAP secrets for both ends of the link which are not being shown.

     # spppcontrol bppp0 
	     authproto=chap 
	     myauthname=uriah myauthsecret='some secret' 
	     hisauthname=ifb-gw hisauthsecret='another' 
	     norechallenge

     A possible call to spppcontrol that could have been used to bring the interface into the state shown by the previous example.

SEE ALSO

     netstat(1), sppp(4), ifconfig(8)

     B. Lloyd and W. Simpson, PPP Authentication Protocols, RFC 1334.

     W. Simpson, Editor, The Point-to-Point Protocol (PPP), RFC 1661.

     W. Simpson, PPP Challenge Handshake Authentication Protocol (CHAP), RFC 1994.

HISTORY

     The spppcontrol utility appeared in FreeBSD 3.0.

AUTHORS

     The program was written by Jorg Wunsch, Dresden.

BSD
								 December 30, 2001							       BSD