[Cc:'d to tech-net because I think it's worth discussion].

"Perry E. Metzger" wrote:
> 
> Andrew Doran <ad@fionn.sports.gov.uk> writes:
> > "Perry E. Metzger" wrote:
> > > Andy Doran <ad@fionn.sports.gov.uk> writes:
> > > >       Porting & testing FreeBSD/OpenBSD userland ppp(8) (nearly done)
> > >
> > > Why the hell would we want that?
> >
> > Because it's far better than in-kernel ppp, both performance and
> > feature wise.
> 
> 1) I can't believe the performance bit at all. Userland PPP *cannot
> possibly* keep up with doing ppp at many megabits per second. Yes, we

You misunderstand. I'm not talking about many megabits per sec, I'm
talking
about small devices, although point taken.

> have drivers and software for T1 cards now.
> 2) If we are lacking features, we should work on those. PPP belongs in
> the kernel, though, just like the ethernet drivers and everything
> else...

From the ppp(8) manpage below. Yes, probably not a good idea for leased
line 
operation, but for operation over analogue/PSTN devices, ppp(8) is great
(I 
regularly see 5-30, sometimes 90k *bytes*/sec over 33.6 modem w/ppp(8)).
Can 
we not provide both, and let users decide? ppp(8) has a different
feature-domain 
than pppd(8).

Andy.

http://www.freebsd.org/cgi/man.cgi?query=ppp&apropos=0&sektion=0&manpath=FreeBSD+4.0-current&format=html

     Provides an interactive user interface.  Using its command mode,
the user
     can easily enter commands to establish the connection with the
remote
     end, check the status of connection and close the connection.  All
func­
     tions can also be optionally password protected for security.

     Supports both manual and automatic dialing.  Interactive mode has a
     ``term'' command which enables you to talk to your modem directly. 
When
     your modem is connected to the remote peer and it starts to talk
PPP, ppp
     detects it and switches to packet mode automatically.  Once you
have de­
     termined the proper sequence for connecting with the remote host,
you can
     write a chat script to define the necessary dialing and login
procedure
     for later convenience.

     Supports on-demand dialup capability.  By using -auto mode, ppp
will act
     as a daemon and wait for a packet to be sent over the PPP link. 
When
     this happens, the daemon automatically dials and establishes the
connec­
     tion.  In almost the same manner -ddial mode (direct-dial mode)
also au­
     tomatically dials and establishes the connection.  However, it
differs in
     that it will dial the remote site any time it detects the link is
down,
     even if there are no packets to be sent.  This mode is useful for
full-
     time connections where we worry less about line charges and more
about
     being connected full time.  A third -dedicated mode is also
available.
     This mode is targeted at a dedicated link between two machines. 
ppp will
     never voluntarily quit from dedicated mode - you must send it the
``quit
     all'' command via its diagnostic socket.  A SIGHUP will force an
LCP
     renegotiation, and a SIGTERM will force it to exit.

     Supports client callback.  ppp can use either the standard LCP
callback
     protocol or the Microsoft CallBack Control Protocol (ftp://ftp.mi­
     crosoft.com/developr/rfc/cbcp.txt).

     Supports packet aliasing.  Packet aliasing (a.k.a. IP masquerading)
al­
     lows computers on a private, unregistered network to access the
Internet.
     The PPP host acts as a masquerading gateway.  IP addresses as well
as TCP
     and UDP port numbers are aliased for outgoing packets and
de-aliased for
     returning packets.

     Supports background PPP connections.  In background mode, if ppp
success­
     fully establishes the connection, it will become a daemon. 
Otherwise, it
     will exit with an error.  This allows the setup of scripts that
wish to
     execute certain commands only if the connection is successfully
estab­
     lished.

     Supports server-side PPP connections.  In direct mode, ppp acts as
server
     which accepts incoming PPP connections on stdin/stdout.

     Supports PAP and CHAP (rfc 1994) authentication.  With PAP or CHAP,
it is
     possible to skip the Unix style login(1) procedure, and use the PPP
pro­
     tocol for authentication instead.  If the peer requests Microsoft
CHAP
     authentication and ppp is compiled with DES support, an appropriate
     MD4/DES response will be made.

     Supports RADIUS (rfc 2138) authentication.  An extension to PAP and
CHAP,
     Remote Access Dial In User Service allows authentication
information to
     be stored in a central or distributed database along with various
per-us­
     er framed connection characteristics.  If libradius is available at
com­
     pile time, ppp will use it to make RADIUS requests when configured
to do
     so.

     Supports Proxy Arp.  ppp can be configured to make one or more
proxy arp
     entries on behalf of the peer.  This allows routing from the peer
to the
     LAN without configuring each machine on that LAN.

     Supports packet filtering.  User can define four kinds of filters:
the in
     filter for incoming packets, the out filter for outgoing packets,
the
     dial filter to define a dialing trigger packet and the alive filter
for
     keeping a connection alive with the trigger packet.

     Tunnel driver supports bpf.  The user can use tcpdump(1) to check
the
     packet flow over the PPP link.

     Supports PPP over TCP capability.  If a device name is specified as
     host:port, ppp will open a TCP connection for transporting data
rather
     than using a conventional serial device.

     Supports IETF draft Predictor-1 (rfc 1978) and DEFLATE (rfc 1979)
     compression.  ppp supports not only VJ-compression but also
Predictor-1
     and DEFLATE compression.  Normally, a modem has built-in
compression
     (e.g. v42.bis) and the system may receive higher data rates from it
as a
     result of such compression.  While this is generally a good thing
in most
     other situations, this higher speed data imposes a penalty on the
system
     by increasing the number of serial interrupts the system has to
process
     in talking to the modem and also increases latency.  Unlike
VJ-compres­
     sion, Predictor-1 and DEFLATE compression pre-compresses all
network
     traffic flowing through the link, thus reducing overheads to a
minimum.

     Supports Microsoft's IPCP extensions.  Name Server Addresses and
NetBIOS
     Name Server Addresses can be negotiated with clients using the
Microsoft
     PPP stack (ie. Win95, WinNT)

     Supports Multi-link PPP (rfc 1990)  It is possible to configure ppp
to
     open more than one physical connection to the peer, combining the
band­
     width of all links for better throughput.