xref: /NextBSD/share/man/man4/sppp.4 (revision e5d2f8730c92c4abb6de986ec4e1f39a242b9868)
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$
27.\"
28.Dd May 25, 2008
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 "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.
43Note that this layer does not provide
44network interfaces of its own, it is rather intended to be layered on
45top of drivers providing a synchronous point-to-point connection that
46wish to run a PPP stack over it.
47The corresponding network interfaces
48have to be provided by these hardware drivers.
49.Pp
50The
51.Nm
52layer provides three basic modes of operation.
53The default mode,
54with no special flags to be set, is to create the PPP connection
55(administrative
56.Em Open
57event to the LCP layer) as soon as the interface is taken up with the
58.Xr ifconfig 8
59command.
60Taking the interface down again will terminate the LCP layer
61and thus all other layers on top.
62The link will also terminate itself as
63soon as no Network Control Protocol (NCP) is open anymore, indicating
64that the lower layers are no longer needed.
65.Pp
66Setting the link-level flag
67.Em link0
68with
69.Xr ifconfig 8
70will cause the respective network interface to go into
71.Em passive
72mode.
73This means, the administrative
74.Em Open
75event to the LCP layer will be delayed until after the lower layers
76signals an
77.Em Up
78event (rise of
79.Dq carrier ) .
80This can be used by lower layers to support
81a dialin connection where the physical layer is not available
82immediately at startup, but only after some external event arrives.
83Receipt of a
84.Em Down
85event from the lower layer will not take the interface completely down
86in this case.
87.Pp
88Finally, setting the flag
89.Em link1
90will cause the interface to operate in
91.Em dial-on-demand
92mode.
93This is also only useful if the lower layer supports the notion
94of a carrier.
95Upon configuring the
96respective interface, it will delay the administrative
97.Em Open
98event to the LCP layer until either an outbound network packet
99arrives, or until the lower layer signals an
100.Em Up
101event, indicating an inbound connection.
102As with passive mode, receipt
103of a
104.Em Down
105event (loss of carrier) will not automatically take the interface down,
106thus it remains available for further connections.
107.Pp
108The
109.Nm
110layer supports the
111.Em debug
112interface flag that can be set with
113.Xr ifconfig 8 .
114If this flag is set, the various control protocol packets being
115exchanged as well as the option negotiation between both ends of the
116link will be logged at level
117.Dv LOG_DEBUG .
118This can be helpful to examine configuration problems during the first
119attempts to set up a new configuration.
120Without this flag being set,
121only the major phase transitions will be logged at level
122.Dv LOG_INFO .
123.Pp
124It is possible to leave the local interface IP address open for
125negotiation by setting it to 0.0.0.0.
126This requires that the remote
127peer can correctly supply a value for it based on the identity of the
128caller, or on the remote address supplied by this side.
129Due to the
130way the IPCP option negotiation works, this address is being supplied
131late during the negotiation, which might cause the remote peer to make
132wrong assumptions.
133.Pp
134In a similar spirit the remote address can be set to the magical
135value
136.Li 0.0.0. Ns Em *
137which means that we do not care what address the remote
138side will use, as long as it is not 0.0.0.0.
139This is useful if your ISP has several dial-in
140servers.
141You can of course
142.Nm route Cm add Ar something_or_other 0.0.0. Ns Em *
143and it will do exactly what you would want it to.
144.Pp
145The PAP and CHAP authentication protocols as described in RFC 1334,
146and RFC 1994 resp., are also implemented.
147Their parameters are being
148controlled by the
149.Xr spppcontrol 8
150utility.
151.Pp
152VJ header compression is implemented, and enabled by default.
153It can be
154disabled using
155.Xr spppcontrol 8 .
156.Sh DIAGNOSTICS
157.Bl -diag
158.It <ifname><ifnum>: <proto> illegal <event> in state <statename>
159An event happened that should not happen for the current state
160the respective control protocol is in.
161See RFC 1661 for a description
162of the state automaton.
163.It <ifname><ifnum>: loopback
164The state automaton detected a line loopback (that is, it was talking
165with itself).
166The interface will be temporarily disabled.
167.It <ifname><ifnum>: up
168The LCP layer is running again, after a line loopback had previously
169been detected.
170.It <ifname><ifnum>: down
171The keepalive facility detected the line being unresponsive.
172Keepalive must be explicitly requested by the lower layers in order to
173take place.
174.El
175.Sh SEE ALSO
176.Xr inet 4 ,
177.Xr intro 4 ,
178.Xr ppp 4 ,
179.Xr ifconfig 8 ,
180.Xr spppcontrol 8
181.Rs
182.%A W. Simpson, Editor
183.%T "The Point-to-Point Protocol (PPP)"
184.%O RFC 1661
185.Re
186.Rs
187.%A G. McGregor
188.%T "The PPP Internet Protocol Control Protocol (IPCP)"
189.%O RFC 1332
190.Re
191.Rs
192.%A B. Lloyd
193.%A W. Simpson
194.%T "PPP Authentication Protocols"
195.%O RFC 1334
196.Re
197.Rs
198.%A W. Simpson
199.%T "PPP Challenge Handshake Authentication Protocol (CHAP)"
200.%O RFC 1994
201.Re
202.Sh AUTHORS
203.An -nosplit
204The original implementation of
205.Nm
206was written in 1994 at Cronyx Ltd., Moscow by
207.An Serge Vakulenko Aq Mt vak@cronyx.ru .
208.An J\(:org Wunsch Aq Mt joerg_wunsch@uriah.heep.sax.de
209rewrote a large part in 1997 in order
210to fully implement the state machine as described in RFC 1661, so it
211could also be used for dialup lines.
212He also wrote this man page.
213Serge later on wrote a basic implementation for PAP and CHAP, which
214served as the base for the current implementation, done again by
215.An J\(:org Wunsch .
216.Sh BUGS
217Many.
218.Pp
219Currently, only the
220.Em IPCP
221control protocol and
222.Xr ip 4
223network protocol is supported.
224More NCPs should be implemented, as well as other control protocols
225for authentication and link quality reporting.
226.Pp
227Negotiation loop avoidance is not fully implemented.
228If the negotiation
229does not converge, this can cause an endless loop.
230.Pp
231The various parameters that should be adjustable per RFC 1661 are
232currently hard-coded into the kernel, and should be made accessible
233through
234.Xr spppcontrol 8 .
235.Pp
236.Em Passive
237mode has not been tested extensively.
238.Pp
239Link-level compression protocols should be supported.
240