modem refuses to talk to chat
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.
Reply to: