pppd over bluetooth broke? - PPP

This is a discussion on pppd over bluetooth broke? - PPP ; 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 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: pppd over bluetooth broke?

  1. pppd over bluetooth broke?

    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 ]
    rcvd [LCP ConfReq id=0x1 ]
    sent [LCP ConfAck id=0x1 ]
    rcvd [LCP ConfRej id=0x1 ]
    sent [LCP ConfReq id=0x2 ]
    rcvd [LCP ConfAck id=0x2 ]
    sent [LCP EchoReq id=0x0 magic=0x0]
    sent [PAP AuthReq id=0x1 user="ISP@CINGULARGPRS.COM" password=]
    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 ]
    sent [IPCP ConfReq id=0x1 ]
    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 ]
    rcvd [IPCP ConfRej id=0x1 ]
    sent [IPCP ConfReq id=0x2 ]
    rcvd [IPCP ConfReq id=0x2 ]
    sent [IPCP ConfRej id=0x2 ]
    rcvd [IPCP ConfRej id=0x2 ]
    sent [IPCP ConfReq id=0x3 ]
    rcvd [IPCP ConfReq id=0x3]
    sent [IPCP ConfAck id=0x3]
    rcvd [IPCP ConfRej id=0x3 ]
    sent [IPCP ConfReq id=0x4 ]
    rcvd [IPCP ConfRej id=0x4 ]
    sent [IPCP ConfReq id=0x5 ]
    rcvd [IPCP ConfRej id=0x5 ]
    sent [IPCP ConfReq id=0x6 ]
    rcvd [IPCP ConfRej id=0x6 ]
    ......
    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

  2. Re: pppd over bluetooth broke?

    Justin Kirby 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 ]
    > rcvd [LCP ConfReq id=0x1 ]
    > sent [LCP ConfAck id=0x1 ]
    > rcvd [LCP ConfRej id=0x1 ]


    Add the pppd option nomagic. NPR.

    > sent [LCP ConfReq id=0x2 ]
    > rcvd [LCP ConfAck id=0x2 ]
    > sent [LCP EchoReq id=0x0 magic=0x0]
    > sent [PAP AuthReq id=0x1 user="ISP@CINGULARGPRS.COM" password=]
    > 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 ]
    > sent [IPCP ConfReq id=0x1 ]


    ^ 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 ]
    > rcvd [IPCP ConfRej id=0x1 ]
    > sent [IPCP ConfReq id=0x2 ]
    > rcvd [IPCP ConfReq id=0x2 ]
    > sent [IPCP ConfRej id=0x2 ]
    > rcvd [IPCP ConfRej id=0x2 ]
    > sent [IPCP ConfReq id=0x3 ]
    > 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 ]
    > sent [IPCP ConfReq id=0x4 ]
    > rcvd [IPCP ConfRej id=0x4 ]
    > sent [IPCP ConfReq id=0x5 ]
    > rcvd [IPCP ConfRej id=0x5 ]
    > sent [IPCP ConfReq id=0x6 ]
    > rcvd [IPCP ConfRej id=0x6 ]
    > .....
    > 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. */

  3. Re: pppd over bluetooth broke?

    real close now...

    Clifford Kite wrote:
    >>rcvd [IPCP ConfRej id=0x3 ]
    >>sent [IPCP ConfReq id=0x4 ]
    >>rcvd [IPCP ConfRej id=0x4 ]
    >>sent [IPCP ConfReq id=0x5 ]
    >>rcvd [IPCP ConfRej id=0x5 ]
    >>sent [IPCP ConfReq id=0x6 ]
    >>rcvd [IPCP ConfRej id=0x6 ]
    >>.....
    >>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.

    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 ]
    rcvd [LCP ConfReq id=0x1 ]
    sent [LCP ConfAck id=0x1 ]
    rcvd [LCP ConfAck id=0x1 ]
    sent [LCP EchoReq id=0x0 magic=0x0]
    sent [PAP AuthReq id=0x1 user="helium" password=]
    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

  4. Re: pppd over bluetooth broke?

    Justin Kirby wrote:
    > 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


    Ah, yes. That's close enough. Thanks, I'll report the bug on the
    Linux PPP mailing list and hope it gets fixed.

    >> 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)


    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 ]
    > rcvd [LCP ConfReq id=0x1 ]
    > sent [LCP ConfAck id=0x1 ]
    > rcvd [LCP ConfAck id=0x1 ]
    > sent [LCP EchoReq id=0x0 magic=0x0]
    > sent [PAP AuthReq id=0x1 user="helium" password=]
    > 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

    where 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. */

+ Reply to Thread