Could not determine local IP address
Olaf Müller-Michaels
Affix 2.0.2.
I am not able to make a GPRS/GSM connection with my T68i; my network
operator is E-Plus in Germany. I am using the following connect
script:
/etc/ppp/peers/DUN:
/dev/bty0
115200
nocrtscts
defaultroute
noipdefault
ipcp-accept-local
ipcp-accept-remote
usepeerdns
novj
novjccomp
connect-delay 1000
remotename EPlusGPRS1054131866
debug
logfile /var/log/pppd
connect '/usr/sbin/chat -s -v ABORT "NO CARRIER" ABORT "NO DIALTONE"
ABORT "BUSY" "" ATZ OK "ATD*99***2#" CONNECT'
That gives me the following error messages in my logfile:
abort on (NO CARRIER)
abort on (NO DIALTONE)
abort on (BUSY)
send (ATZ^M)
expect (OK)
ATZ^M^M
OK
-- got it
send (ATD*99***2#^M)
expect (CONNECT)
^M
ATD*99***2#^M^M
CONNECT
-- got it
Serial connection established.
using channel 3
Using interface ppp0
Connect: ppp0 <--> /dev/bty0
Warning - secret file /etc/ppp/pap-secrets has world and/or group
access
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x8f285366> <pcomp>
<accomp>]
Timeout 0x20084bc:0x203b440 in 3 seconds.
rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <pcomp> <accomp> <auth pap>]
lcp_reqci: returning CONFREJ.
sent [LCP ConfRej id=0x1 <auth pap>]
rcvd [LCP ConfRej id=0x1 <magic 0x8f285366>]
Untimeout 0x20084bc:0x203b440.
sent [LCP ConfReq id=0x2 <asyncmap 0x0> <pcomp> <accomp>]
Timeout 0x20084bc:0x203b440 in 3 seconds.
rcvd [LCP ConfReq id=0x2 <asyncmap 0x0> <pcomp> <accomp>]
lcp_reqci: returning CONFACK.
sent [LCP ConfAck id=0x2 <asyncmap 0x0> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x2 <asyncmap 0x0> <pcomp> <accomp>]
Untimeout 0x20084bc:0x203b440.
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3
0.0.0.0>]
Timeout 0x20084bc:0x203b6a0 in 3 seconds.
sent [CCP ConfReq id=0x1 <bsd v1 15>]
Timeout 0x20084bc:0x203b7a0 in 3 seconds.
rcvd [LCP ProtRej id=0x4 80 fd 01 01 00 07 15 03 2f]
Untimeout 0x20084bc:0x203b7a0.
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3
0.0.0.0>]
Timeout 0x20084bc:0x203b6a0 in 3 seconds.
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3
0.0.0.0>]
Timeout 0x20084bc:0x203b6a0 in 3 seconds.
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3
0.0.0.0>]
Timeout 0x20084bc:0x203b6a0 in 3 seconds.
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3
0.0.0.0>]
Timeout 0x20084bc:0x203b6a0 in 3 seconds.
rcvd [IPCP ConfReq id=0x1]
ipcp: returning Configure-NAK
sent [IPCP ConfNak id=0x1 <addr 0.0.0.0>]
rcvd [IPCP ConfRej id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3
0.0.0.0>]
Untimeout 0x20084bc:0x203b6a0.
sent [IPCP ConfReq id=0x2 <addrs 0.0.0.0 0.0.0.0>]
Timeout 0x20084bc:0x203b6a0 in 3 seconds.
rcvd [IPCP ConfReq id=0x2]
ipcp: returning Configure-ACK
sent [IPCP ConfAck id=0x2]
sent [IPCP ConfReq id=0x2 <addrs 0.0.0.0 0.0.0.0>]
Timeout 0x20084bc:0x203b6a0 in 3 seconds.
rcvd [IPCP ConfRej id=0x2 <addrs 0.0.0.0 0.0.0.0>]
Untimeout 0x20084bc:0x203b6a0.
sent [IPCP ConfReq id=0x3]
Timeout 0x20084bc:0x203b6a0 in 3 seconds.
sent [IPCP ConfReq id=0x3]
Timeout 0x20084bc:0x203b6a0 in 3 seconds.
rcvd [IPCP ConfAck id=0x3]
Untimeout 0x20084bc:0x203b6a0.
ipcp: up
Could not determine local IP address
ipcp: down
sent [IPCP TermReq id=0x4 "Could not determine local IP address"]
Timeout 0x20084bc:0x203b6a0 in 3 seconds.
Modem hangup
Untimeout 0x20084bc:0x203b6a0.
CCP: Down event in state 1!
Connection terminated.
Connect time 0.4 minutes.
Sent 167 bytes, received 48 bytes.
Anyone any ideas?
Olaf Müller-Michaels
James Carlson
> Untimeout 0x20084bc:0x203b440.
It looks like you might have compiled the 'pppd' program with one of
the debugging #defines enabled. Don't do that.
> rcvd [IPCP ConfReq id=0x1]
The peer is claiming not to know his IP address.
There are a couple of reasons this could be. One has to do with
brokenness in GPRS; search the net (google.com can be helpful) for
other references to this. (GPRS doesn't bother authenticating the
user until *AFTER* PAP is actually done and IPCP has started. It then
behaves very strangely indeed if the user doesn't have a valid
"profile" with the service.)
The other could just be a simple bug in the peer, which you could
correct by specifying an arbitrary set of addresses in your pppd
configuration -- e.g., "192.168.0.1:192.168.0.2". I doubt, though,
that this will really fix the problem.
--
James Carlson, Solaris Networking <james.d...@sun.com>
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677
Olaf Müller-Michaels
since my Zaurus is in the office. One additional remark, I have no problems
connecting via a Palm Tungsten T using the following minimum settings:
Dial-up number: *99***2#
User: eplus
Pass: internet (or anything else)
DNS: [E-Plus DNS Server]
What would a comparable setup for pppd?
Also, I have not entered anything into PAP.secrets, my user and pass are
only in CHAP.secrets. Might that be the problem?
Olaf
"James Carlson" <james.d...@sun.com> schrieb im Newsbeitrag
news:xoav3cid...@sun.com...
Clifford Kite
> Thanks for your quick response. Have not had the chance to try further,
> since my Zaurus is in the office. One additional remark, I have no problems
> connecting via a Palm Tungsten T using the following minimum settings:
> Dial-up number: *99***2#
> User: eplus
> Pass: internet (or anything else)
> DNS: [E-Plus DNS Server]
> What would a comparable setup for pppd?
Probably the exact same settings as you now have, except with a line
such as
eplus * internet
in pap-secrets and the pppd option "user eplus".
> Also, I have not entered anything into PAP.secrets, my user and pass are
> only in CHAP.secrets. Might that be the problem?
Since it seems many GPRS PPP implementations are broken it very well
could be the problem. That would easy to determine by putting the
same line as is in your chap-secrets into pap-secrets.
--
Clifford Kite Email: "echo xvgr_yv...@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* For every credibility gap, there is a gullibility fill.
-- R. Clopton */
Olaf Müller-Michaels
ping any computer on the internet. The output of my debug is as
follows:
"abort on (NO CARRIER)
abort on (NO DIALTONE)
abort on (BUSY)
send (ATZ^M)
expect (OK)
ATZ^M^M
OK
-- got it
send (ATD*99***2#^M)
expect (CONNECT)
^M
ATD*99***2#^M^M
CONNECT
-- got it
Serial connection established.
using channel 2
Using interface ppp0
Connect: ppp0 <--> /dev/bty0
Warning - secret file /etc/ppp/pap-secrets has world and/or group
access
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3e1cce08> <pcomp>
<accomp>]
Timeout 0x20084bc:0x203b440 in 3 seconds.
rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <pcomp> <accomp> <auth pap>]
lcp_reqci: returning CONFACK.
sent [LCP ConfAck id=0x1 <asyncmap 0x0> <pcomp> <accomp> <auth pap>]
rcvd [LCP ConfRej id=0x1 <magic 0x3e1cce08>]
Untimeout 0x20084bc:0x203b440.
sent [LCP ConfReq id=0x2 <asyncmap 0x0> <pcomp> <accomp>]
Timeout 0x20084bc:0x203b440 in 3 seconds.
rcvd [LCP ConfAck id=0x2 <asyncmap 0x0> <pcomp> <accomp>]
Untimeout 0x20084bc:0x203b440.
Warning - secret file /etc/ppp/pap-secrets has world and/or group
access
sent [PAP AuthReq id=0x1 user="eplus" password=<hidden>]
Timeout 0x200ebbc:0x203b6e0 in 3 seconds.
sent [PAP AuthReq id=0x2 user="eplus" password=<hidden>]
Timeout 0x200ebbc:0x203b6e0 in 3 seconds.
rcvd [PAP AuthAck id=0x2 ""]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3
0.0.0.0>]
Timeout 0x20084bc:0x203b6a0 in 3 seconds.
sent [CCP ConfReq id=0x1 <bsd v1 15>]
Timeout 0x20084bc:0x203b7a0 in 3 seconds.
rcvd [LCP ProtRej id=0x3 80 fd 01 01 00 07 15 03 2f]
Untimeout 0x20084bc:0x203b7a0.
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3
0.0.0.0>]
Timeout 0x20084bc:0x203b6a0 in 3 seconds.
rcvd [IPCP ConfReq id=0x1 <addr 10.129.39.187>]
ipcp: returning Configure-ACK
sent [IPCP ConfAck id=0x1 <addr 10.129.39.187>]
rcvd [IPCP ConfNak id=0x1 <addr 10.129.39.187> <ms-dns1 212.23.98.2>
<ms-dns3 212.23.97.2>]
Untimeout 0x20084bc:0x203b6a0.
sent [IPCP ConfReq id=0x2 <addr 10.129.39.187> <ms-dns1 212.23.98.2>
<ms-dns3 212.23.97.2>]
Timeout 0x20084bc:0x203b6a0 in 3 seconds.
rcvd [IPCP ConfAck id=0x2 <addr 10.129.39.187> <ms-dns1 212.23.98.2>
<ms-dns3 212.23.97.2>]
Untimeout 0x20084bc:0x203b6a0.
ipcp: up
local IP address 10.129.39.187
remote IP address 10.129.39.187
primary DNS address 212.23.98.2
secondary DNS address 212.23.97.2
Script /etc/ppp/ip-up started (pid 4145)
Script /etc/ppp/ip-up finished (pid 4145), status = 0x0
Terminating on signal 15.
ipcp: down
Untimeout 0x2013d0c:0x0.
Script /etc/ppp/ip-down started (pid 4170)
CCP: Down event in state 1!
sent [LCP TermReq id=0x3 "User request"]
Timeout 0x20084bc:0x203b440 in 3 seconds.
rcvd [LCP TermAck id=0x3]
Untimeout 0x20084bc:0x203b440.
Connection terminated.
Connect time 11.5 minutes.
Sent 2888 bytes, received 54 bytes.
Waiting for 1 child processes...
script /etc/ppp/ip-down, pid 4170
Script /etc/ppp/ip-down finished (pid 4170), status = 0x0"
Strange that the IP addresses for the local and the remote host are
the same ...
"local IP address 10.129.39.187
remote IP address 10.129.39.187"
Clifford Kite <ki...@see.signature.id> wrote in message news:<ghpfcb...@corncob.inetport.com>...
Clifford Kite
> sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3
> 0.0.0.0>]
> Timeout 0x20084bc:0x203b6a0 in 3 seconds.
> rcvd [IPCP ConfReq id=0x1 <addr 10.129.39.187>]
You send a Configure-Request that tells the peer you want it to supply
your IP address (as well as DNS IP addresses).
The peer sent a Configure-Request to use 10.129.39.187 as it's IP address
for the PPP link.
> ipcp: returning Configure-ACK
> sent [IPCP ConfAck id=0x1 <addr 10.129.39.187>]
You Ack the peer's requested IP address.
> rcvd [IPCP ConfNak id=0x1 <addr 10.129.39.187> <ms-dns1 212.23.98.2>
> <ms-dns3 212.23.97.2>]
The peer Naks 0.0.0.0, as it is expected to do, and supplies the
same IP address as it requested for itself, which is *not* what it
is expected to do. This appears to be an example of the broken GPRS
PPP implementations or configurations.
> Untimeout 0x20084bc:0x203b6a0.
> sent [IPCP ConfReq id=0x2 <addr 10.129.39.187> <ms-dns1 212.23.98.2>
> <ms-dns3 212.23.97.2>]
> Timeout 0x20084bc:0x203b6a0 in 3 seconds.
> rcvd [IPCP ConfAck id=0x2 <addr 10.129.39.187> <ms-dns1 212.23.98.2>
> <ms-dns3 212.23.97.2>]
You request the IP address the peer suggested, along with the DNS IP
addresses it suggested, and the peer Acks your request.
I would have to go along with James Carlson's suggestion for the pppd
IP address option, but use the form
Note that no IP address follows the ":" which tells the peer to supply
it's own IP address (which it did above).
This is guesswork on my part. I suspect that it doesn't make much
difference what IP address pppd requests as long as it's a reserved
IP address (not routable) and not the peer's IP address, or perhaps
not in the same address space as the IP address of the peer.
If this doesn't work then I'm out of suggestions and someone else here
will need to step in, or it might be possible to get a hint of what to
do from the Internet access provider. I know very little about how GPRS
uses PPP negotiations or links to provide Internet access.
--
Clifford Kite Email: "echo xvgr_yv...@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." Benjamin Franklin */