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