Margo Schulter wrote:
> ... ppp dialup problem
> .. failures to connect with a timeout started
> gradually happening and getting more common early
> this year, but really serious by early May,
> when I might sometimes try ten or more times
> without success with a 56K external modem,
> Slackware 10.0, and ppp files which had given
> no previous problems.
Correlation is not causation, but temperatures are getting warmer this
time of year. Chips and hardware near fault can fail sooner when warmer.
If this is a really old model, and you feel comfortable opening the modem
container (if external) or taking it out of your computer (assuming
internal) to press any chips into sockets that is something to quickly
try.
Chips rising due to heating and cooling of equipment was a problem a long
time a go with years of use, but most hardware now has eliminated chips in
sockets and moved to full integration. It is worth investigating, anyway.
> I tried calling 611, and they checked the telephone
> line, confirming that it seemed fine (this was
> at a time I had just made some unsuccessful
> connection attempts).
Try another modem, even slower, if you have one, to help confirm it is not
likely the media.
> Then, starting May 23, I was unable to make a
> connection -- and looked into /var/log/messages.
> One thing I noted was that sometimes the message
> at the end of an unsuccessful ppp attempt was
>
> chat[1078]: alarm
> chat[1078]: Failed
> pppd[1076]: Exit
>
> but sometimes
>
> chat[1056]: alarm
> chat[1056]: warning: alarm synchronization problem
> chat[1056]: Failed
> pppd[1054]: Exit
As you probably know, "chat" is a program used to automate connections
using conditionals, waiting for certain outputs before transmitting
responses. It includes options to program timeout values, and if exceeded,
send alarm. Knowing exactly which timeout is exceeded, and which alarm is
being triggered could help you to identify which part is failing.
A common failure with chat scripts a long time ago was the first character
of output was not reliably acquired. As a result, many chat expectation
scripts include a wildcard for the first character and full text for the
remaining characters.
So, what if due you accidental reconfiguration, or other software
reconfiguring it, or some other cause, somehow one ore more AT commands
was passed to your modem, for example, to switch output responses from
"OK" to "integer" ? When this happens, often a single digit (commonly 1 or
0) are displayed, and if your chat scripts are not designed to recognize
them as the desired output before transmitting the next bit of data in
reply, a timeout will be reached, and an alarm signaled.
This can also cause problem if the older "first char is not always read"
problems was not 100% solved in the decade+ time since chat has been
available. (When output is only one char, you can see how this could be a
problem if not addressed.)
To help eliminate this, visit your modems AT command set, and find the
option to "reset all settings to factory config" and then issue the next
AT command to "save current settings to be default" [on power-up or
non-factory reset.]
Then issue some simple command in minicom or other terminal program like:
ATH
and see if you get "OK" or an integer response.
> After a week of things like turning the modem
> off and on, or rebooting the system, I tried
> a hard reset -- maybe what made the difference,
> since I then could get online maybe every other
> attempt from either DOS 6.22 ("Try everything") or
> my accustomed Linux.
The problem following the modem suggests the modem settings are bad, or
the modem is bad/going bad.
> I'm still getting timeouts at least 50% of the
> time, which makes me wonder about what could
> be going on -- the "warning: alarm synchronization
> problem" happens on some ppp timeouts, but others
> are just the "alarm - Failed - Exit" type.
IIRC, "chat" support a "verbose" mode which logs every step to show you
where it is failing. It may be logged to /var/log/messages, or another
place, or dumped to a window during connection. That would be good to
investigate. The chat scripts are often installed in an "/etc" or "/var"
dir with chat as part of the name of the directory.
# find /etc -iname \*chat\* -type d -print
# find /var -iname \*chat\* -type d -print
find the chat "scripts" and edit them to specify the verbose option,
however that is done, now-a-days.
> I've been advised that the modem and the telephone
> line are usual suspects -- although I haven't
> generally noticed lots of line noise on voice
> calls.
>
> A larger question is whether I might want to
> delve deeper into debugging this, or maybe
> shift to DSL.
>
> But I'm curious what might be happening,
> and thank anyone who might have experience
> or educated guesses on this.
Like other people here, it has been a long time since I've used modems.
Good luck!
-ME
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
