SPPPCONTROL(8) BSD System Manager's Manual SPPPCONTROL(8)
spppcontrol - display or set parameters for an sppp interface
spppcontrol [-v] ifname [parameter[=value]] [...]
The sppp(4) driver might require a number of additional arguments or op- tional 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 settings 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 current PPP phase the interface is in, which can be one of the names dead, establish, authenticate, network, or terminate. If an authentication pro- tocol 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 displayed, plus any possible options to the authentication protocol if applicable. Note that the authentication secrets (sometimes called keys) are not returned by the underlying system call, and are thus not displayed. If any additional parameter is supplied, superuser privileges are re- quired, and the command works in 'set' mode. This is normally done quiet- ly, unless the option -v is also enabled, which will cause a final prin- tout 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's 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. Don't forget to quote the secrets from the shell if they contain shell metacharacters (or whitespace). myauthkey=secret Same as above. hisauthsecret=secret Same as above, to be used if we are authenticator and the remote peer needs to authenticate. hisauthkey=secret Same as above. callin Require remote to authenticate himself only when he's cal- ling in, but not when we are caller. This is required for some peers that do not implement the authentication proto- cols symmetrically (like Ascend routers, for example). always The opposite of callin. Require remote to always authenti- cate, regardless of which side is placing the call. This is the default, and will not be explicitly displayed in 'list' mode. norechallenge Only meaningful with CHAP. Do not re-challenge peer once the initial CHAP handshake was successful. Used to work around broken peer implementations that can't 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 current- ly in the range of 300 through approximately 800 seconds.) This is the default, and will not be explicitly displayed in 'list' mode.
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 chal- lenges will be transmitted. There are supposedly some known CHAP secrets for both ends of the link which are not displayed. $ spppcontrol bppp0 bppp0: phase=dead myauthproto=chap myauthname="uriah" hisauthproto=chap hisauthname="ifb-gw" norechallenge A possible call to spppcontrol that could have been used to bring the in- terface into the state shown by the previous example: # spppcontrol bppp0 \ authproto=chap \ myauthname=uriah myauthsecret='some secret' \ hisauthname=ifb-gw hisauthsecret='another' \ norechallenge
netstat(1), pppoe(4), 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.
The spppcontrol utility appeared in FreeBSD 3.0.
The program was written by Joerg Wunsch, Dresden. MirOS BSD #10-current October 11, 1997 2
Generated on 2014-02-10 02:47:05 by $MirOS: src/scripts/roff2htm,v 1.79 2014/02/10 00:36:11 tg Exp $
These manual pages and other documentation are copyrighted by their respective writers;
their source is available at our CVSweb,
AnonCVS, and other mirrors. The rest is Copyright © 2002‒2014 The MirOS Project, Germany.
This product includes material provided by Thorsten Glaser.
This manual page’s HTML representation is supposed to be valid XHTML/1.1; if not, please send a bug report – diffs preferred.