|
Home > Archive > PPP > April 2004 > pppd over bluetooth broke?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
pppd over bluetooth broke?
|
|
| Justin Kirby 2004-04-21, 10:39 am |
| 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
| |
| Clifford Kite 2004-04-21, 12:37 pm |
| Justin Kirby <zion@0penaether.0rg> wrote:
> 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
Many comments below are not related to the problem (NPR), but
will simplify negotiations by disallowing requesting default pppd
implementation options that the peer has rejected.
> 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>]
Add the pppd option nomagic. NPR.
> 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
Strange, since pppd didn't request the code 9 option in any LCP request.
> 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>]
^ This appears to be the beginning of the problem. ^
> rcvd [LCP ProtRej id=0x4 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
Add the pppd option noccp. NPR.
> rcvd [IPCP ConfReq id=0x1]
The peer requests IPCP but without options.
> 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]
After some negotiation, pppd accepts the peer's request for IPCP without
options.
> 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
Forever is relative. It should stop all negotiation after 10 such
requests. Or there may be a bug in the code that negotiates the
(old) IP addresses option.
In any case, pppd keeps trying to get an IP address for itself even
though it's request for that IPCP option is rejected. I'd consider
that a (second?) bug.
I *think* these additional pppd options will correct the IPCP negotiation
problems, provided that you are using pppd 2.4.2:
ipcp-no-address
ipcp-no-addresses
novj
Note that the first two are not in the pppd man pages although they
are mentioned in the README file in the top pppd source tree. The last
option isn't really necessary but eliminates useless VJ negotiation.
BTW, be aware that I haven't ever done this..
--
Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* The generation of random numbers is too important to be left
to chance. */
| |
| Justin Kirby 2004-04-22, 1:39 am |
| real close now...
Clifford Kite wrote:
>
>
> Forever is relative. It should stop all negotiation after 10 such
> requests. Or there may be a bug in the code that negotiates the
> (old) IP addresses option.
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 ;)
> I *think* these additional pppd options will correct the IPCP negotiation
> problems, provided that you are using pppd 2.4.2:
>
> ipcp-no-address
> ipcp-no-addresses
> novj
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)
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
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]
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 2004-04-22, 12: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. */
|
|
|
|
|