It blew up ppp for me. It seems the strings returned from the chat
script were garbled, resulting in ppp not knowing it was connected.
Going back to 2.1.6 cured the problem without making any changes to the
ppp binary or config files. Here is an exerpt of an NORMAL, successful
ppp connect under 2.1.6:
Nov 9 04:17:26 seahunt kernel: registered device ppp0
Nov 9 04:17:49 seahunt chat[114]: ATDT99999999^M^M
Nov 9 04:17:49 seahunt chat[114]: CONNECT -- got it
Nov 9 04:17:49 seahunt chat[114]: send (^M)
Nov 9 04:17:49 seahunt chat[114]: expect (ession)
Nov 9 04:17:49 seahunt chat[114]: 28800/ARQ/VFC/LAPM/V42BIS^M
Nov 9 04:17:51 seahunt chat[114]: ^M
Nov 9 04:17:51 seahunt chat[114]: Press <RETURN> to begin Login Session
-- got it
Nov 9 04:17:51 seahunt chat[114]: send (#####^M)
Nov 9 04:17:51 seahunt chat[114]: expect (word:)
Nov 9 04:17:51 seahunt chat[114]: shppp^M
Nov 9 04:17:51 seahunt chat[114]: Password: -- got it
Nov 9 04:17:51 seahunt chat[114]: send (########^M)
Nov 9 04:17:52 seahunt pppd[111]: Serial connection established.
Nov 9 04:17:53 seahunt pppd[111]: Using interface ppp0
Nov 9 04:17:53 seahunt pppd[111]: Connect: ppp0 <--> /dev/cua1
Nov 9 04:17:55 seahunt pppd[111]: local IP address 140.174.70.10
Nov 9 04:17:55 seahunt pppd[111]: remote IP address 140.174.70.100
...and here is one using 2.1.8:
Nov 9 04:12:18 seahunt pppd[440]: pppd 2.2.0 started by root, uid 0
Nov 9 04:12:19 seahunt chat[441]: abort on (BUSY)
Nov 9 04:12:19 seahunt chat[441]: abort on (ERROR)
Nov 9 04:12:19 seahunt chat[441]: abort on (NO CARRIER)
Nov 9 04:12:19 seahunt chat[441]: timeout set to 90 seconds
Nov 9 04:12:19 seahunt chat[441]: send (ATDT9999999^M)
Nov 9 04:12:19 seahunt chat[441]: expect (CONNECT)
Nov 9 04:12:38 seahunt chat[441]: ATDT9999999^M
Nov 9 04:12:38 seahunt chat[441]: CONNECT -- got it
Nov 9 04:12:38 seahunt chat[441]: send (^M)
Nov 9 04:12:38 seahunt chat[441]: expect (ession)
Nov 9 04:12:40 seahunt chat[441]: 28800/QVFC/LAPM/V42BIS^M
Nov 9 04:12:40 seahunt chat[441]: Prss <RETURN> to Session -- got it
Nov 9 04:12:40 seahunt chat[441]: send (######^M)
Nov 9 04:12:40 seahunt chat[441]: expect (word:)
Nov 9 04:12:40 seahunt chat[441]: shppp^M
Nov 9 04:12:40 seahunt chat[441]: Password: -- got it
Nov 9 04:12:40 seahunt chat[441]: send (######^M)
Nov 9 04:12:40 seahunt pppd[440]: Serial connection established.
Nov 9 04:12:41 seahunt pppd[440]: Using interface ppp0
Nov 9 04:12:41 seahunt pppd[440]: Connect: ppp0 <--> /dev/cua1
Nov 9 04:13:11 seahunt pppd[440]: Connection terminated.
Nov 9 04:13:12 seahunt chat[449]: abort on (BUSY)
Nov 9 04:13:12 seahunt chat[449]: abort on (ERROR)
Nov 9 04:13:12 seahunt chat[449]: abort on (NO CARRIER)
Nov 9 04:13:12 seahunt chat[449]: timeout set to 90 seconds
Nov 9 04:13:12 seahunt chat[449]: send (ATDT9999999^M)
Nov 9 04:13:13 seahunt chat[449]: expect (CONNECT)
Nov 9 04:13:18 seahunt PPPCHECK: ppp link was DOWN...
Nov 9 04:13:18 seahunt pppd[456]: pppd 2.2.0 started by root, uid 0
Nov 9 04:13:18 seahunt pppd[456]: Device cua1 is locked by pid 440
Nov 9 04:13:18 seahunt pppd[456]: Exit.
Nov 9 04:13:31 seahunt chat[449]: ATDT9999999^M
Nov 9 04:13:31 seahunt chat[449]: CONNECT -- got it
Nov 9 04:13:31 seahunt chat[449]: send (^M)
Nov 9 04:13:31 seahunt chat[449]: expect (ession)
Nov 9 04:13:31 seahunt chat[449]: 28800/IS^M
Nov 9 04:13:33 seahunt chat[449]:
Nov 9 04:14:18 seahunt PPPCHECK: ppp link was DOWN...
Nov 9 04:14:18 seahunt pppd[470]: pppd 2.2.0 started by root, uid 0
Nov 9 04:14:18 seahunt pppd[470]: Device cua1 is locked by pid 440
Nov 9 04:14:18 seahunt pppd[470]: Exit.
Nov 9 04:15:01 seahunt chat[449]: Prss <RETURN> to
Nov 9 04:15:01 seahunt pppd[440]: Exit.
Nov 9 04:15:01 seahunt chat[449]: alarm
Nov 9 04:15:01 seahunt chat[449]: Failed
Nov 9 04:15:18 seahunt PPPCHECK: ppp link was DOWN...
Nov 9 04:15:18 seahunt pppd[486]: pppd 2.2.0 started by root, uid 0
It looks to me like there are some big problems on the serial port.
Strings that normally come through under 2.1.6 are garbled under 2.1.8.
(pppcheck is a "keepalive" script I run, and it kept killing the ppp
connection because it was unable to ping the other end of the link, in
otherwords the link was not actually established... ping was returning
"no route to host" errors.
Anyway, back to 2.1.6 and all is well. 2.1.7 oopsed on my about once
every five minutes until the machine just ran out of resources and
locked up.
Michael
-- Michael Nelson nelson@seahunt.imat.com San Francisco, CA michaeln@csd.sgi.com