Re: yet another ppp failure story...
On Thu, 21 Dec 2000, W. Crowshaw wrote:
> At 11:04 AM -0800 12/20/00, Dwight Johnson wrote:
> >On Wed, 20 Dec 2000, W. Crowshaw wrote:
> >
> >> At 5:42 PM -0800 12/19/00, Dwight Johnson wrote:
> >> >
> >> >Show us your chatscript.
> >> >
> >>
> >> My chat script looks like this:
> >> 'TIMEOUT' '30'
> >> 'ABORT' 'BUSY'
> >> 'ABORT' 'NO CARRIER'
> >> 'ABORT' 'NO ANSWER'
> >> 'ABORT' 'NO DIALTONE'
> >> 'ABORT' 'RING'
> >> 'ABORT' '% User/password invalid'
> >> '' 'ATZ'
> >> 'OK-+++\c-OK' 'AT &F1 L W2 Q0 V1 E1 &D2 &C1 S0=0 S7=150+MS=56'
> >> 'OK' 'ATDT5551000'
> >> 'CONNECT 42000' ''
> >> 'User Access Verification--User Access Verification' ''
> >> 'sername:--sername:' 'wcrowshaw'
> >> 'assword:' 'mypassword'
> >> '>' 'ppp'
> >
> >Your chat script is quite suspect. How did you come up with this weird chat
> >script? Most ISPs are authenticating with PAP (or MS CHAP) these days.
>
> This script isn't so strange. It used to work perfectly before I
> switched from a Redhat distribution to a Debian.
> >If your ISP does authenticate this way (unlikely), you will be able to
> >verify it in minicom by doing it manually. After entering 'ppp' at your
> >console in minicom, you should see the PPP stream start -- it's a profusion
> >of weird characters spewing over your screen.
>
> O.K. I tried minicom and it looks like this.
> -----minicom output begin
> AT&F1LW2Q0V1E1&D2&C1S0=0S7=150+MS=56
> OK
> ATDY T5551000
> CONNECT 44000
>
>
> User Access Verification
>
> Username: wcrowshaw
> Password:
> as14>ppp
> Entering PPP mode.
> Async interface address is unnumbered (Ethernet0)
> Your IP address is 129.49.78.118. MTU is 1500 bytes
> Header compression will match your system.
>
> ~?}#¿!}!Å} }4}"}&} }*} } }%}&"}&G}4}'}"}(}"d?~~?}#¿!}!Ç} }4}"}&} }*}
> } }%}&"}&G}4}'}"}(}"Æ}0~~?}#¿!}!É} }4}"}&} }*} }
> }%}&"}&G}4}'}"}(}"ÁÉ~~?}#¿!}!Ñ} }4}"}&} }*} }
> }%}&"}&G}4}'}"}(}"+c~~?}#¿!}!Ö} }4}"}&} }*} }
> }%}&"}&G}4}'}"}(}"b?~~?}#¿!}!Ü} }4}"}&} }*} }
> }%}&"}&G}4}'}"}(}"®M~~?}#¿!}!á} }4}"}&} }*} }
> }%}&"}&G}4}'}"}(}"·Þ~~?}#¿!}!à} }4}"}&} }*} }
> }%}&"}&G}4}'}"}(}"!Ñ~~?}#¿!}!â} }4}"}&} }*} }
> }%}&"}&G}4}'}"}(}"h}7~~?}#¿!}!ä} }4}"}&} }*} }
> }%}&"}&G}4}'}"}(}"¢?~~?}#¿!}!ã} }4}"}&} }*} } }%}&"}&G}4}'}"}(}"Î9~
> NO CARRIER
> ----minicom output end
>
> As you can see, my script only works (now) -- that is, actually goes
> through the authentification process -- iff the CONNECT speed matches
> 42000. Considering that this speed can change upon each connection,
> this is one bug from the script.
>
> In any case, using minicom basically gives me a verbose version of
> what has been happening all along. The one interesting detail is the
> line "Async interface address is unnumbered (Ethernet0)". In the
> ppp-logs I have made, before failure, there is always a line "Using
> interface ppp0" and then "ppp0<->ttyS0". The line "Async interface
> address is unnumbered (Ethernet0)" appears to suggest that my machine
> is trying to use interface etho. I don't know.
>
OK, minicom verifies your chat script is fine. And you can get PPP started.
Now, as soon as PPP gets started, you need to quickly exit minicom with no
modem reset and execute
pppd -d -detach /dev/ttyS0 38400 &
from the command line. This must be done quickly before your ISP terminates
your PPP. I usually like to type in the command from another console or
xterm so that it will be immediately ready upon minicom exit.
This step should start your PPP session. Just follow Section 14 of the
PPP-HOWTO.
I recommend you persevere until you are successful at establishing a manual
PPP connection in this way.
There is a PPP mailing list I also recommend signing on to for solving
difficult connection problems.
But the next place to look is your /etc/ppp/options file. If you had a
successful connection with the same ISP on Red Hat, you should be able to
use the same one you used there.
These procedures are laborious, but they have the advantage that you
control everything. There are no software blackboxes (e.g., wvdial) in the
middle. Also, you come to understand the underlying processes much better.
Good luck,
Dwight
>
> >But if your ISP does authenticate this way, you should see the prompts
> >from the left side of your chat script appear for you to respond to.
> >
> >> The ugly init screen above is basically the one I run on my mac using
> >> the same modem to connect to my ISP. I've checked it with the modem
> >> manual and its pretty non-controversial.
> >>
> >>
> >> >Try dialing in using minicom. An immediate hangup like you are
> >> >getting suggests a possible problem with your modem.
> >> >
> >> >Minicom will show you what you get back from your ISP when your call
> >> >first gets answered.
> >> >
> >> I will try minicom tomorrow night.
> >
> >The PPP-HOWTO by Robert Hart goes into the details of making this manual
> >connection in minicom. My version is from 1997 but I highly recommend
> >your reading it. On your Mac, you may have to revert to a custom-built
> >script and the PPP-HOWTO will show you how to put it together.
>
> Yep, I have read this too.
>
> >
> >> >Set kdebug to 7 and observe the dialup dialog with your chatscript.
> >
> >Still recommended. You would probably view this output in
> >/var/log/messages unless you have routed it elsewhere.
>
> I am still doing this rerouting message deamon,local2.debug
> /var/log/pppoutput. Here's an interesting thing though. When I use
> minicom, I get absolute no ppp output in the log. This makes sense
> because I'm not having ppp dialout through chat, but minicom itself.
> Hmm...
>
>
> >
> >Dwight
>
>
Reply to: