Subject: Re: A ppp problem solved and another problem found
To: Jon Lefman <jlefman@bu.edu>
From: Bill Studenmund <wrstuden@loki.stanford.edu>
List: port-mac68k
Date: 04/04/1997 09:13:32
> Remember how I was always disconnecting when using sup?  Well, I think I
> solved a part of the problem.  I changed the stty line in my ppp-connect
> script used in ppp-up.  It used to say "stty clocal".  I changed it to
> "stty -clocal".  It seemed to work.  Reading through the man page for stty,
> clocal says that I'm not using modem control.  That seemed to be incorrect.
> I changed it and I was able to stay connected for hours.  Is this a
> theoretically good thing?

Since you're using a modem, don't use clocal. Though why are you setting
the configuration in an stty line? Since pppd can (and will) set up the
serial line, let it.

Also, let me mention more clearly: right now, you can use stty to set
a serial port's behavior, and then come along and do something which uses
that behavior. This functionality is considered bad (as it means the serial
port isn't resetting to known defaults and can be left in a messed-up
state). It is going away in the future.

ppp works fine with the standard defaults, so there'll be no loss there
if you use ppp to set things up.

> Now the next problem, why won't ppp stop sending as soon as my modem's flow
> control light goes low?  It works just fine in MacOS, but it doesn't
> respond in NetBSD.  Not sure why....any hints?  I'm assuming it's an stty
> setting that I'm not using.  I am currently using stty -clocal crtscts
> -echo.

Do you have crtscts in your options file for ppp? If crtscts is in
force when ppp is running, the serial drivers will respect the flow
control lines. But ppp modifies the serial port settings as it goes
along, so just because you have it in the stty before you start doesn't
mean it's being used.

> I noticed a problem or two in the ppp scripts in /private/wrstuden on
> ftp.macbsd.com.  First, the README file has a .tgz filename.  It's a
> regular text file.  Just pointing it out.

I'll fix that as soon as sprintlink,net gets happy (I can't log onto
puma at the moment).

> Another possible problem is that the options file doesn't appear to be used
> unless pppd uses a file called options.  If it does look for that file,
> please disregard the rest of this.  If it doesn't, the options file never
> gets read in.  The script file ppp-up says something like: pppd 19200
> connect "insert script names here".  If an extra options file is going to
> be used, pppd needs to have something like this: pppd 19200 file
> options_file_name connect "insert script names here".  I couldn't find
> anywhere else where the options file was used.  This could possibly be
> misleading if trying to configure pppd.

>From man pppd:

OPTIONS FILES
       Options can be taken from files as  well  as  the  command
       line.   pppd reads options from the files /etc/ppp/options
       and ~/.ppprc before  looking  at  the  command  line.

Take care,

Bill