I am trying to establish a ppp connection over bluetooth using T616. I
do have a successful bluetooth pairing. I get what looks like a
successful dial, but the IP address is what looks to be breaking it. I
have no idea where to go from here.
Any ideas would be greatly appreciated (I have been at this for 2wks)
Thnx
pppd debug output:
AT
OK
ATE1
OK
AT&f;+cgdcont=4,”IP”,”isp.cingular”
OK
ATDT*99***4#
CONNECT
Serial connection established.
using channel 2
Using interface ppp0
Connect: ppp0 <–> /dev/rfcomm0
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x54c39f64> <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 ConfRej id=0x1 <magic 0x54c39f64>]
sent [LCP ConfReq id=0x2 <asyncmap 0x0> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x2 <asyncmap 0x0> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0x0]
sent [PAP AuthReq id=0x1 user=”ISP@CINGULARGPRS.COM” 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 [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 192.168.1.99>]
rcvd [LCP ProtRej id=0x4 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
rcvd [IPCP ConfReq id=0x1]
sent [IPCP ConfNak id=0x1 <addr 0.0.0.0>]
rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01> <addr 192.168.1.99>]
sent [IPCP ConfReq id=0x2 <addrs 192.168.1.99 0.0.0.0>]
rcvd [IPCP ConfReq id=0x2 <addr 0.0.0.0>]
sent [IPCP ConfRej id=0x2 <addr 0.0.0.0>]
rcvd [IPCP ConfRej id=0x2 <addrs 192.168.1.99 0.0.0.0>]
sent [IPCP ConfReq id=0x3 <addrs 192.168.1.99 0.0.0.0>]
rcvd [IPCP ConfReq id=0x3]
sent [IPCP ConfAck id=0x3]
rcvd [IPCP ConfRej id=0x3 <addrs 192.168.1.99 0.0.0.0>]
sent [IPCP ConfReq id=0x4 <addrs 192.168.1.99 0.0.0.0>]
rcvd [IPCP ConfRej id=0x4 <addrs 192.168.1.99 0.0.0.0>]
sent [IPCP ConfReq id=0x5 <addrs 192.168.1.99 0.0.0.0>]
rcvd [IPCP ConfRej id=0x5 <addrs 192.168.1.99 0.0.0.0>]
sent [IPCP ConfReq id=0x6 <addrs 192.168.1.99 0.0.0.0>]
rcvd [IPCP ConfRej id=0x6 <addrs 192.168.1.99 0.0.0.0>]
……
repeats forever until I kill it
/etc/ppp/peers/gprs
/dev/rfcomm0 57600
connect ‘/usr/sbin/chat -t 80 -v -f /etc/ppp/peers/chat-gprs’
defaultroute
debug
nodetach
/etc/ppp/peers/chat-gprs
ECHO ON
ABORT ‘\nBUSY\r’
ABORT ‘\nERROR\r’
ABORT ‘\nNO ANSWER\r’
ABORT ‘\nNO CARRIER\r’
ABORT ‘\nNO DIALTONE\r’
ABORT ‘\nRINGING\r\n\r\nRINGING\r’
” \rAT
TIMEOUT 12
OK ATE1
OK AT&f;+cgdcont=4,”IP”,”isp.cingular”
OK ATDT*99***4#
CONNECT
___________________________________________
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