Discussion:
wvdial does not connect
(too old to reply)
u***@yahoo.com
2006-04-04 09:48:53 UTC
Permalink
Hi,

I am trying to dial to the local GPRS network here in Malaysia. My
system is running on linux and I am very new to linux and pppd. After
installing linux, pppd and wvdial onto my system, I face a weird
situation where it can't seem to connect to the GPRS network. I've
configure all the necessary configurations and below is the snippet
from the debug log (/var/log/debug).

Apr 4 15:52:49 ifs pppd[24952]: pppd 2.4.2 started by root, uid 0
Apr 4 15:52:49 ifs pppd[24952]: using channel 32
Apr 4 15:52:49 ifs pppd[24952]: Using interface ppp0
Apr 4 15:52:49 ifs pppd[24952]: Connect: ppp0 <--> /dev/ttyACM0
Apr 4 15:52:49 ifs pppd[24952]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0x57865201> <pcomp> <accomp>]
Apr 4 15:52:49 ifs pppd[24952]: rcvd [LCP ConfAck id=0x1 <asyncmap
0x0> <magic 0x57865201> <pcomp> <accomp>]
Apr 4 15:52:52 ifs pppd[24952]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0x57865201> <pcomp> <accomp>]
Apr 4 15:52:52 ifs pppd[24952]: rcvd [LCP ConfAck id=0x1 <asyncmap
0x0> <magic 0x57865201> <pcomp> <accomp>]
Apr 4 15:52:55 ifs pppd[24952]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0x57865201> <pcomp> <accomp>]
Apr 4 15:52:55 ifs pppd[24952]: rcvd [LCP ConfAck id=0x1 <asyncmap
0x0> <magic 0x57865201> <pcomp> <accomp>]
Apr 4 15:52:57 ifs pppd[24952]: rcvd [LCP ConfReq id=0x1 <mru 1500>
<asyncmap 0x0> <auth pap> <magic 0x30200000> <pcomp> <accomp>]
Apr 4 15:52:57 ifs pppd[24952]: sent [LCP ConfAck id=0x1 <mru 1500>
<asyncmap 0x0> <auth pap> <magic 0x30200000> <pcomp> <accomp>]
Apr 4 15:52:57 ifs pppd[24952]: sent [PAP AuthReq id=0x1 user="digi"
password=<hidden>]
Apr 4 15:52:57 ifs pppd[24952]: rcvd [LCP EchoReq id=0x1
magic=0x30200000]
Apr 4 15:52:57 ifs pppd[24952]: sent [LCP EchoRep id=0x1
magic=0x57865201]
Apr 4 15:53:00 ifs pppd[24952]: sent [PAP AuthReq id=0x2 user="digi"
password=<hidden>]
Apr 4 15:53:00 ifs pppd[24952]: rcvd [PAP AuthAck id=0x2 "Welcome to
Motorola A760 Software Modem!"]
Apr 4 15:53:00 ifs pppd[24952]: Remote message: Welcome to Motorola
A760 Software Modem!
Apr 4 15:53:00 ifs pppd[24952]: PAP authentication succeeded
Apr 4 15:53:00 ifs pppd[24952]: sent [CCP ConfReq id=0x1 <deflate 15>
<deflate(old#) 15>]
Apr 4 15:53:00 ifs pppd[24952]: sent [IPCP ConfReq id=0x1 <compress VJ
0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Apr 4 15:53:00 ifs pppd[24952]: rcvd [IPCP ConfRej id=0x1 <compress VJ
0f 01>]
Apr 4 15:53:00 ifs pppd[24952]: sent [IPCP ConfReq id=0x2 <addr
0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Apr 4 15:53:02 ifs pppd[24952]: rcvd [LCP EchoReq id=0x1
magic=0x30200000]
Apr 4 15:53:02 ifs pppd[24952]: sent [LCP EchoRep id=0x1
magic=0x57865201]
Apr 4 15:53:03 ifs pppd[24952]: sent [CCP ConfReq id=0x1 <deflate 15>
<deflate(old#) 15>]
Apr 4 15:53:03 ifs pppd[24952]: sent [IPCP ConfReq id=0x2 <addr
0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Apr 4 15:53:05 ifs pppd[24952]: rcvd [IPCP ConfReq id=0x1]
Apr 4 15:53:05 ifs pppd[24952]: sent [IPCP ConfNak id=0x1 <addr
0.0.0.0>]
Apr 4 15:53:05 ifs pppd[24952]: rcvd [LCP TermReq id=0x2 00 00 00 00
00 00]
Apr 4 15:53:05 ifs pppd[24952]: LCP terminated by peer (^@^@^@^@^@^@)
Apr 4 15:53:05 ifs pppd[24952]: sent [LCP TermAck id=0x2]
Apr 4 15:53:08 ifs pppd[24952]: Connection terminated.
Apr 4 15:53:08 ifs pppd[24952]: Exit.

Does the above problem caused by a timeout? Why does LCP been
terminated by peer? Does that mean the ISP does not support LCP?

Any help will be much and greatly appreciated.

-Ray-
James Carlson
2006-04-04 11:30:38 UTC
Permalink
Post by u***@yahoo.com
I am trying to dial to the local GPRS network here in Malaysia. My
You might want to search netnews archives. The oddities of GPRS have
been discussed many times before.
Post by u***@yahoo.com
Apr 4 15:53:03 ifs pppd[24952]: sent [IPCP ConfReq id=0x2 <addr
0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Apr 4 15:53:05 ifs pppd[24952]: rcvd [IPCP ConfReq id=0x1]
Apr 4 15:53:05 ifs pppd[24952]: sent [IPCP ConfNak id=0x1 <addr
0.0.0.0>]
Apr 4 15:53:05 ifs pppd[24952]: rcvd [LCP TermReq id=0x2 00 00 00 00
00 00]
This behavior is pretty typical for GPRS.

GPRS is designed very strangely. It does not do peer authentication
during the PPP Authentication phase. That PAP Authenticate-Ack that
you see is a complete fabrication: no authentication was done.
Instead, it waits until IPCP runs to authenticate the user. If
authentication fails, you then get really strange behavior with the
peer appearing to be unable to negotiate an IP address.

This is just a GPRS design flaw.
Post by u***@yahoo.com
Does the above problem caused by a timeout?
No. It means that either your user name/password are incorrect, or
that your GPRS service has not been properly activated.
Post by u***@yahoo.com
Why does LCP been
terminated by peer?
It means that the peer is asking you to please go away. It doesn't
want to talk to you anymore. It could just disconnect at layer one
(hang up the phone), but it's being overly polite.

Other than the suggestions above, the only way to find out why the
peer sent the link termination request is to go inspect the debug logs
on the peer's side. LCP provides a means for some useful text
information to be included in the termination message, but for some
reason the peer didn't bother doing that.
Post by u***@yahoo.com
Does that mean the ISP does not support LCP?
No.
--
James Carlson, KISS Network <***@sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
u***@yahoo.com
2006-04-04 12:32:13 UTC
Permalink
Nice to hear from you James. I've been reading your replies in this
group to guide me on ppp.
Post by James Carlson
You might want to search netnews archives. The oddities of GPRS have
been discussed many times before.
netnews archives??
Post by James Carlson
This behavior is pretty typical for GPRS.
GPRS is designed very strangely. It does not do peer authentication
during the PPP Authentication phase. That PAP Authenticate-Ack that
you see is a complete fabrication: no authentication was done.
Instead, it waits until IPCP runs to authenticate the user. If
authentication fails, you then get really strange behavior with the
peer appearing to be unable to negotiate an IP address.
This is just a GPRS design flaw.
Now I get a clearer picture.
Post by James Carlson
No. It means that either your user name/password are incorrect, or
that your GPRS service has not been properly activated.
I believe the username and password should be correct. It is provided
by the service provider here. I also believe that GPRS service has been
properly activated as I managed to dial up on MS Win XP platform and
also do some surfing on the phone itself, just to make sure GPRS and
the phone works properly. Perhaps the only thing that I am afraid most
is missing configurations. I've added the user name and password even
to /etc/ppp/pap-secrets, necessary configurations to /etc/ppp/options
and configured wvdial.conf. I hope and certainly wish I do not miss
anything.
Post by James Carlson
It means that the peer is asking you to please go away. It doesn't
want to talk to you anymore. It could just disconnect at layer one
(hang up the phone), but it's being overly polite.
So this could mean that all the pap authentication messages is a polite
act? If so, why does IPCP send a ConfReq? If that is normal, then how
come it can dial on a Win XP system?
Post by James Carlson
Other than the suggestions above, the only way to find out why the
peer sent the link termination request is to go inspect the debug logs
on the peer's side. LCP provides a means for some useful text
information to be included in the termination message, but for some
reason the peer didn't bother doing that.
Debug log at the peer side? Do you mean check on the ISP side? I have
no idea on how to do this.

Thanks and hope to hear from you soon.

Regards,
Raymond
James Carlson
2006-04-04 13:32:21 UTC
Permalink
Post by u***@yahoo.com
Post by James Carlson
You might want to search netnews archives. The oddities of GPRS have
been discussed many times before.
netnews archives??
There are many. Try http://groups.google.com/.
Post by u***@yahoo.com
Post by James Carlson
No. It means that either your user name/password are incorrect, or
that your GPRS service has not been properly activated.
I believe the username and password should be correct. It is provided
by the service provider here. I also believe that GPRS service has been
properly activated as I managed to dial up on MS Win XP platform and
also do some surfing on the phone itself, just to make sure GPRS and
the phone works properly. Perhaps the only thing that I am afraid most
is missing configurations. I've added the user name and password even
to /etc/ppp/pap-secrets, necessary configurations to /etc/ppp/options
and configured wvdial.conf. I hope and certainly wish I do not miss
anything.
You should have something like this in your pppd configuration:

user yourname

and something like this in pap-secrets:

yourname * "your passphrase"

Be careful; special characters present in your username or passphrase
must be escaped.
Post by u***@yahoo.com
Post by James Carlson
It means that the peer is asking you to please go away. It doesn't
want to talk to you anymore. It could just disconnect at layer one
(hang up the phone), but it's being overly polite.
So this could mean that all the pap authentication messages is a polite
act?
No; it's just broken by the GPRS standards. The peer sends PAP
Authenticate-Ack even if the user name and passphrase you present are
nonsense.
Post by u***@yahoo.com
If so, why does IPCP send a ConfReq? If that is normal, then how
come it can dial on a Win XP system?
I'm guessing that your user name / passphrase are correct on that XP
system but are incorrect on this system.
Post by u***@yahoo.com
Post by James Carlson
Other than the suggestions above, the only way to find out why the
peer sent the link termination request is to go inspect the debug logs
on the peer's side. LCP provides a means for some useful text
information to be included in the termination message, but for some
reason the peer didn't bother doing that.
Debug log at the peer side? Do you mean check on the ISP side? I have
no idea on how to do this.
Nor do I. Good luck.
--
James Carlson, KISS Network <***@sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
u***@yahoo.com
2006-04-05 11:09:27 UTC
Permalink
Post by James Carlson
user yourname
yourname * "your passphrase"
This is what I have in /etc/ppp/options
lock
crtscts
defaultroute
noauth
noipdefault
name digi
debug

and this is what I have in /etc/ppp/pap-secrets
# Secrets for authentication using PAP
# client server secret IP addresses
name * password

Is there anything wrong with this?
Post by James Carlson
I'm guessing that your user name / passphrase are correct on that XP
system but are incorrect on this system.
Both Systems use different authentication?
Post by James Carlson
Nor do I. Good luck.
If I could somehow manage to check the peer's log, I do not think the
service provider would grant me access for this. =P

Hope I do not miss anything.

Raymond
James Carlson
2006-04-05 11:20:33 UTC
Permalink
Post by u***@yahoo.com
This is what I have in /etc/ppp/options
lock
crtscts
defaultroute
noauth
noipdefault
name digi
debug
You should have "user digi" instead of "name digi," assuming your name
is in fact "digi." It's a bit of a minor point, but "name" is
typically used for dial-in servers (which is not what you have) and
"user" is used for dial-out.

You may also want "noccp," as it's clear the peer doesn't implement
that.
Post by u***@yahoo.com
and this is what I have in /etc/ppp/pap-secrets
# Secrets for authentication using PAP
# client server secret IP addresses
name * password
Is there anything wrong with this?
Is that literal? You should have exactly the same "name" here that's
given for the name or user option in /etc/ppp/options.
Post by u***@yahoo.com
Post by James Carlson
I'm guessing that your user name / passphrase are correct on that XP
system but are incorrect on this system.
Both Systems use different authentication?
I don't understand what you're saying here.

My comment was that the symptoms here imply that you've correctly
configured your peer (user) name and passphrase on that XP box, but
you have not correctly configured the same data on the machine running
pppd. It is likely to be the incorrectly specified user name and/or
passphrase that is causing the problem.
--
James Carlson, KISS Network <***@sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
Unruh
2006-04-05 16:57:04 UTC
Permalink
Post by u***@yahoo.com
Post by James Carlson
user yourname
yourname * "your passphrase"
This is what I have in /etc/ppp/options
lock
crtscts
defaultroute
noauth
noipdefault
name digi
This is not causing the problem but use
user digi
not name digi
Also put in novj and noccp
Post by u***@yahoo.com
debug
and this is what I have in /etc/ppp/pap-secrets
# Secrets for authentication using PAP
# client server secret IP addresses
name * password
I assume that you have
digi
not
name
in that line. and for password it is the actual password, not the word
password.
Post by u***@yahoo.com
Is there anything wrong with this?
Post by James Carlson
I'm guessing that your user name / passphrase are correct on that XP
system but are incorrect on this system.
Both Systems use different authentication?
Post by James Carlson
Nor do I. Good luck.
If I could somehow manage to check the peer's log, I do not think the
service provider would grant me access for this. =P
Hope I do not miss anything.
Trying to figure out how other people could be incompetent is always a hard
job. The creativity of incompetence seems boundless.
Goh Choon Lye
2006-04-06 09:34:02 UTC
Permalink
Hi,

Where is your chatscript to setup physical link ? or you have another

/etc/ppp/options.ttyACM0 file since pppd using ttyACM0 .

I have setup GPRS connection with pppd in RedHat on ttyS0 with
iTegno/Siemen modem.
My configuration /etc/ppp/options.ttyS0 file;
lock
crtscts
nobsdcomp
novj
noipdefault
deflate 0,0
defaultroute
user abc
pap-timeout 10
pap-max-authreq 3
connect "/usr/sbin/chat -v -t 20 -f /etc/ppp/chatscript"

/etc/ppp/chatscript
"" "AT"
OK "AT+CGDCONT=1,\"IP\",\"shsurbana1\""
OK "AT+CGATT=1"
OK "ATDT*99***1#"
TIMEOUT 60 CONNECT

/etc/ppp/pap-secrets
abc * *
u***@yahoo.com
2006-04-06 12:10:28 UTC
Permalink
Post by Goh Choon Lye
Hi,
Where is your chatscript to setup physical link ? or you have another
/etc/ppp/options.ttyACM0 file since pppd using ttyACM0 .
I do not have /etc/ppp/options.ttyACM0. I am using wvdial and below is
my wvdial.conf

[Dialer Defaults]
Modem = /dev/ttyACM0
Baud = 460800
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCFLAGS=0
Init3 = AT+CGDCONT=1, "IP", "diginet"
Usename = digi
Password = digi
ISDN = 0
Modem Type = USB Modem

The above uses the default wvdial configuration except the phone
number, username and password.



James, Unruh,

This is my new /etc/ppp/options
lock
crtscts
defaultroute
noauth
noipdefault
noccp
novj
user digi
debug

and this is my new /etc/ppp/pap-secrets
# Secrets for authentication using PAP
# client server secret IP addresses
digi * digi

I try connecting and still face the same log message.

Regards,
Raymond
James Carlson
2006-04-06 13:15:35 UTC
Permalink
Post by u***@yahoo.com
I try connecting and still face the same log message.
I think that makes it fairly simple: the problem has to be an
incorrect user name and/or password. You need to correct those, and I
don't see how anyone here can really help with that.
--
James Carlson, KISS Network <***@sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
Unruh
2006-04-06 16:35:08 UTC
Permalink
Post by u***@yahoo.com
Post by Goh Choon Lye
Hi,
Where is your chatscript to setup physical link ? or you have another
/etc/ppp/options.ttyACM0 file since pppd using ttyACM0 .
I do not have /etc/ppp/options.ttyACM0. I am using wvdial and below is
my wvdial.conf
[Dialer Defaults]
Modem = /dev/ttyACM0
Baud = 460800
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCFLAGS=0
Init3 = AT+CGDCONT=1, "IP", "diginet"
Usename = digi
Password = digi
ISDN = 0
Modem Type = USB Modem
The above uses the default wvdial configuration except the phone
number, username and password.
James, Unruh,
This is my new /etc/ppp/options
lock
crtscts
defaultroute
noauth
noipdefault
noccp
novj
user digi
debug
and this is my new /etc/ppp/pap-secrets
# Secrets for authentication using PAP
# client server secret IP addresses
digi * digi
I try connecting and still face the same log message.
No you do not. There should be no compression attempts and no vj requests.
Please post the output of th elogs. YOu admit that you do not understand
what is happening. Thus your ability to read the logs is also suspect.

Finally as James says, it may well be that the remote system thinks your
username or password are incorrect. You can only find that out by talking
with your ISP.

If they are rejecting you because of your password or username, you cannot
tell from your end. Nothing you post or try to do will work.

As an example, try replacing your username and password in
/etc/ppp/pap-secrets with wrong ones, and try logging on. Is there any
difference in the logon? If there is then the hypothesis is wrong, but if
there is not, then it is the strongest possibility.
Post by u***@yahoo.com
Regards,
Raymond
u***@yahoo.com
2006-04-07 07:04:47 UTC
Permalink
I will post the log message coming monday as I will be away during the
weekend. In the mean time I will also try some other username and
password just to verify whether I will get the same log message.

Thanks for the help all these while.

Raymond
Post by Unruh
Post by u***@yahoo.com
Post by Goh Choon Lye
Hi,
Where is your chatscript to setup physical link ? or you have another
/etc/ppp/options.ttyACM0 file since pppd using ttyACM0 .
I do not have /etc/ppp/options.ttyACM0. I am using wvdial and below is
my wvdial.conf
[Dialer Defaults]
Modem = /dev/ttyACM0
Baud = 460800
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCFLAGS=0
Init3 = AT+CGDCONT=1, "IP", "diginet"
Usename = digi
Password = digi
ISDN = 0
Modem Type = USB Modem
The above uses the default wvdial configuration except the phone
number, username and password.
James, Unruh,
This is my new /etc/ppp/options
lock
crtscts
defaultroute
noauth
noipdefault
noccp
novj
user digi
debug
and this is my new /etc/ppp/pap-secrets
# Secrets for authentication using PAP
# client server secret IP addresses
digi * digi
I try connecting and still face the same log message.
No you do not. There should be no compression attempts and no vj requests.
Please post the output of th elogs. YOu admit that you do not understand
what is happening. Thus your ability to read the logs is also suspect.
Finally as James says, it may well be that the remote system thinks your
username or password are incorrect. You can only find that out by talking
with your ISP.
If they are rejecting you because of your password or username, you cannot
tell from your end. Nothing you post or try to do will work.
As an example, try replacing your username and password in
/etc/ppp/pap-secrets with wrong ones, and try logging on. Is there any
difference in the logon? If there is then the hypothesis is wrong, but if
there is not, then it is the strongest possibility.
Post by u***@yahoo.com
Regards,
Raymond
Unruh
2006-04-05 16:54:51 UTC
Permalink
Post by James Carlson
Post by u***@yahoo.com
Post by James Carlson
You might want to search netnews archives. The oddities of GPRS have
been discussed many times before.
netnews archives??
There are many. Try http://groups.google.com/.
Post by u***@yahoo.com
Post by James Carlson
No. It means that either your user name/password are incorrect, or
that your GPRS service has not been properly activated.
I believe the username and password should be correct. It is provided
by the service provider here. I also believe that GPRS service has been
properly activated as I managed to dial up on MS Win XP platform and
also do some surfing on the phone itself, just to make sure GPRS and
the phone works properly. Perhaps the only thing that I am afraid most
is missing configurations. I've added the user name and password even
to /etc/ppp/pap-secrets, necessary configurations to /etc/ppp/options
and configured wvdial.conf. I hope and certainly wish I do not miss
anything.
user yourname
yourname * "your passphrase"
Be careful; special characters present in your username or passphrase
must be escaped.
He apparently has those since he does answer the pap authentication
request. Now it may be that the username or password are wrong of course.
Post by James Carlson
Post by u***@yahoo.com
Post by James Carlson
It means that the peer is asking you to please go away. It doesn't
want to talk to you anymore. It could just disconnect at layer one
(hang up the phone), but it's being overly polite.
So this could mean that all the pap authentication messages is a polite
act?
No; it's just broken by the GPRS standards. The peer sends PAP
Authenticate-Ack even if the user name and passphrase you present are
nonsense.
Post by u***@yahoo.com
If so, why does IPCP send a ConfReq? If that is normal, then how
come it can dial on a Win XP system?
I'm guessing that your user name / passphrase are correct on that XP
system but are incorrect on this system.
Post by u***@yahoo.com
Post by James Carlson
Other than the suggestions above, the only way to find out why the
peer sent the link termination request is to go inspect the debug logs
on the peer's side. LCP provides a means for some useful text
information to be included in the termination message, but for some
reason the peer didn't bother doing that.
Debug log at the peer side? Do you mean check on the ISP side? I have
no idea on how to do this.
Nor do I. Good luck.
Unruh
2006-04-05 16:53:22 UTC
Permalink
Post by u***@yahoo.com
Nice to hear from you James. I've been reading your replies in this
group to guide me on ppp.
Post by James Carlson
You might want to search netnews archives. The oddities of GPRS have
been discussed many times before.
netnews archives??
Post by James Carlson
This behavior is pretty typical for GPRS.
GPRS is designed very strangely. It does not do peer authentication
during the PPP Authentication phase. That PAP Authenticate-Ack that
you see is a complete fabrication: no authentication was done.
Instead, it waits until IPCP runs to authenticate the user. If
authentication fails, you then get really strange behavior with the
peer appearing to be unable to negotiate an IP address.
This is just a GPRS design flaw.
Now I get a clearer picture.
Post by James Carlson
No. It means that either your user name/password are incorrect, or
that your GPRS service has not been properly activated.
I believe the username and password should be correct. It is provided
by the service provider here. I also believe that GPRS service has been
properly activated as I managed to dial up on MS Win XP platform and
also do some surfing on the phone itself, just to make sure GPRS and
the phone works properly. Perhaps the only thing that I am afraid most
is missing configurations. I've added the user name and password even
to /etc/ppp/pap-secrets, necessary configurations to /etc/ppp/options
and configured wvdial.conf. I hope and certainly wish I do not miss
anything.
Post by James Carlson
It means that the peer is asking you to please go away. It doesn't
want to talk to you anymore. It could just disconnect at layer one
(hang up the phone), but it's being overly polite.
So this could mean that all the pap authentication messages is a polite
act? If so, why does IPCP send a ConfReq? If that is normal, then how
come it can dial on a Win XP system?
Who knows what it is trying to do. It is very confused. It may be that your
compression requests drive it out of its mind. Win would not ask for those
compressions.
Post by u***@yahoo.com
Post by James Carlson
Other than the suggestions above, the only way to find out why the
peer sent the link termination request is to go inspect the debug logs
on the peer's side. LCP provides a means for some useful text
information to be included in the termination message, but for some
reason the peer didn't bother doing that.
Debug log at the peer side? Do you mean check on the ISP side? I have
no idea on how to do this.
Yes, that is a problem.
Post by u***@yahoo.com
Thanks and hope to hear from you soon.
Regards,
Raymond
Unruh
2006-04-05 16:50:32 UTC
Permalink
Your MOtorola's implimentation of ppp is bizare.
Get rid of the request for ccp, (put noccp , novj, into /etc/ppp/options.)

The remote system does support ppp, but its implimentation seems to be
exceedingly broken. You are going to have to try to immitate a Win machine
as much as possible.
Post by u***@yahoo.com
Hi,
I am trying to dial to the local GPRS network here in Malaysia. My
system is running on linux and I am very new to linux and pppd. After
installing linux, pppd and wvdial onto my system, I face a weird
situation where it can't seem to connect to the GPRS network. I've
configure all the necessary configurations and below is the snippet
from the debug log (/var/log/debug).
Apr 4 15:52:49 ifs pppd[24952]: pppd 2.4.2 started by root, uid 0
Apr 4 15:52:49 ifs pppd[24952]: using channel 32
Apr 4 15:52:49 ifs pppd[24952]: Using interface ppp0
Apr 4 15:52:49 ifs pppd[24952]: Connect: ppp0 <--> /dev/ttyACM0
Apr 4 15:52:49 ifs pppd[24952]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0x57865201> <pcomp> <accomp>]
Apr 4 15:52:49 ifs pppd[24952]: rcvd [LCP ConfAck id=0x1 <asyncmap
0x0> <magic 0x57865201> <pcomp> <accomp>]
Apr 4 15:52:52 ifs pppd[24952]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0x57865201> <pcomp> <accomp>]
YOur own implimentation also seems to be broken. It gets a ConfAck and
immediately sends out the same request. What pppd are you running? Are you
sure that your distribution has not messed it up?

Mind you the remote machine seems to be incapable of starting its own ppp
stream, so maybe your side is just trying to wake it up.
Post by u***@yahoo.com
Apr 4 15:52:52 ifs pppd[24952]: rcvd [LCP ConfAck id=0x1 <asyncmap
0x0> <magic 0x57865201> <pcomp> <accomp>]
Apr 4 15:52:55 ifs pppd[24952]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0x57865201> <pcomp> <accomp>]
Apr 4 15:52:55 ifs pppd[24952]: rcvd [LCP ConfAck id=0x1 <asyncmap
0x0> <magic 0x57865201> <pcomp> <accomp>]
Apr 4 15:52:57 ifs pppd[24952]: rcvd [LCP ConfReq id=0x1 <mru 1500>
<asyncmap 0x0> <auth pap> <magic 0x30200000> <pcomp> <accomp>]
Finally a ConfReq from the other side. 10 sec after negotiations start.
This is not good.
Post by u***@yahoo.com
Apr 4 15:52:57 ifs pppd[24952]: sent [LCP ConfAck id=0x1 <mru 1500>
<asyncmap 0x0> <auth pap> <magic 0x30200000> <pcomp> <accomp>]
Apr 4 15:52:57 ifs pppd[24952]: sent [PAP AuthReq id=0x1 user="digi"
password=<hidden>]
Apr 4 15:52:57 ifs pppd[24952]: rcvd [LCP EchoReq id=0x1
magic=0x30200000]
Apr 4 15:52:57 ifs pppd[24952]: sent [LCP EchoRep id=0x1
magic=0x57865201]
Apr 4 15:53:00 ifs pppd[24952]: sent [PAP AuthReq id=0x2 user="digi"
password=<hidden>]
Apr 4 15:53:00 ifs pppd[24952]: rcvd [PAP AuthAck id=0x2 "Welcome to
Motorola A760 Software Modem!"]
Apr 4 15:53:00 ifs pppd[24952]: Remote message: Welcome to Motorola
A760 Software Modem!
Apr 4 15:53:00 ifs pppd[24952]: PAP authentication succeeded
OK, you are authenticated.
Post by u***@yahoo.com
Apr 4 15:53:00 ifs pppd[24952]: sent [CCP ConfReq id=0x1 <deflate 15>
<deflate(old#) 15>]
This may be totally confusing the remote machine. Make sure you put noccp
into your options file.
Post by u***@yahoo.com
Apr 4 15:53:00 ifs pppd[24952]: sent [IPCP ConfReq id=0x1 <compress VJ
0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Apr 4 15:53:00 ifs pppd[24952]: rcvd [IPCP ConfRej id=0x1 <compress VJ
0f 01>]
Ah, a response. Also put in novj
Post by u***@yahoo.com
Apr 4 15:53:00 ifs pppd[24952]: sent [IPCP ConfReq id=0x2 <addr
0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
And now the remote system has gone into a sulk. Who knowns why.

You might get rid of the ms-dns requests. ( remove them from
/etc/ppp/options) to see if you at least get a connection.
Post by u***@yahoo.com
Apr 4 15:53:02 ifs pppd[24952]: rcvd [LCP EchoReq id=0x1
magic=0x30200000]
Sheesh. This is the phone trying to see if yo uare still awake, when it has
gone to sleep.
Post by u***@yahoo.com
Apr 4 15:53:02 ifs pppd[24952]: sent [LCP EchoRep id=0x1
magic=0x57865201]
Apr 4 15:53:03 ifs pppd[24952]: sent [CCP ConfReq id=0x1 <deflate 15>
<deflate(old#) 15>]
Again, it will NOT be able to do these compressions. You should not be
asking. It probably confuses the far side, because the programmer was
incompetent.
Post by u***@yahoo.com
Apr 4 15:53:03 ifs pppd[24952]: sent [IPCP ConfReq id=0x2 <addr
0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Apr 4 15:53:05 ifs pppd[24952]: rcvd [IPCP ConfReq id=0x1]
This is silly. It has really gone into a sulk.
Post by u***@yahoo.com
Apr 4 15:53:05 ifs pppd[24952]: sent [IPCP ConfNak id=0x1 <addr
0.0.0.0>]
Apr 4 15:53:05 ifs pppd[24952]: rcvd [LCP TermReq id=0x2 00 00 00 00
00 00]
And finally it says it does not want to talk to you.
Post by u***@yahoo.com
Apr 4 15:53:05 ifs pppd[24952]: sent [LCP TermAck id=0x2]
Apr 4 15:53:08 ifs pppd[24952]: Connection terminated.
Apr 4 15:53:08 ifs pppd[24952]: Exit.
Does the above problem caused by a timeout? Why does LCP been
No.
Post by u***@yahoo.com
terminated by peer? Does that mean the ISP does not support LCP?
It means the far side requested that you get lost.
No it does not mean it does not support LCP. It has been talking LCP during
the whole negotiation. It is impossible to know what it does not like from
this exchange since the far side remains largely silent.
Post by u***@yahoo.com
Any help will be much and greatly appreciated.
-Ray-
James Carlson
2006-04-05 19:45:53 UTC
Permalink
Post by Unruh
Post by u***@yahoo.com
Apr 4 15:52:49 ifs pppd[24952]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0x57865201> <pcomp> <accomp>]
Apr 4 15:52:49 ifs pppd[24952]: rcvd [LCP ConfAck id=0x1 <asyncmap
0x0> <magic 0x57865201> <pcomp> <accomp>]
Apr 4 15:52:52 ifs pppd[24952]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0x57865201> <pcomp> <accomp>]
YOur own implimentation also seems to be broken. It gets a ConfAck and
immediately sends out the same request.
That's not true. Look at the time stamps. That second request is due
to the restart timer -- three seconds have elapsed without a Configure
Request message from the peer, which means we're stuck in AckRcvd
state with the timer running. TO+ causes a new request to be sent.

This is all correct, and not a bug, and not broken.

The problems are on the peer's side. That it's using GPRS is probably
the most significant one.
--
James Carlson, KISS Network <***@sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
Unruh
2006-04-05 22:30:48 UTC
Permalink
Post by James Carlson
Post by Unruh
Post by u***@yahoo.com
Apr 4 15:52:49 ifs pppd[24952]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0x57865201> <pcomp> <accomp>]
Apr 4 15:52:49 ifs pppd[24952]: rcvd [LCP ConfAck id=0x1 <asyncmap
0x0> <magic 0x57865201> <pcomp> <accomp>]
Apr 4 15:52:52 ifs pppd[24952]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0x57865201> <pcomp> <accomp>]
YOur own implimentation also seems to be broken. It gets a ConfAck and
immediately sends out the same request.
That's not true. Look at the time stamps. That second request is due
to the restart timer -- three seconds have elapsed without a Configure
Request message from the peer, which means we're stuck in AckRcvd
state with the timer running. TO+ causes a new request to be sent.
This is all correct, and not a bug, and not broken.
Yes, I was beginning to suspect that. Wait 2 sec for a counter proposal
from the far side and try again if it does not come? It knows that ppp is
operational on the far side since it did get a ConfAck.
Post by James Carlson
The problems are on the peer's side. That it's using GPRS is probably
the most significant one.
Well, it is a useful service. Too bad the implimenters all seem to be
incompetent. Have not read enough books I guess :-)
Loading...