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 de - scribed in RFC
1661. Note that this layer does not provide network inter - faces 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 provid - ed 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 respective network interface to go into passive mode. This means,
- the administrative 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 physi - cal 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 supports the notion of a carrier (like with an ISDN line). Up
- on configuring
the respective interface, it will delay the administrative - Open event to
the LCP layer until either an outbound network packet ar - rives, or until
the lower layer signals an Up event, indicating an inbound - connection.
As with passive mode, receipt of a Down event (loss of car - rier) will not
automatically take the interface down, thus it remains - available for further connections.
- The sppp layer supports the debug interface flag that can be
- set with
ifconfig(8). If this flag is set, the various control pro - tocol 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 examine configuration problems during the first attempts to set
- up a new configuration. Without this flag being set, only the major
- phase transitions will be logged at level LOG_INFO.
- It is possible to leave the local interface IP address open
- for negotiation by setting it to 0.0.0.0. This requires that the re
- mote 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 re - mote side will
use, as long as it is not 0.0.0.0. This is useful if your - ISP has several 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 controlled by the spppcontrol(8) utility.
- VJ header compression is implemented, and enabled by de
- fault. 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 control protocol is in. See RFC 1661 for a description of the
- state automaton.
- <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 loopback 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 Wun - sch.
BUGS
Many.
- Currently, only the IPCP control protocol and ip(4) network
- protocol is
supported. More NCPs should be implemented, as well as oth - er 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 currently hard-coded into the kernel, and should be made acces
- sible through
spppcontrol(8). - Passive mode has not been tested extensively.
- Link-level compression protocols should be supported.
- BSD December 30, 2001