1.\"
2.\" Copyright (c) 1997 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.\"
| 1.\"
2.\" Copyright (c) 1997 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.\" $Id: sppp.4,v 1.3 1997/10/11 11:27:25 joerg Exp $
| 26.\" $Id: sppp.4,v 1.4 1998/02/28 21:00:55 phk Exp $
|
27.\"
28.Dd May 19, 1997
29.Dt SPPP 4
30.Os
31.Sh NAME
32.Nm sppp
33.Nd point to point protocol network layer for synchronuous lines
34.Sh SYNOPSIS
35.Cd "pseudo-device sppp" Op Ar count
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 synchronuous 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 (like with an ISDN line). 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 0.0.0.1 which means that we don't care what address the remote
124side will use, as long as it is not 0.0.0.0.
125This is useful if your ISP has several dial-in
126servers. You can of course
127.Ic route add something or other 0.0.0.1
128and it will do exactly what you would want it to.
129.Pp
130The PAP and CHAP authentication protocols as described in RFC 1334,
131and RFC 1994 resp., are also implemented. Their parameters are being
132controlled by the
133.Xr spppcontrol 8
134utility.
135.Sh DIAGNOSTICS
136.Bl -diag
137.It <ifname><ifnum>: <proto> illegal <event> in state <statename>
138An event happened that should not happen for the current state
139the respective control protocol is in. See RFC 1661 for a description
140of the state automaton.
141.It <ifname><ifnum>: loopback
142The state automaton detected a line loopback (that is, it was talking
143with itself). The interface will be temporarily disabled.
144.It <ifname><ifnum>: up
145The LCP layer is running again, after a line loopback had previously
146been detected.
147.It <ifname><ifnum>: down
148The keepalive facility detected the line being unresponsive.
149Keepalive must be explicitly requested by the lower layers in order to
150take place.
151.El
152.Sh SEE ALSO
153.Xr inet 4 ,
154.Xr intro 4 ,
155.Xr ppp 4 ,
156.Xr ifconfig 8 ,
157.Xr spppcontrol 8
158.Rs
159.%A W. Simpson, Editor
160.%T "The Point-to-Point Protocol (PPP)"
161.%O RFC 1661
162.Re
163.Rs
164.%A G. McGregor
165.%T "The PPP Internet Protocol Control Protocol (IPCP)"
166.%O RFC 1332
167.Re
168.Rs
169.%A B. Lloyd, W. Simpson
170.%T "PPP Authentication Protocols"
171.%O RFC 1334
172.Re
173.Rs
174.%A W. Simpson
175.%T "PPP Challenge Handshake Authentication Protocol (CHAP)"
176.%O RFC 1994
177.Re
178.Sh AUTHORS
179The original implementation of
180.Nm
| 27.\"
28.Dd May 19, 1997
29.Dt SPPP 4
30.Os
31.Sh NAME
32.Nm sppp
33.Nd point to point protocol network layer for synchronuous lines
34.Sh SYNOPSIS
35.Cd "pseudo-device sppp" Op Ar count
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 synchronuous 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 (like with an ISDN line). 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 0.0.0.1 which means that we don't care what address the remote
124side will use, as long as it is not 0.0.0.0.
125This is useful if your ISP has several dial-in
126servers. You can of course
127.Ic route add something or other 0.0.0.1
128and it will do exactly what you would want it to.
129.Pp
130The PAP and CHAP authentication protocols as described in RFC 1334,
131and RFC 1994 resp., are also implemented. Their parameters are being
132controlled by the
133.Xr spppcontrol 8
134utility.
135.Sh DIAGNOSTICS
136.Bl -diag
137.It <ifname><ifnum>: <proto> illegal <event> in state <statename>
138An event happened that should not happen for the current state
139the respective control protocol is in. See RFC 1661 for a description
140of the state automaton.
141.It <ifname><ifnum>: loopback
142The state automaton detected a line loopback (that is, it was talking
143with itself). The interface will be temporarily disabled.
144.It <ifname><ifnum>: up
145The LCP layer is running again, after a line loopback had previously
146been detected.
147.It <ifname><ifnum>: down
148The keepalive facility detected the line being unresponsive.
149Keepalive must be explicitly requested by the lower layers in order to
150take place.
151.El
152.Sh SEE ALSO
153.Xr inet 4 ,
154.Xr intro 4 ,
155.Xr ppp 4 ,
156.Xr ifconfig 8 ,
157.Xr spppcontrol 8
158.Rs
159.%A W. Simpson, Editor
160.%T "The Point-to-Point Protocol (PPP)"
161.%O RFC 1661
162.Re
163.Rs
164.%A G. McGregor
165.%T "The PPP Internet Protocol Control Protocol (IPCP)"
166.%O RFC 1332
167.Re
168.Rs
169.%A B. Lloyd, W. Simpson
170.%T "PPP Authentication Protocols"
171.%O RFC 1334
172.Re
173.Rs
174.%A W. Simpson
175.%T "PPP Challenge Handshake Authentication Protocol (CHAP)"
176.%O RFC 1994
177.Re
178.Sh AUTHORS
179The original implementation of
180.Nm
|
181was written in 1994 at Cronyx Ltd., Moscow by Serge Vakulenko, now
182<vak@cronyx.ru>.
| 181was written in 1994 at Cronyx Ltd., Moscow by
182.An Serge Vakulenko Aq vak@cronyx.ru .
|
183.ie t J\(:org Wunsch
184.el Joerg Wunsch
| 183.ie t J\(:org Wunsch
184.el Joerg Wunsch
|
185<joerg_wunsch@uriah.heep.sax.de> rewrote a large part in 1997 in order
| 185.Aq joerg_wunsch@uriah.heep.sax.de
186rewrote a large part in 1997 in order
|
186to fully implement the state machine as described in RFC 1661, so it
187could also be used for dialup lines. He also wrote this man page.
188Serge later on wrote a basic implementation for PAP and CHAP, which
189served as the base for the current implementation, done again by
190.ie t J\(:org Wunsch.
191.el Joerg Wunsch.
192.Sh BUGS
193Many.
194.Pp
195Currently, only the
196.Em IPCP
197control protocol and
198.Xr ip 4
199network protocol is supported.
200.Pp
201Negotiation loop avoidance is not fully implemented. If the negotiation
202doesn't converge, this can cause an endless loop.
203.Pp
204The various parameters that should be adjustable per RFC 1661 are
205currently hard-coded into the kernel, and should be made accessible
206through
207.Xr spppcontrol 8 .
208.Pp
209.Em Passive
210mode has not been tested extensively.
211.Pp
212More NCPs should be implemented, as well as other control protocols
213for authentication and link quality reporting.
214.Pp
215IPCP should support VJ header compression.
216.Pp
217Link-level compression protocols should be supported.
| 187to fully implement the state machine as described in RFC 1661, so it
188could also be used for dialup lines. He also wrote this man page.
189Serge later on wrote a basic implementation for PAP and CHAP, which
190served as the base for the current implementation, done again by
191.ie t J\(:org Wunsch.
192.el Joerg Wunsch.
193.Sh BUGS
194Many.
195.Pp
196Currently, only the
197.Em IPCP
198control protocol and
199.Xr ip 4
200network protocol is supported.
201.Pp
202Negotiation loop avoidance is not fully implemented. If the negotiation
203doesn't converge, this can cause an endless loop.
204.Pp
205The various parameters that should be adjustable per RFC 1661 are
206currently hard-coded into the kernel, and should be made accessible
207through
208.Xr spppcontrol 8 .
209.Pp
210.Em Passive
211mode has not been tested extensively.
212.Pp
213More NCPs should be implemented, as well as other control protocols
214for authentication and link quality reporting.
215.Pp
216IPCP should support VJ header compression.
217.Pp
218Link-level compression protocols should be supported.
|