l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2012 Jun 07 00:36

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Weird ppp dialup problem -- switch to DSL?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Weird ppp dialup problem -- switch to DSL?

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

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:
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!

vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.