See my comments below. Marc
---------- Marc Mongeon <[EMAIL PROTECTED]> Unix Specialist Ban-Koe Systems 9100 W Bloomington Fwy Bloomington, MN 55431-2200 (612)888-0123, x417 | FAX: (612)888-3344 ---------- "It's such a fine line between clever and stupid." -- David St. Hubbins and Nigel Tufnel of "Spinal Tap" >>> "Cheshire" <[EMAIL PROTECTED]> 07/20 11:52 AM >>> [...] > Jul 20 00:51:28 cheshire pppd[300]: pppd 2.3.5 started by root, uid 0 > Jul 20 00:51:29 cheshire chat[304]: abort on (BUSY) > Jul 20 00:51:29 cheshire chat[304]: abort on (NO CARRIER) > Jul 20 00:51:29 cheshire chat[304]: abort on (VOICE) > Jul 20 00:51:29 cheshire chat[304]: abort on (NO DIALTONE) > Jul 20 00:51:29 cheshire chat[304]: abort on (NO ANSWER) > Jul 20 00:51:29 cheshire chat[304]: send (ATZ^M) > Jul 20 00:51:29 cheshire chat[304]: expect (OK) > Jul 20 00:51:38 cheshire chat[304]: > Jul 20 00:51:48 cheshire chat[304]: OK > Jul 20 00:51:48 cheshire chat[304]: -- got it > Jul 20 00:51:48 cheshire chat[304]: send (ATDT7770591^M) > Jul 20 00:51:48 cheshire chat[304]: expect (CONNECT) > Jul 20 00:51:48 cheshire chat[304]: ^M > Jul 20 00:51:58 cheshire chat[304]: ATZ^M^M > Jul 20 00:51:58 cheshire chat[304]: OK^M Hmm... could some other process have sent an init string to the modem while pppd was waiting for CONNECT? File locking should prevent that from happening, though. I guess I'd start by checking for any getty or pppd daemons running on the same port: ps aux | grep -E "(getty|pppd)" (do that while pppd is trying to connect) > Jul 20 00:52:33 cheshire chat[304]: alarm > Jul 20 00:52:33 cheshire chat[304]: Failed > Jul 20 00:52:33 cheshire pppd[300]: Connect script failed > Jul 20 00:52:34 cheshire pppd[300]: Exit.
