xref: /dragonfly/share/man/man4/sppp.4 (revision cfd1aba3)
1.\"
2.\" Copyright (c) 1997, 2001 Joerg Wunsch
3.\"
4.\" All rights reserved.
5.\"
6.\" Redistribution and use in source and binary forms, with or without
7.\" modification, are permitted provided that the following conditions
8.\" are met:
9.\" 1. Redistributions of source code must retain the above copyright
10.\"    notice, this list of conditions and the following disclaimer.
11.\" 2. Redistributions in binary form must reproduce the above copyright
12.\"    notice, this list of conditions and the following disclaimer in the
13.\"    documentation and/or other materials provided with the distribution.
14.\"
15.\" THIS SOFTWARE IS PROVIDED BY THE DEVELOPERS ``AS IS'' AND ANY EXPRESS OR
16.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
17.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
18.\" IN NO EVENT SHALL THE DEVELOPERS BE LIABLE FOR ANY DIRECT, INDIRECT,
19.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
20.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
21.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
22.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
23.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
24.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
25.\"
26.\" $FreeBSD: src/share/man/man4/sppp.4,v 1.8.2.5 2002/04/24 18:55:35 joerg Exp $
27.\"
28.Dd December 30, 2001
29.Dt SPPP 4
30.Os
31.Sh NAME
32.Nm sppp
33.Nd point to point protocol network layer for synchronous lines
34.Sh SYNOPSIS
35.Cd "pseudo-device sppp"
36.Sh DESCRIPTION
37The
38.Nm
39network layer implements the state machine and the Link Control
40Protocol (LCP) of the
41.Em point to point protocol (PPP)
42as described in RFC 1661.  Note that this layer does not provide
43network interfaces of its own, it is rather intended to be layered on
44top of drivers providing a synchronous point-to-point connection that
45wish to run a PPP stack over it.  The corresponding network interfaces
46have to be provided by these hardware drivers.
47.Pp
48The
49.Nm
50layer provides three basic modes of operation.  The default mode,
51with no special flags to be set, is to create the PPP connection
52(administrative
53.Em Open
54event to the LCP layer) as soon as the interface is taken up with the
55.Xr ifconfig 8
56command.  Taking the interface down again will terminate the LCP layer
57and thus all other layers on top.  The link will also terminate itself as
58soon as no Network Control Protocol (NCP) is open anymore, indicating
59that the lower layers are no longer needed.
60.Pp
61Setting the link-level flag
62.Em link0
63with
64.Xr ifconfig 8
65will cause the respective network interface to go into
66.Em passive
67mode.  This means, the administrative
68.Em Open
69event to the LCP layer will be delayed until after the lower layers
70signals an
71.Em Up
72event (rise of
73.Dq carrier ) .
74This can be used by lower layers to support
75a dialin connection where the physical layer isn't available
76immediately at startup, but only after some external event arrives.
77Receipt of a
78.Em Down
79event from the lower layer will not take the interface completely down
80in this case.
81.Pp
82Finally, setting the flag
83.Em link1
84will cause the interface to operate in
85.Em dial-on-demand
86mode.  This is also only useful if the lower layer supports the notion
87of a carrier.  Upon configuring the
88respective interface, it will delay the administrative
89.Em Open
90event to the LCP layer until either an outbound network packet
91arrives, or until the lower layer signals an
92.Em Up
93event, indicating an inbound connection.  As with passive mode, receipt
94of a
95.Em Down
96event (loss of carrier) will not automatically take the interface down,
97thus it remains available for further connections.
98.Pp
99The
100.Nm
101layer supports the
102.Em debug
103interface flag that can be set with
104.Xr ifconfig 8 .
105If this flag is set, the various control protocol packets being
106exchanged as well as the option negotiation between both ends of the
107link will be logged at level
108.Dv LOG_DEBUG .
109This can be helpful to examine configuration problems during the first
110attempts to set up a new configuration.  Without this flag being set,
111only the major phase transitions will be logged at level
112.Dv LOG_INFO .
113.Pp
114It is possible to leave the local interface IP address open for
115negotiation by setting it to 0.0.0.0.  This requires that the remote
116peer can correctly supply a value for it based on the identity of the
117caller, or on the remote address supplied by this side.  Due to the
118way the IPCP option negotiation works, this address is being supplied
119late during the negotiation, which might cause the remote peer to make
120wrong assumptions.
121.Pp
122In a similar spirit the remote address can be set to the magical
123value
124.Li 0.0.0. Ns Em *
125which means that we don't care what address the remote
126side will use, as long as it is not 0.0.0.0.
127This is useful if your ISP has several dial-in
128servers.  You can of course
129.Nm route Cm add Ar something_or_other 0.0.0. Ns Em *
130and it will do exactly what you would want it to.
131.Pp
132The PAP and CHAP authentication protocols as described in RFC 1334,
133and RFC 1994 resp., are also implemented.  Their parameters are being
134controlled by the
135.Xr spppcontrol 8
136utility.
137.Pp
138VJ header compression is implemented, and enabled by default.  It can be
139disabled using
140.Xr spppcontrol 8 .
141.Sh DIAGNOSTICS
142.Bl -diag
143.It <ifname><ifnum>: <proto> illegal <event> in state <statename>
144An event happened that should not happen for the current state
145the respective control protocol is in.  See RFC 1661 for a description
146of the state automaton.
147.It <ifname><ifnum>: loopback
148The state automaton detected a line loopback (that is, it was talking
149with itself).  The interface will be temporarily disabled.
150.It <ifname><ifnum>: up
151The LCP layer is running again, after a line loopback had previously
152been detected.
153.It <ifname><ifnum>: down
154The keepalive facility detected the line being unresponsive.
155Keepalive must be explicitly requested by the lower layers in order to
156take place.
157.El
158.Sh SEE ALSO
159.Xr inet 4 ,
160.Xr intro 4 ,
161.Xr ppp 4 ,
162.Xr ifconfig 8 ,
163.Xr spppcontrol 8
164.Rs
165.%A W. Simpson, Editor
166.%T "The Point-to-Point Protocol (PPP)"
167.%O RFC 1661
168.Re
169.Rs
170.%A G. McGregor
171.%T "The PPP Internet Protocol Control Protocol (IPCP)"
172.%O RFC 1332
173.Re
174.Rs
175.%A B. Lloyd
176.%A W. Simpson
177.%T "PPP Authentication Protocols"
178.%O RFC 1334
179.Re
180.Rs
181.%A W. Simpson
182.%T "PPP Challenge Handshake Authentication Protocol (CHAP)"
183.%O RFC 1994
184.Re
185.Sh AUTHORS
186.An -nosplit
187The original implementation of
188.Nm
189was written in 1994 at Cronyx Ltd., Moscow by
190.An Serge Vakulenko Aq Mt vak@cronyx.ru .
191.An J\(:org Wunsch Aq Mt joerg_wunsch@uriah.heep.sax.de
192rewrote a large part in 1997 in order
193to fully implement the state machine as described in RFC 1661, so it
194could also be used for dialup lines.  He also wrote this man page.
195.An Serge Vakulenko
196later on wrote a basic implementation for PAP and CHAP, which
197served as the base for the current implementation, done again by
198.An J\(:org Wunsch .
199.Sh BUGS
200Many.
201.Pp
202Currently, only the
203.Em IPCP
204control protocol and
205.Xr ip 4
206network protocol is supported.
207More NCPs should be implemented, as well as other control protocols
208for authentication and link quality reporting.
209.Pp
210Negotiation loop avoidance is not fully implemented.  If the negotiation
211doesn't converge, this can cause an endless loop.
212.Pp
213The various parameters that should be adjustable per RFC 1661 are
214currently hard-coded into the kernel, and should be made accessible
215through
216.Xr spppcontrol 8 .
217.Pp
218.Em Passive
219mode has not been tested extensively.
220.Pp
221Link-level compression protocols should be supported.
222