Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 May 1997 08:48:56 +0200
From:      j@uriah.heep.sax.de (J Wunsch)
To:        freebsd-current@FreeBSD.org (FreeBSD-current users)
Cc:        vak@cronyx.ru (Serge Vakulenko)
Subject:   Heads up for ar(4), cx(4), and sr(4) users
Message-ID:  <19970520084856.ZX56425@uriah.heep.sax.de>

next in thread | raw e-mail | index | archive | help
As recently threatened, i heavily munged with the SyncPPP layer in the
kernel.  I'm now successfully using it over an ISDN line in
dial-on-demand mode.  While it was my ultimate goal to keep it
compatible with the existing version, i needed a minor change in the
API in order to decouple the this-layer-started and this-layer-
finished actions from the corresponding Up and Down events.  They were
previously implicitly shortcut, and now need to be explicitly shortcut
in the underlying hardware drivers of ar(4), cx(4), and sr(4).  I've
added the couple of lines to each of these drivers.  (In case you
wonder, if the underlying hardware is of type `dialup', they are of
course _not_ shortcut.)

I have added a bunch of stuff, most notably the state machine now
conforms to RFC 1661.  This was a prerequisite for me to use it
against an arbitrary number of PPP-over-ISDN routers.  The older
simplified state machine was only appropriate for leased line
operation.  Most of the other added features (like dial-on-demand) are
probably neither of interest for you, and are turned off by default.
Dial-on-demand can be activated with link-level flag 1, passive mode
(not actually passive PPP as described in the RFC, but passively
waiting for `carrier') by link-level flag 0.

Phase, state, event and action names are according to RFC 1661
wherever possible, to avoid confusion.  (The state numbers are now,
too.)  So this RFC is ``recommended reading'' if you want to
understand the subtleties of the state machine.

Debugging the control protocol packets and the state transitions is
still done using the interface debug flag (see ifconfig(8)), but no
longer by kernel printf's cluttering your console, but by log(9) calls
at level LOG_DEBUG.  (Most of them, only phase transitions are logged
at LOG_INFO.)

I didn't touch the Cisco framing code at all, so i hope it continues
to work as it used to be.  It should probably also get the fixes for
the statistics counters (if_ierrors, if_oerrors, if_collisions) since
i feel they are basically applicable there as well.

I didn't integrate any of the new features from the vendor branch yet
(frame relay framing, PAP/CHAP), although i will continue to work at
this.

I encourage you to look at the code and comment on it.  In particular,
examine the spots i've marked with XXX, and see what would be most
appropriate there.

Finally, i also wrote a man page sppp(4) for it, and it mentions a
number of remaining bugs and omissions.

-- 
cheers, J"org

joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970520084856.ZX56425>