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