1.\" $OpenBSD: sppp.4,v 1.24 2014/03/17 17:07:45 deraadt 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: March 17 2014 $ 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.Sh STANDARDS 209.Rs 210.%A G. McGregor 211.%D May 1992 212.%R RFC 1332 213.%T The PPP Internet Protocol Control Protocol (IPCP) 214.Re 215.Pp 216.Rs 217.%A B. Lloyd 218.%A W. Simpson 219.%D October 1992 220.%R RFC 1334 221.%T PPP Authentication Protocols 222.Re 223.Pp 224.Rs 225.%A W. Simpson 226.%D July 1994 227.%R RFC 1661 228.%T The Point-to-Point Protocol (PPP) 229.Re 230.Pp 231.Rs 232.%A W. Simpson 233.%D August 1996 234.%R RFC 1994 235.%T PPP Challenge Handshake Authentication Protocol (CHAP) 236.Re 237.Pp 238.Rs 239.%A S. Varada 240.%A D. Haskins 241.%A E. Allen 242.%D September 2007 243.%R RFC 5072 244.%T IP Version 6 over PPP 245.Re 246.Sh AUTHORS 247.An -nosplit 248The original implementation of 249.Nm 250was written in 1994 at Cronyx Ltd., Moscow, by 251.An Serge Vakulenko Aq Mt vak@cronyx.ru . 252.An Joerg Wunsch Aq Mt joerg_wunsch@uriah.heep.sax.de 253rewrote a large part in 1997 in order 254to fully implement the state machine as described in RFC 1661, so it 255could also be used for dialup lines. 256He also wrote the initial version of this man page. 257Serge later on wrote a basic implementation for PAP and CHAP, which 258served as the base for the current implementation, done again by 259Joerg Wunsch. 260.Pp 261.An Reyk Floeter 262implemented 263.Nm 264support for 265.Xr ifconfig 8 266in 267.Ox 4.0 268in order to remove the original 269.Ql spppcontrol 270utility, which was previously used to configure and display the 271.Nm 272settings. 273.Sh BUGS 274Many. 275.Pp 276Negotiation loop avoidance is not fully implemented. 277If the negotiation doesn't converge, this can cause an endless loop. 278.Pp 279The various parameters that should be adjustable per RFC 1661 are 280currently hard-coded into the kernel, and should be made accessible 281through 282.Xr ifconfig 8 . 283.Pp 284.Em Passive 285mode has not been tested extensively. 286.Pp 287More NCPs should be implemented, as well as other control protocols 288for authentication and link quality reporting. 289.Pp 290IPCP should support VJ header compression. 291.Pp 292Link-level compression protocols should be supported. 293