🚀 go-pugleaf

[for last minute comments regarding pppd vs. other implementations,
 see the last paragraph of this article]

We are trying to run the PPP implementation pppd, version 1.01beta,
as distributed by Greg Christy (gmc@quotron.com).  According to
colleagues at a neighbouring site of ours, pppd works after a little
tweaking.  We have received their particular configuration files,
and tried to apply whatever seems relevant to our environment.
Still, we can't make the thing work.  Since this isn't an obvious
bug with Greg's implementation, I'm turning to the net in the hope
of receiving useful hints (but I'm sending this to Greg as well).

Building the kernel and the associated utilities (pppd and slstats)
was a straight-forward task with no problems, following the
instructions given (in Readme.streams).

Our test configuration differs somewhat from the intended target
configuration.  This is of course in order to simplify testing;
however, there might be subtle differences affecting the operation
of pppd, and if you recognize any of the specifics stated below as
being critical, I'd appreciate information about that.  Our target
configuration is almost identical to the allegedly working set-up
which our neighbouring site uses.

			test			target
Host hardware:		Sun SLC <-> SLC		Sun SPARCstation 1 <-> ELC
Host operating system:	SunOS 4.1.1		SunOS 4.1.1 or 4.1.3
Type of medium:		direct RS-232 line	dial-up modem line
Session start:		pppd started by root	interactive login from ELC
Debugging log:		enabled			disabled
IP address allocation:	separate C network	virtual LAN IP address(*)
Interface preparation:	no ifconfig		ifconfig at boot

(*) By "virtual LAN IP address" I mean that the remote leaf host has
an IP address logically belonging to our site's ethernet, and that
the local routing host advertises this by means of proxy ARP.

We have tried to approach the target configuration as much as we
consider reasonable at this stage, in one or a couple of the
aspects mentioned above at the time, however without positive
results.  The only things we haven't tried are moving to the
target hardware, using SunOS 4.1.3, and hooking up a real modem.

I even tried to use trace(1) with option -p on the pppd process in
the hope of obtaining more detailed information on what the deamon
was actually doing, but that seemed to prevent the pppd process
from performing some critical ioctl(2) properly.  Is this maybe
a bug with trace(1) or ptrace(2), or is it just a case of the
unavoidable fact that nothing can be observed without being
affected by the observation?

Typical command line when run by root:

	pppd /dev/ttya 9600 192.36.168.1:

Typical command line when run as the result of a pseudo-user login:

	mesg n ; stty -tostop ; exec pppd 192.36.168.1:

We have tried various ifconfig commands both before and after starting
pppd, but with no appearant change in overall behaviour (other than
netstat(8) being dependent on the interface being up and running).

Typical debugging log output:

Dec 18 16:11:01 pppd[1694]: Starting ppp daemon version 1.0beta patchlevel 1
Dec 18 16:11:01 pppd[1694]: warning... not a process group leader
Dec 18 16:11:01 pppd[1694]: pgrpid = 1694
Dec 18 16:11:01 pppd[1694]: popped stream module : ttcompat
Dec 18 16:11:01 pppd[1694]: popped stream module : ldterm
Dec 18 16:11:01 pppd[1694]: Using unit ppp0
Dec 18 16:11:01 pppd[1694]: hostname = Riga
Dec 18 16:11:01 pppd[1694]: connect: ppp0 /dev/ttya
Dec 18 16:11:01 pppd[1694]: fsm_sconfreq(c021): Sent id 1.
Dec 18 16:11:01 pppd[1694]: Timeout 6194:16b38 in 3 seconds.
Dec 18 16:11:01 pppd[1694]: Setting itimer for 3 seconds.
Dec 18 16:11:04 pppd[1694]: Alarm
Dec 18 16:11:04 pppd[1694]: fsm_sconfreq(c021): Sent id 2.
Dec 18 16:11:04 pppd[1694]: Timeout 6194:16b38 in 3 seconds.
Dec 18 16:11:04 pppd[1694]: Setting itimer for 3 seconds.
Dec 18 16:11:04 pppd[1694]: Setting itimer for 3 seconds.
Dec 18 16:11:07 pppd[1694]: Alarm
Dec 18 16:11:07 pppd[1694]: fsm_sconfreq(c021): Sent id 3.
Dec 18 16:11:07 pppd[1694]: Timeout 6194:16b38 in 3 seconds.
Dec 18 16:11:07 pppd[1694]: Setting itimer for 3 seconds.
Dec 18 16:11:07 pppd[1694]: Setting itimer for 3 seconds.

... [lots of repetitious logging deleted] ...

Dec 18 17:02:24 pppd[1694]: Alarm
Dec 18 17:02:24 pppd[1694]: fsm_sconfreq(c021): Sent id 254.
Dec 18 17:02:24 pppd[1694]: Timeout 6194:16b38 in 3 seconds.
Dec 18 17:02:24 pppd[1694]: Setting itimer for 3 seconds.
Dec 18 17:02:24 pppd[1694]: Setting itimer for 3 seconds.
Dec 18 17:02:26 pppd[1694]: Hangup
Dec 18 17:02:26 pppd[1694]: Untimeout 6194:16b38.
Dec 18 17:02:26 pppd[1694]: Setting itimer for 0 seconds.
Dec 18 17:02:26 pppd[1694]: str_restore: pushed module ldterm
Dec 18 17:02:26 pppd[1694]: str_restore: pushed module ttcompat
Dec 18 17:02:26 pppd[1694]: fcntl(F_SETFL, fdflags): Bad file number

The above final is caused by sending a SIGHUP to the pppd process
(however three successive SIGKILL's seem to be necessary to really
get rid of it).

The warning "not a process group leader" appears to be the
innocent result of a subtle coding bug, with no later effects,
but I haven't tried fixing it (variable "pid" uninitialized).

During all this, there seems to be no activity on the serial line, as
evident from an Interfaker(tm) breakout patch box.  I was desperate
enough to lower the speed to 50 bps in order to verify this.

At the same time, "netstat -i" does show increasing figures for the
ppp0 interface in the "Opkts" column, but in no other column.  The
slstats tool shows some figures in the (out) "pack" and "ip" columns
too, but I haven't used this tool very much since I don't know what
to look for.

The most obvious approach now seems to be to start riddling the code
with debugging messages, but I don't feel too familiar with device
drivers and streams programming myself...

We would appreciate suggestions as to what might be wrong, and what
we can do about it.  Further questions regarding our configuration
are also welcome.  Please send e-mail to Sun-staff@DoCS.UU.SE, as
we don't read these groups regularly, and/or post at your own
discretion if you consider it appropriate.  We will try to compile
a summary of relevant items sent to us via e-mail and post it to
these same groups, but that won't be until after the holidays.
We will also keep Greg Christy informed about any useful changes to
the pppd code that we might end up with.

...

I wrote the above before finding out that there actually was a
newsgroup comp.protocols.ppp and reading its FAQ.  Due to that, I
might now consider trying ppp-1.1 by brad@cayman.com instead (it's
not clear to me whether the word "superseded" in section 5.1.1.2
of the FAQ refers to the BSD code, or to the pppd implementation
as such).  However, I still think my questions above may be of
some interest (unless people have really stopped using pppd; it
doesn't look too old to me).  Strictly speaking, whether to use
pppd or ppp is to me just yet another variable being added to
those already listed above, thus doubling the amount of choices
once again.  Tell us what you think.
-- 
Anders Andersson, Dept. of Computer Systems, Uppsala University
Paper Mail: Box 325, S-751 05 UPPSALA, Sweden
Phone: +46 18 183170   EMail: andersa@DoCS.UU.SE