[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: poff doesn't exit connection properly (was: Problems with apt-get and pppd)



Frank Preut <debian@blinx.de> writes:

> > 1) i use pon/poff for my dialup connection.. the problem with this is
> > that poff somehow doesn't seem to completely close the connection or
> > something because when i try to re-connect with pon nothing happens..
> > that's also the reason why dial on demand isn't feasible.. i have to
> > repeat poff twice to be able connect again.. i have checked syslog but
> > the last message is pppd: exit..
> > 
> 
> okay to elaborate further on this: again i work on potato and haven't
> fiddled with the ppp stuff other than setting up the connection with
> pppconfig.. since the problem *might* be related to some modem issues: i
> have an elsa microlink 56k.. i don't see this problem when i use, for
> instance, wvdial, but i don't want to use wvdial and i would like to use
> dial on demand..
> 
> any pointers to a possible solutions appreciated,

Hey, I experience exactly the same problem!  What modem do you have?
My is an "ELSA MicroLink 56k".

This behavior didn't appear with my old Creatix SG2843 28.8k modem.  A
week ago I changed my mainboard (overclocking apparently _does_
shorten the lifespan, but it was old nevertheless...) and my modem to
a 56k one and now that little nuisance irks me too.

I'm not sure whether it's the modem's or the mainboard's fault, but I
don't think that the board has anything to do with it.

I have a suspicion that the reason might be poff not waiting for the
final "OK" after hangup.  Let's have a look at two snippets from my
syslog:

The beginning of a successful pon run:
Jan 26 12:55:58 mother pppd[613]: pppd 2.3.11 started by cwg, uid 1000
Jan 26 12:55:59 mother chat[615]: abort on (BUSY)
Jan 26 12:55:59 mother chat[615]: abort on (NO CARRIER)
Jan 26 12:55:59 mother chat[615]: abort on (VOICE)
Jan 26 12:55:59 mother chat[615]: abort on (NO DIALTONE)
Jan 26 12:55:59 mother chat[615]: abort on (NO DIAL TONE)
Jan 26 12:55:59 mother chat[615]: abort on (NO ANSWER)
Jan 26 12:55:59 mother chat[615]: send (ATZ^M)
Jan 26 12:55:59 mother chat[615]: expect (OK)
Jan 26 12:55:59 mother chat[615]: ATZ^M^M
Jan 26 12:55:59 mother chat[615]: OK
Jan 26 12:55:59 mother chat[615]:  -- got it 
Jan 26 12:55:59 mother chat[615]: send (ATD00000000000^M)
Jan 26 12:56:00 mother chat[615]: expect (CONNECT)
Jan 26 12:56:00 mother chat[615]: ^M
Jan 26 12:56:30 mother chat[615]: ATD00000000000^M^M
Jan 26 12:56:30 mother chat[615]: CONNECT
Jan 26 12:56:30 mother chat[615]:  -- got it 
Jan 26 12:56:30 mother chat[615]: send (\d)
Jan 26 12:56:31 mother pppd[613]: Serial connection established.

The beginning of a failed pon run:
Jan 24 11:14:37 mother pppd[393]: pppd 2.3.11 started by cwg, uid 1000
Jan 24 11:14:38 mother chat[394]: abort on (BUSY)
Jan 24 11:14:38 mother chat[394]: abort on (NO CARRIER)
Jan 24 11:14:38 mother chat[394]: abort on (VOICE)
Jan 24 11:14:38 mother chat[394]: abort on (NO DIALTONE)
Jan 24 11:14:38 mother chat[394]: abort on (NO DIAL TONE)
Jan 24 11:14:38 mother chat[394]: abort on (NO ANSWER)
Jan 24 11:14:38 mother chat[394]: send (ATZ^M)
Jan 24 11:14:38 mother chat[394]: expect (OK)
Jan 24 11:14:38 mother chat[394]: ^M
Jan 24 11:14:38 mother chat[394]: OK
Jan 24 11:14:38 mother chat[394]:  -- got it 
Jan 24 11:14:38 mother chat[394]: send (ATD00000000000^M)
Jan 24 11:14:38 mother chat[394]: expect (CONNECT)
Jan 24 11:14:38 mother chat[394]: ^M
Jan 24 11:14:38 mother chat[394]: ATZ^M^M
Jan 24 11:14:38 mother chat[394]: OK^M
Jan 24 11:14:50 mother pppd[393]: Terminating on signal 15.
Jan 24 11:14:50 mother pppd[393]: Connect script failed

It seems that poff doesn't read the final "OK" from the modem.  When
pon says "ATZ", it gets that old "OK" from the modem and the second
"OK" (from ATZ this time) is interpreted as the answer to the "ATD..."
command.  As chat expects "CONNECT" and gets "OK" the script fails.

IIRC my old modem said "NO CARRIER" on hangup, but I'm not sure.
Maybe the poff only waits for this and ignores "OK".

A solution could be to change the chatscript in some way so that it
eats up an "OK" before beginning its conversation with the modem.  A
short glimpse at the chat manpage didn't reveal to me how to do it.
And as this problem is not cruical I currently don't have more time to
spend on it.  If you or someone else on the list knows a solution,
please do let me know.

Christoph



Reply to: