xref: /openbsd/share/man/man4/sppp.4 (revision 404b540a)
1.\" $OpenBSD: sppp.4,v 1.17 2009/01/31 19:37:12 sobrado Exp $
2.\"
3.\" Copyright (c) 1997 Joerg Wunsch
4.\"
5.\" All rights reserved.
6.\"
7.\" Redistribution and use in source and binary forms, with or without
8.\" modification, are permitted provided that the following conditions
9.\" are met:
10.\" 1. Redistributions of source code must retain the above copyright
11.\"    notice, this list of conditions and the following disclaimer.
12.\" 2. Redistributions in binary form must reproduce the above copyright
13.\"    notice, this list of conditions and the following disclaimer in the
14.\"    documentation and/or other materials provided with the distribution.
15.\"
16.\" THIS SOFTWARE IS PROVIDED BY THE DEVELOPERS ``AS IS'' AND ANY EXPRESS OR
17.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
18.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
19.\" IN NO EVENT SHALL THE DEVELOPERS BE LIABLE FOR ANY DIRECT, INDIRECT,
20.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
21.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
22.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
23.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
24.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
25.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
26.\"
27.\"
28.Dd $Mdocdate: January 31 2009 $
29.Dt SPPP 4
30.Os
31.Sh NAME
32.Nm sppp
33.Nd PPP and Link Control Protocol
34.Sh SYNOPSIS
35.Cd "pseudo-device sppp" Op Ar count
36.Sh DESCRIPTION
37The
38.Nm
39network layer implements the state machine and Link Control
40Protocol (LCP) of the
41Point-to-Point Protocol (PPP)
42as described in RFC 1661.
43Note that this layer does not provide network interfaces of its own, it is
44rather intended to be layered on
45top of drivers providing a point-to-point connection that
46wish to run a PPP stack over it.
47The corresponding network interfaces have to be provided by these hardware
48drivers.
49.Pp
50The
51.Nm
52layer provides three basic modes of operation.
53The default mode, with no special flags set, is to create the
54PPP connection (administrative
55.Em Open
56event to the LCP layer) as soon as the interface is taken up with the
57.Xr ifconfig 8
58command.
59Taking the interface down again will terminate the LCP layer
60and thus all other layers on top.
61The link will also terminate itself as soon as no Network Control Protocol
62(NCP) is open anymore, indicating that the lower layers are no longer needed.
63.Pp
64Setting the link-level flag
65.Cm link0
66with
67.Xr ifconfig 8
68will cause the respective network interface to go into
69.Em passive
70mode.
71This means the administrative
72.Em Open
73event to the LCP layer will be delayed until after the lower layers
74signal an
75.Em Up
76event (rise of
77.Dq carrier ) .
78This can be used by the lower layers to support
79a dial-in connection where the physical layer isn't available
80immediately at startup, but only after some external event arrives.
81Receipt of a
82.Em Down
83event from the lower layer will not take the interface completely down
84in this case.
85.Pp
86Finally, setting the flag
87.Cm link1
88will cause the interface to operate in
89.Em dial-on-demand
90mode.
91This is also only useful if the lower layers support the notion
92of a carrier (like with an ISDN line).
93Upon configuring the respective interface, it will delay the administrative
94.Em Open
95event to the LCP layer until either an outbound network packet
96arrives, or until the lower layers signal an
97.Em Up
98event, indicating an inbound connection.
99As with passive mode, receipt of a
100.Em Down
101event (loss of carrier) will not automatically take the interface down,
102thus it remains available for further connections.
103.Pp
104The
105.Nm
106layer supports the
107.Em debug
108interface flag, which can be set with
109.Xr ifconfig 8 .
110If this flag is set, the various control protocol packets being
111exchanged as well as the option negotiation between both ends of the
112link will be logged at level
113.Dv LOG_DEBUG .
114This can be helpful to examine configuration problems during the first
115attempts to set up a new configuration.
116Without this flag being set, only the major phase transitions will be
117logged at level
118.Dv LOG_INFO .
119.Pp
120It is possible to leave the local interface IP address open for
121negotiation by setting it to 0.0.0.0.
122This requires that the remote peer can correctly supply a value for it
123based on the identity of the caller, or on the remote address supplied
124by this side.
125Due to the way the IPCP option negotiation works, this address is
126supplied late during the negotiation, which could cause the remote peer
127to make false assumptions.
128.Pp
129In a similar spirit the remote address can be set to the magical
130value 0.0.0.1, which means that we don't care what address the remote
131side will use, as long as it is not 0.0.0.0.
132This is useful if your ISP has several dial-in servers.
133You can of course
134.Ic route add something or other 0.0.0.1
135and it will do exactly what you would want it to.
136.Pp
137The PAP and CHAP authentication protocols, as described in RFCs 1334
138and 1994, respectively, are also implemented.
139Their parameters are controlled by the
140.Xr ifconfig 8
141utility.
142.Sh EXAMPLES
143Display the settings for pppoe0.
144The interface is currently in the
145.Em establish
146phase and tries to connect to the remote peer;
147other possible PPP phases are
148.Em dead ,
149.Em authenticate ,
150.Em network ,
151or
152.Em terminate .
153Both ends of the connection use the CHAP protocol, the local client
154tells the remote peer the system name
155.Ql uriah ,
156and the peer is expected to authenticate by the name
157.Ql ifb-gw .
158Once the initial CHAP handshake has been successful, no further CHAP
159challenges will be transmitted.
160There are supposedly some known CHAP secrets for both ends of the link
161which are not displayed.
162.Bd -literal -offset indent
163$ ifconfig pppoe0
164pppoe0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1492
165        dev: em0 state: PADI sent
166        sid: 0x0 PADI retries: 0 PADR retries: 0
167        sppp: phase establish authproto chap authname "uriah" \e
168		peerproto chap peername "ifb-gw" norechallenge
169        groups: pppoe
170        inet 0.0.0.0 --> 0.0.0.1 netmask 0xffffffff
171.Ed
172.Pp
173A possible call to
174.Xr ifconfig 8
175that could have been used to bring the interface into the state shown
176by the previous example:
177.Bd -literal -offset indent
178# ifconfig em0 up
179# ifconfig pppoe0 0.0.0.0 0.0.0.1 netmask 0xffffffff \e
180	pppoedev em0 \e
181	authproto chap authname uriah authkey "some secret" \e
182	peerproto chap peername "ifb-gw" peerkey "another" \e
183	peerflag norechallenge \e
184	up
185.Ed
186.Sh DIAGNOSTICS
187.Bl -diag
188.It <ifname><ifnum>: <proto> illegal <event> in state <statename>
189An event happened that should not happen for the current state
190the respective control protocol is in.
191See RFC 1661 for a description of the state automaton.
192.It <ifname><ifnum>: loopback
193The state automaton detected a line loopback (that is, it was talking
194with itself).
195The interface will be temporarily disabled.
196.It <ifname><ifnum>: up
197The LCP layer is running again, after a line loopback had previously
198been detected.
199.It <ifname><ifnum>: down
200The keepalive facility detected the line being unresponsive.
201Keepalive must be explicitly requested by the lower layers in order to
202take place.
203.El
204.Sh SEE ALSO
205.Xr inet 4 ,
206.Xr pppoe 4 ,
207.Xr ifconfig 8 ,
208.Xr ppp 8
209.Rs
210.%A W. Simpson, Editor
211.%T "The Point-to-Point Protocol (PPP)"
212.%O RFC 1661
213.Re
214.Rs
215.%A G. McGregor
216.%T "The PPP Internet Protocol Control Protocol (IPCP)"
217.%O RFC 1332
218.Re
219.Rs
220.%A B. Lloyd, W. Simpson
221.%T "PPP Authentication Protocols"
222.%O RFC 1334
223.Re
224.Rs
225.%A W. Simpson
226.%T "PPP Challenge Handshake Authentication Protocol (CHAP)"
227.%O RFC 1994
228.Re
229.Sh AUTHORS
230The original implementation of
231.Nm
232was written in 1994 at Cronyx Ltd., Moscow by
233.An Serge Vakulenko Aq vak@cronyx.ru .
234.ie t J\(:org Wunsch
235.el Joerg Wunsch
236.Aq joerg_wunsch@uriah.heep.sax.de
237rewrote a large part in 1997 in order
238to fully implement the state machine as described in RFC 1661, so it
239could also be used for dialup lines.
240He also wrote the initial version of this man page.
241Serge later on wrote a basic implementation for PAP and CHAP, which
242served as the base for the current implementation, done again by
243.ie t J\(:org Wunsch.
244.el Joerg Wunsch.
245.Pp
246.ie t Reyk Fl\(:oter
247.el Reyk Floeter
248implemented
249.Nm
250support for
251.Xr ifconfig 8
252in
253.Ox 4.0
254in order to remove the original
255.Ql spppcontrol
256utility, which was previously used to configure and display the
257.Nm
258settings.
259.Sh BUGS
260Many.
261.Pp
262Negotiation loop avoidance is not fully implemented.
263If the negotiation doesn't converge, this can cause an endless loop.
264.Pp
265The various parameters that should be adjustable per RFC 1661 are
266currently hard-coded into the kernel, and should be made accessible
267through
268.Xr ifconfig 8 .
269.Pp
270.Em Passive
271mode has not been tested extensively.
272.Pp
273More NCPs should be implemented, as well as other control protocols
274for authentication and link quality reporting.
275.Pp
276IPCP should support VJ header compression.
277.Pp
278Link-level compression protocols should be supported.
279