Re: PPP Problems cont.
Hi Guys:
This is what I do.
I don't log in. Loging in implies V.120. V.120 sucks.
When I get the "CONNECT" is just start ppp negotiation.
This approach seem to work with several ISPs.
I'm using a Zyxel ISDN modem at 128 so don't be
confused with the init or dialing strings.
Below is my provider file
ABORT BUSY
ABORT "NO CARRIER"
ABORT VOICE
ABORT "NO DIALTONE"
"" ATB40&K44&J3
"" ATDI98609234+98609234
CONNECT '' <-- these are single quotes
When the modem generates a CONNECT string,
the box goes right into LCP negotiation and
authenticates via PAP. In my options file I have
a line which states my login name as follows:
name _genx@isdn
In my pap-secrets file I have a line which provides
my outbound password for the userid in question
as follows:
_genx@isdn * password
Hope this is of some use.
Peter
Kent West wrote:
> On Mon, 9 Nov 1998, Chris Hoover wrote:
>
> > I still can not get my linux box to connect to my isp (bellsouth.net),
> > and am looking for ideas and help.
> >
> > Attached is a copy of my /etc/ppp/peers/provider,
> > /etc/chatscripts/provider, and /var/log/ppp.log.
> >
> > Can someone tell me what is going on here? I've used pppconfig to set
> > it all up, and it dials out fine, but it ppp dies right after
> > connecting.
> >
> > Thanks,
> >
> > Chris
> >
> >
> >
> > /etc/ppp/peers/provider
> > # This file was generated by pppconfig. You can edit the following
> > lines
> > # but please do not delete lines or the change the comments or you will
> > # confuse pppconfig.
> > noauth #pppconfig_noauth
> > connect "/usr/sbin/chat -v -f /etc/chatscripts/provider"
> > #pppconfig_connect
> > debug #pppconfig_debug
> > /dev/ttyS2 #pppconfig_dev
> > 115200 #pppconfig_speed
> > defaultroute #pppconfig_route
> > noipdefault #pppconfig_ipdefault
> > user wax_man #pppconfig_user
> > # End of pppconfig controlled lines. You can add lines below here
> > without
> > # confusing pppconfig.
> >
> >
> >
> > /var/log/ppp.log
> > Nov 9 20:58:18 tux pppd[480]: pppd 2.3.5 started by root, uid 0
> > Nov 9 20:58:19 tux chat[481]: abort on (BUSY)
> > Nov 9 20:58:19 tux chat[481]: abort on (NO CARRIER)
> > Nov 9 20:58:19 tux chat[481]: abort on (VOICE)
> > Nov 9 20:58:19 tux chat[481]: abort on (NO DIALTONE)
> > Nov 9 20:58:19 tux chat[481]: abort on (NO ANSWER)
> > Nov 9 20:58:19 tux chat[481]: send (ATZ^M)
> > Nov 9 20:58:19 tux chat[481]: expect (OK)
> > Nov 9 20:58:38 tux chat[481]: ATZ^M^M
> > Nov 9 20:58:38 tux chat[481]: OK
> > Nov 9 20:58:38 tux chat[481]: -- got it
> > Nov 9 20:58:38 tux chat[481]: send (ATDT2528294^M)
> > Nov 9 20:58:38 tux chat[481]: expect (CONNECT)
> > Nov 9 20:58:38 tux chat[481]: ^M
> > Nov 9 20:59:18 tux chat[481]: ATDT2528294^M
> > Nov 9 20:59:23 tux chat[481]: alarm
> > Nov 9 20:59:23 tux chat[481]: Failed
> > Nov 9 20:59:23 tux pppd[480]: Connect script failed
> > Nov 9 20:59:24 tux pppd[480]: Exit.
> >
> >
> >
> > /etc/chatscripts/provider
> > ABORT BUSY
> > ABORT "NO CARRIER"
> > ABORT VOICE
> > ABORT "NO DIALTONE"
> > ABORT "NO ANSWER"
> > "" ATZ
> > OK ATDT2528294
> > CONNECT ''
> > sername: \d\qwax_man
> > ssword: \qpassword
> >
> > "" \d\c
>
> Just a shot in the dark; maybe your ISP's prompt uses "login:" or
> something else instead of "username:". You might want to manually dial-in
> using minicom for comparison purposes.
>
> You might also want to give wvdial a try, which is an "I'll guess my way
> through the connection process" utility that I've had good success with.
>
> --
> Unsubscribe? mail -s unsubscribe debian-user-request@lists.debian.org < /dev/null
begin:vcard
n:Iannarelli;Peter
tel;fax:1+416-929-1056
tel;work:1+416-929-1885
x-mozilla-html:FALSE
url:http://www.genxl.com
org:GenX Internte Labs;Operations
adr:;;20 Madison Ave.;Toronto;ON;M5R 2S1;CA
version:2.1
email;internet:Peter.Iannarelli
title:Engineer
x-mozilla-cpt:;0
fn:Peter Iannarelli
end:vcard
Reply to: