Frank Preut [EMAIL PROTECTED] 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 (ATD000^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]: ATD000^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 (ATD000^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
