Skip site navigation (1)Skip section navigation (2)

FreeBSD Man Pages

Man Page or Keyword Search:
Man Architecture
Apropos Keyword Search (all sections) Output format
home | help
SPPP(4)		       FreeBSD Kernel Interfaces Manual		       SPPP(4)

NAME
     sppp -- point to point protocol network layer for synchronous lines

SYNOPSIS
     device sppp

DESCRIPTION
     The sppp network layer implements the state machine and the Link Control
     Protocol (LCP) of the point to point protocol (PPP) as described in RFC
     1661.  Note that this layer does not provide network interfaces of	its
     own, it is	rather intended	to be layered on top of	drivers	providing a
     synchronous point-to-point	connection that	wish to	run a PPP stack	over
     it.  The corresponding network interfaces have to be provided by these
     hardware drivers.

     The sppp layer provides three basic modes of operation.  The default
     mode, with	no special flags to be set, is to create the PPP connection
     (administrative Open event	to the LCP layer) as soon as the interface is
     taken up with the ifconfig(8) command.  Taking the	interface down again
     will terminate the	LCP layer and thus all other layers on top.  The link
     will also terminate itself	as soon	as no Network Control Protocol (NCP)
     is	open anymore, indicating that the lower	layers are no longer needed.

     Setting the link-level flag link0 with ifconfig(8)	will cause the respec-
     tive network interface to go into passive mode.  This means, the adminis-
     trative Open event	to the LCP layer will be delayed until after the lower
     layers signals an Up event	(rise of ``carrier'').	This can be used by
     lower layers to support a dialin connection where the physical layer is
     not available immediately at startup, but only after some external	event
     arrives.  Receipt of a Down event from the	lower layer will not take the
     interface completely down in this case.

     Finally, setting the flag link1 will cause	the interface to operate in
     dial-on-demand mode.  This	is also	only useful if the lower layer sup-
     ports the notion of a carrier.  Upon configuring the respective inter-
     face, it will delay the administrative Open event to the LCP layer	until
     either an outbound	network	packet arrives,	or until the lower layer sig-
     nals an Up	event, indicating an inbound connection.  As with passive
     mode, receipt of a	Down event (loss of carrier) will not automatically
     take the interface	down, thus it remains available	for further connec-
     tions.

     The sppp layer supports the debug interface flag that can be set with
     ifconfig(8).  If this flag	is set,	the various control protocol packets
     being exchanged as	well as	the option negotiation between both ends of
     the link will be logged at	level LOG_DEBUG.  This can be helpful to exam-
     ine configuration problems	during the first attempts to set up a new con-
     figuration.  Without this flag being set, only the	major phase transi-
     tions will	be logged at level LOG_INFO.

     It	is possible to leave the local interface IP address open for negotia-
     tion by setting it	to 0.0.0.0.  This requires that	the remote peer	can
     correctly supply a	value for it based on the identity of the caller, or
     on	the remote address supplied by this side.  Due to the way the IPCP
     option negotiation	works, this address is being supplied late during the
     negotiation, which	might cause the	remote peer to make wrong assumptions.

     In	a similar spirit the remote address can	be set to the magical value
     0.0.0.* which means that we do not	care what address the remote side will
     use, as long as it	is not 0.0.0.0.	 This is useful	if your	ISP has	sev-
     eral dial-in servers.  You	can of course route add	something_or_other
     0.0.0.* and it will do exactly what you would want	it to.

     The PAP and CHAP authentication protocols as described in RFC 1334, and
     RFC 1994 resp., are also implemented.  Their parameters are being con-
     trolled by	the spppcontrol(8) utility.

     VJ	header compression is implemented, and enabled by default.  It can be
     disabled using spppcontrol(8).

DIAGNOSTICS
     <ifname><ifnum>: <proto> illegal <event> in state <statename>  An event
     happened that should not happen for the current state the respective con-
     trol protocol is in.  See RFC 1661	for a description of the state automa-
     ton.

     <ifname><ifnum>: loopback	The state automaton detected a line loopback
     (that is, it was talking with itself).  The interface will	be temporarily
     disabled.

     <ifname><ifnum>: up  The LCP layer	is running again, after	a line loop-
     back had previously been detected.

     <ifname><ifnum>: down  The	keepalive facility detected the	line being
     unresponsive.  Keepalive must be explicitly requested by the lower	layers
     in	order to take place.

SEE ALSO
     inet(4), intro(4),	ppp(4),	ifconfig(8), spppcontrol(8)

     W.	Simpson, Editor, The Point-to-Point Protocol (PPP), RFC	1661.

     G.	McGregor, The PPP Internet Protocol Control Protocol (IPCP), RFC 1332.

     B.	Lloyd and W. Simpson, PPP Authentication Protocols, RFC	1334.

     W.	Simpson, PPP Challenge Handshake Authentication	Protocol (CHAP), RFC
     1994.

AUTHORS
     The original implementation of sppp was written in	1994 at	Cronyx Ltd.,
     Moscow by Serge Vakulenko <vak@cronyx.ru>.	 Jorg Wunsch
     <joerg_wunsch@uriah.heep.sax.de> rewrote a	large part in 1997 in order to
     fully implement the state machine as described in RFC 1661, so it could
     also be used for dialup lines.  He	also wrote this	man page.  Serge later
     on	wrote a	basic implementation for PAP and CHAP, which served as the
     base for the current implementation, done again by	Jorg Wunsch.

BUGS
     Many.

     Currently,	only the IPCP control protocol and ip(4) network protocol is
     supported.	 More NCPs should be implemented, as well as other control
     protocols for authentication and link quality reporting.

     Negotiation loop avoidance	is not fully implemented.  If the negotiation
     does not converge,	this can cause an endless loop.

     The various parameters that should	be adjustable per RFC 1661 are cur-
     rently hard-coded into the	kernel,	and should be made accessible through
     spppcontrol(8).

     Passive mode has not been tested extensively.

     Link-level	compression protocols should be	supported.

FreeBSD	10.1			 May 25, 2008			  FreeBSD 10.1

NAME | SYNOPSIS | DESCRIPTION | DIAGNOSTICS | SEE ALSO | AUTHORS | BUGS

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=sppp&sektion=4&manpath=FreeBSD+10.0-RELEASE>

home | help