First off, this is a potato system, kernel 2.2.4, up to date as of 3/24. When I upgraded to the new ppp package, things went majorly boom. I cleaned up a few problems related to /etc/ppp.chatscript and the changes in pppd's connect option (probably relics of my crufty and idiosyncratic ppp setup. PPP was the first thing I set up after moving from Slack, and while my system may have been Debianized, I certainly wasn't).
But I've hit a brick wall here, my modem and pppd are no longer on speaking terms. The log sums it up pretty well... Mar 26 01:19:11 platinum pppd[429]: pppd 2.3.6 started by root, uid 0 Mar 26 01:19:12 platinum chat[431]: abort on (BUSY) Mar 26 01:19:12 platinum chat[431]: abort on (NO CARRIER) Mar 26 01:19:12 platinum chat[431]: send (^M) Mar 26 01:19:12 platinum chat[431]: send (AT&F1W2^M) Mar 26 01:19:12 platinum chat[431]: expect (OK) Mar 26 01:19:57 platinum chat[431]: alarm Mar 26 01:19:57 platinum chat[431]: Failed Mar 26 01:19:57 platinum pppd[429]: Connect script failed If I then go into minicom and hit enter, the modem will spit back "ERROR". Which makes me think chat isn't saying what it thinks its saying, but rather some garbage without a ^M in it. Running chat with -V rather than -v seems to back this up, platinum:/etc/chatscripts# chat -V -f provider.script </dev/ttyS1 >/dev/ttyS1 ^?~xx~xx^?platinum:/etc/chatscripts# but I've never used the -V flag on a functional system, so I don't know if that's normal or not. If I run chat attached to the console rather than ttyS1, I can play the part of the modem and things work fine. Likewise I can impersonate chat with minicom just fine. Only when I put the two together do things fail. Anybody know what's going on here? I haven't submitted a bug report on this, yet, usually when when something simple fails in a bizarre way, it means I've missed something fundamental. Let me know if I should.
