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/08/1997 19:35:53
> >While ppp is running, try "stty -e -f /dev/tty00" and see what the
> >settings are while ppp is up.
> >
> >The serial drivers will certainly respect CTS going low if crtscts is
> >asserted. They will immediately stop sending (any character in
> >transmission will of course be finished).
> >
> >One other question. Are you using the modem initialization string you
> >use inder MacOS? The modem string in the non-demand-dial kit is just
> >the one MacSlIP was using on my modem. Your modem might need different.
> 
> I'm using the same initialization string for MacPPP and ppp-up on BSD.
> It's at&f1&c1&d2&k3
> 
> &f1:  Set factory settings 1, just basic stuff is set.
> &c1:  Set's carrier detect low when disconnected, up when connected
> &d2:  When dtr drops, the connection drops.  I've tried &d0, but that
> doesn't affect when I send through ftp and pppd still continues to send
> after FC has gone low.
> &k3:  Use hardware flow control

All that looks good.

> Here's what happens when I do "stty -e -f /dev/tty00" when pppd is not
> connected:
> speed 9600 baud; 0 rows; 0 columns;
> lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
>         -echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
>         -extproc
> iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk
>         brkint -inpck -ignpar -parmrk
> oflags: opost onlcr oxtabs
> cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -mdmbuf
> discard dsusp   eof     eol     eol2    erase   intr    kill    lnext
> ^O      ^Y      ^D      <undef> <undef> ^?      ^C      ^U      ^V
> min     quit    reprint start   status  stop    susp    time    werase
> 1       ^\      ^R      ^Q      <undef> ^S      ^Z      0       ^W
> 
> Here's the same thing when pppd is connected:
> ppp disc; speed 38400 baud; 0 rows; 0 columns;
> lflags: -icanon -isig -iexten -echo -echoe -echok -echoke -echonl
>         -echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin
>         -nokerninfo -extproc
> iflags: -istrip -icrnl -inlcr -igncr -ixon -ixoff -ixany -imaxbel ignbrk
>         -brkint -inpck ignpar -parmrk
> oflags: -opost -onlcr -oxtabs
> cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb crtscts -mdmbuf
> discard dsusp   eof     eol     eol2    erase   intr    kill    lnext
> ^O      ^Y      ^D      <undef> <undef> ^?      ^C      ^U      ^V
> min     quit    reprint start   status  stop    susp    time    werase
> 1       ^\      ^R      ^Q      <undef> ^S      ^Z      0       ^W
> 
> 
> Can you make anything of this?

It looks fine.

I really don't know what's wrong. The driver will IMMEDIATELY stop if
crtscts gets dropped, and won't restart until it's reasserted.

The only thing which comes to mind is to get a serial break out box
and see what's going on. Watch both the Tx pin, and the CTS pin.
The Tx pin should stop as soon as the CTS pin is de-asserted.

Don't forget that CTS is asserted when it's a "0", and that "0" in
RS-232 is v > +3 V. :-)

Take care,

Bill