04-22-04 05:41 PM
Justin Kirby <zion@0penaether.0rg> wrote:
> real close now...
> Clifford Kite wrote:
> Well, I started pppd and it dropped into the 'loop', so I went to make
> coffee, ran some errands, and when I came back it was still doing it. So
> that classifies as 'forever' for me ;)
Ah, yes. That's close enough.  Thanks, I'll report the bug on the
Linux PPP mailing list and hope it gets fixed.
[vbcol=seagreen]
> woo hoo, this did some magic for me, thnx! This is as far as I have ever
> gotten. More debug output, this looks to be a bit of more automagic
> (i.e. more of my ignorance)
Actually the ipcp-no* options are recent additions to pppd. I half-way
suspect that it is due in part to a question about the option noip that
I posted on the Linux PPP mailing list.
> debug output:
> pppd call gprs
> AT
> OK
> ATE1
> OK
> AT+cgdcont=1,"IP","wap.cingular"
> OK
> ATDT*99***1#
> CONNECT
> Serial connection established.
> using channel 2
> Using interface ppp0
> Connect: ppp0 <--> /dev/rfcomm0
> sent [LCP ConfReq id=0x1 <asyncmap 0x0> <pcomp> <accomp>]
> rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <pcomp> <accomp> <auth pap>]
> sent [LCP ConfAck id=0x1 <asyncmap 0x0> <pcomp> <accomp> <auth pap>]
> rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <pcomp> <accomp>]
> sent [LCP EchoReq id=0x0 magic=0x0]
> sent [PAP AuthReq id=0x1 user="helium" password=<hidden>]
> rcvd [LCP CodeRej id=0x3 09 00 00 08 00 00 00 00]
> LCP: Rcvd Code-Reject for code 9, id 0
> rcvd [PAP AuthAck id=0x1 ""]
> PAP authentication succeeded
> sent [IPCP ConfReq id=0x1]
> rcvd [IPCP ConfReq id=0x1]
> sent [IPCP ConfAck id=0x1]
> rcvd [IPCP ConfAck id=0x1]
> Could not determine remote IP address: defaulting to 10.64.64.64
> Cannot determine ethernet address for proxy ARP
> local IP address 192.168.1.99
> remote IP address 10.64.64.64
This looks semi-right, the local IP address is the one that the peer
requested you use. The remote IP address is a default served up by pppd
because none was negotiated for the peer, but that doesn't really matter.
You do need to make sure there exists a PPP default route with gateway
(gw) 10.64.64.64 by using "route -n" .
> Script /etc/ppp/ip-up started (pid 1081)
> Script /etc/ppp/ip-up finished (pid 1081), status = 0x0
> No response to 4 echo-requests
> Serial link appears to be disconnected.
> Script /etc/ppp/ip-down started (pid 1120)
> sent [LCP TermReq id=0x2 "Peer not responding"]
> Script /etc/ppp/ip-down finished (pid 1120), status = 0x1
> rcvd [LCP TermReq id=0x2 "Peer not responding"]
> sent [LCP TermAck id=0x2]
> rcvd [LCP TermAck id=0x2]
Pppd initiated link termination because it got no response to the
PPP echo-requests it had send. The option(s) for echo-request and
echo-reply are likely configured in the file /etc/ppp/peers/gprs,
including the option
lcp-echo-interval <n>
where <n> is an integer representing the time between echo-requests.
Try commenting out this as well as any other option there with echo in
the name. The pppd man pages explain the PPP echo-request options.
> Connection terminated.
> Connect time 2.1 minutes.
> Sent 112 bytes, received 60 bytes.
> current /etc/ppp/peers/gprs
> /dev/rfcomm0 57600
> connect '/usr/sbin/chat -t 80 -v -f /etc/ppp/peers/chat-gprs'
> nomagic
> noccp
> ipcp-no-address
> ipcp-no-addresses
> novj
> defaultroute
> debug
> nodetach
--
Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* Better is the enemy of good enough. */
[ Post a follow-up to this message ]
| 
