spppcontrol(8)

NAME

spppcontrol - display or set parameters for an sppp inter
face

SYNOPSIS

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

DESCRIPTION

The sppp(4) driver might require a number of additional ar
guments or
optional parameters besides the settings that can be adjust
ed 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 net
stat(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 au
thentication
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 displayed, plus any possible options to the authentication pro
tocol 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 privi
leges 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 in
terface. This
has the side-effect of clearing the other au
thenticationrelated parameters for this interface as well
(i.e., system
name and authentication secret will be forgot
ten).
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 pro
tocol.
hisauthname=name
Set his system name for the authentication
protocol. For
CHAP, this will only be used as a hint, caus
ing 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 forget 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 authen
ticator 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 au
thentication
protocols symmetrically (like Ascend routers,
for example).
always The opposite of callin. Require remote to al
ways authenti
cate, 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-chal
lenge peer once
the initial CHAP handshake was successful.
Used to work
around broken peer implementations that cannot
grok being
re-challenged once the connection is up.
rechallenge
With CHAP, send re-challenges at random inter
vals while the
connection is in network phase. (The inter
vals are currently in the range of 300 through approxi
mately 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 com
pression.
(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 en
abled.)
disable-ipv6
Disable negotiation of the IPv6 network con
trol 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 ini
tialization 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 possi
ble. Both
ends of the connection use the CHAP protocol, my end tells
remote the
system name ``uriah'', and remote is expected to authenti
cate 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' hisauth
name=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
Copyright © 2010-2024 Platon Technologies, s.r.o.           Home | Man pages | tLDP | Documents | Utilities | About
Design by styleshout