History log of /freebsd-9.3-release/usr.sbin/ppp/exec.h
Revision Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
# 267654 19-Jun-2014 gjb

Copy stable/9 to releng/9.3 as part of the 9.3-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

# 225736 22-Sep-2011 kensmith

Copy head to stable/9 as part of 9.0-RELEASE release cycle.

Approved by: re (implicit)


# 196514 24-Aug-2009 brian

When ``ppp -direct'' is invoked by a program that uses pipe(2) to
create stdin and stdout, don't blindly try to use stdin as a bi-directional
channel. Instead, detect the pipe and set up a special exec handler
that indirects write() calls through stdout.

This fixes the problem where ``set device "!ssh -e none host ppp
-direct label"'' no longer works with an openssh-5.2 server side as
that version of openssh ignores the USE_PIPES config setting and
*always* uses pipes (rather than socketpair) for stdin/stdout channels.

MFC after: 3 days


# 52942 06-Nov-1999 brian

Support PPPoE

Help (lots) from: julian, archie
Facilities from: ahebert@pubnix.net


# 50479 27-Aug-1999 peter

$Id$ -> $FreeBSD$


# 47769 05-Jun-1999 brian

Correct the way ppp transfers links on the server side in MP
mode by padding out the ``struct device'' to the maximum
device size.
Bump the ppp version number to indicate the transfer format
change.

This should make MP over tty and udp devices functional again.


# 47061 12-May-1999 brian

Allow ``host:port/udp'' devices and support ``host:port/tcp'' as
being the same as the previous (still supported) ``host:port''
syntax for tcp socket devices.

A udp device uses synchronous ppp rather than async, and avoids
the double-retransmit overhead that comes with ppp over tcp (it's
usually a bad idea to transport IP over a reliable transport that
itself is using an unreliable transport). PPP over UDP provides
througput of ** 1.5Mb per second ** with all compression disabled,
maxing out a PPro/200 when running ppp twice, back-to-back.

This proves that PPPoE is plausable in userland....

This change adds a few more handler functions to struct device and
allows derivations of struct device (which may contain their own
data etc) to pass themselves through the unix domain socket for MP.
** At last **, struct physical has lost all the tty crud !

iov2physical() is now smart enough to restore the correct stack of
layers so that MP servers will work again.

The version number has bumped as our MP link transfer contents have
changed (they now may contain a `struct device').

Don't extract the protocol twice in MP mode (resulting in protocol
rejects for every MP packet). This was broken with my original
layering changes.

Add ``Physical'' and ``Sync'' log levels for logging the relevent
raw packets and add protocol-tracking LogDEBUG stuff in various
LayerPush & LayerPull functions.

Assign our physical device name for incoming tcp connections by
calling getpeername().

Assign our physical device name for incoming udp connections from
the address retrieved by the first recvfrom().


# 46686 08-May-1999 brian

o Redesign the layering mechanism and make the aliasing code part of
the layering.

We now ``stack'' layers as soon as we open the device (when we figure
out what we're dealing with). A static set of `dispatch' routines are
also declared for dealing with incoming packets after they've been
`pulled' up through the stacked layers.

Physical devices are now assigned handlers based on the device type
when they're opened. For the moment there are three device types;
ttys, execs and tcps.

o Increment version number to 2.2
o Make an entry in [uw]tmp for non-tty -direct invocations (after
pap/chap authentication).
o Make throughput counters quad_t's
o Account for the absolute number of mbuf malloc()s and free()s in
``show mem''.
o ``show modem'' becomes ``show physical''.