Problem with IPCP part of PPP on CDMA access, Palm OS5 device - PPP

This is a discussion on Problem with IPCP part of PPP on CDMA access, Palm OS5 device - PPP ; I am trying to access via PPP on a CDMA network with a Palm device with OS5, and receiving a constant error. I donīt know how to solve this problem, thanks in advance for any help. Palm traces shows this: ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Problem with IPCP part of PPP on CDMA access, Palm OS5 device

  1. Problem with IPCP part of PPP on CDMA access, Palm OS5 device

    I am trying to access via PPP on a CDMA network with a Palm device
    with OS5, and receiving a constant error. I donīt know how to solve
    this problem, thanks in advance for any help.

    Palm traces shows this:

    Connect Log
    S:at+cso=12
    S:atdt#777
    S:^M
    LCP->CfgReq
    LCP->CfgReq
    LCP<-CfgReq
    LCP->CfgAck
    LCP<-CfgAck
    LCP Up
    IPCP->CfgReq
    IPCP->CfgReq
    IPCP->CfgReq
    IPCP->CfgReq
    IPCP->CfgReq
    IPCP->CfgReq
    IPCP->CfgReq
    IPCP->CfgReq
    IPCP->TrmReq
    LCP->Trmreq
    LCP<-Trmreq
    LCP->TrmAck
    LCP<-TrmAck

    Not Connected

    It seemed that no replies on IPCP, but after some research, I found
    that there was reply but packets received were possible malformed, so
    Palm reject them without showing on LOG.
    So I traced all communication with debugger and converted to Ethereal
    format to debug. What is constant that all IPCP requests receives
    same answer:

    Traces of first 8 frames:

    Frame 1 (20 bytes on wire, 20 bytes captured)
    Arrival Time: May 10, 2004 11:46:19.000000000
    Time delta from previous packet: 0.000000000 seconds
    Time since reference or first frame: 0.000000000 seconds
    Frame Number: 1
    Packet Length: 20 bytes
    Capture Length: 20 bytes
    Point-to-Point Direction: Sent (0)
    Point-to-Point Protocol
    Address: 0xff
    Control: 0x03
    Protocol: Link Control Protocol (0xc021)
    PPP Link Control Protocol

    Frame 2 (20 bytes on wire, 20 bytes captured)
    Arrival Time: May 10, 2004 11:46:19.000000000
    Time delta from previous packet: 0.000000000 seconds
    Time since reference or first frame: 0.000000000 seconds
    Frame Number: 2
    Packet Length: 20 bytes
    Capture Length: 20 bytes
    Point-to-Point Direction: Received (1)
    Point-to-Point Protocol
    Address: 0xff
    Control: 0x03
    Protocol: Link Control Protocol (0xc021)
    PPP Link Control Protocol

    Frame 3 (20 bytes on wire, 20 bytes captured)
    Arrival Time: May 10, 2004 11:46:19.000000000
    Time delta from previous packet: 0.000000000 seconds
    Time since reference or first frame: 0.000000000 seconds
    Frame Number: 3
    Packet Length: 20 bytes
    Capture Length: 20 bytes
    Point-to-Point Direction: Sent (0)
    Point-to-Point Protocol
    Address: 0xff
    Control: 0x03
    Protocol: Link Control Protocol (0xc021)
    PPP Link Control Protocol

    Frame 4 (20 bytes on wire, 20 bytes captured)
    Arrival Time: May 10, 2004 11:46:19.000000000
    Time delta from previous packet: 0.000000000 seconds
    Time since reference or first frame: 0.000000000 seconds
    Frame Number: 4
    Packet Length: 20 bytes
    Capture Length: 20 bytes
    Point-to-Point Direction: Received (1)
    Point-to-Point Protocol
    Address: 0xff
    Control: 0x03
    Protocol: Link Control Protocol (0xc021)
    PPP Link Control Protocol

    Frame 5 (32 bytes on wire, 32 bytes captured)
    Arrival Time: May 10, 2004 11:46:20.000000000
    Time delta from previous packet: 1.000000000 seconds
    Time since reference or first frame: 1.000000000 seconds
    Frame Number: 5
    Packet Length: 32 bytes
    Capture Length: 32 bytes
    Point-to-Point Direction: Sent (0)
    Point-to-Point Protocol
    Protocol: IP Control Protocol (0x8021)
    PPP IP Control Protocol
    Code: Configuration Request (0x01)
    Identifier: 0x15
    Length: 28
    Options: (24 bytes)
    IP address: 0.0.0.0
    IP compression protocol: 6 bytes
    IP compression protocol: VJ compressed TCP (0x2d)
    Data (2 bytes)
    Primary DNS server IP address: 0.0.0.0
    Secondary DNS server IP address: 0.0.0.0

    Frame 6 (18 bytes on wire, 18 bytes captured)
    Arrival Time: May 10, 2004 11:46:20.000000000
    Time delta from previous packet: 0.000000000 seconds
    Time since reference or first frame: 1.000000000 seconds
    Frame Number: 6
    Packet Length: 18 bytes
    Capture Length: 18 bytes
    Point-to-Point Direction: Received (1)
    Point-to-Point Protocol
    Protocol: IP Control Protocol (0x8021)
    PPP IP Control Protocol
    Code: Configuration Request (0x01)
    Identifier: 0x15
    Length: 7171
    Options: (7167 bytes)
    Unknown (0x06) (2 bytes)
    Unknown (0x06) (45 bytes)
    [Malformed Packet: PPP IPCP]

    Frame 7 (32 bytes on wire, 32 bytes captured)
    Arrival Time: May 10, 2004 11:46:23.000000000
    Time delta from previous packet: 3.000000000 seconds
    Time since reference or first frame: 4.000000000 seconds
    Frame Number: 7
    Packet Length: 32 bytes
    Capture Length: 32 bytes
    Point-to-Point Direction: Sent (0)
    Point-to-Point Protocol
    Protocol: IP Control Protocol (0x8021)
    PPP IP Control Protocol
    Code: Configuration Request (0x01)
    Identifier: 0x16
    Length: 28
    Options: (24 bytes)
    IP address: 0.0.0.0
    IP compression protocol: 6 bytes
    IP compression protocol: VJ compressed TCP (0x2d)
    Data (2 bytes)
    Primary DNS server IP address: 0.0.0.0
    Secondary DNS server IP address: 0.0.0.0

    Frame 8 (18 bytes on wire, 18 bytes captured)
    Arrival Time: May 10, 2004 11:46:23.000000000
    Time delta from previous packet: 0.000000000 seconds
    Time since reference or first frame: 4.000000000 seconds
    Frame Number: 8
    Packet Length: 18 bytes
    Capture Length: 18 bytes
    Point-to-Point Direction: Received (1)
    Point-to-Point Protocol
    Protocol: IP Control Protocol (0x8021)
    PPP IP Control Protocol
    Code: Configuration Request (0x01)
    Identifier: 0x16
    Length: 7171
    Options: (7167 bytes)
    Unknown (0x06) (2 bytes)
    Unknown (0x06) (45 bytes)
    [Malformed Packet: PPP IPCP]

    .... and continues until timeout

    DCE to DTE packet malformed package is as follows:

    0000 80 21 01 16 1c 03 06 02 06 2d 03 01 81 06 83 06
    0010 91 9f

    ================================================== =========================


    I supposed that VJ compression was the cause, but malformed packages
    keep coming on same place.

    ......

    Frame 46 (26 bytes on wire, 26 bytes captured)
    Arrival Time: May 10, 2004 12:49:51.000000000
    Time delta from previous packet: 0.000000000 seconds
    Time since reference or first frame: 3812.000000000 seconds
    Frame Number: 46
    Packet Length: 26 bytes
    Capture Length: 26 bytes
    Point-to-Point Direction: Sent (0)
    Point-to-Point Protocol
    Protocol: IP Control Protocol (0x8021)
    PPP IP Control Protocol
    Code: Configuration Request (0x01)
    Identifier: 0x03
    Length: 22
    Options: (18 bytes)
    IP address: 0.0.0.0
    Primary DNS server IP address: 0.0.0.0
    Secondary DNS server IP address: 0.0.0.0

    Frame 47 (13 bytes on wire, 13 bytes captured)
    Arrival Time: May 10, 2004 12:49:51.000000000
    Time delta from previous packet: 0.000000000 seconds
    Time since reference or first frame: 3812.000000000 seconds
    Frame Number: 47
    Packet Length: 13 bytes
    Capture Length: 13 bytes
    Point-to-Point Direction: Received (1)
    Point-to-Point Protocol
    Protocol: IP Control Protocol (0x8021)
    PPP IP Control Protocol
    Code: Configuration Request (0x01)
    Identifier: 0x03
    Length: 5635
    Options: (5631 bytes)
    Unknown (0x06) (129 bytes)
    [Malformed Packet: PPP IPCP]

    .........


    Any ideas ??

  2. Re: Problem with IPCP part of PPP on CDMA access, Palm OS5 device

    groups@guia-mercosur.com (Rob) writes:
    > It seemed that no replies on IPCP, but after some research, I found
    > that there was reply but packets received were possible malformed, so
    > Palm reject them without showing on LOG.
    > So I traced all communication with debugger and converted to Ethereal
    > format to debug. What is constant that all IPCP requests receives
    > same answer:


    As is often the case (*sigh*), the omitted parts look like the crucial
    ones.

    I suspect that LCP is negotiating an ACCM that isn't actually
    supported by both peers.

    > PPP IP Control Protocol
    > Code: Configuration Request (0x01)
    > Identifier: 0x15
    > Length: 7171
    > Options: (7167 bytes)
    > Unknown (0x06) (2 bytes)
    > Unknown (0x06) (45 bytes)
    > [Malformed Packet: PPP IPCP]


    That looks pretty garbled. There's nothing you can do about this at
    this level.

    > DCE to DTE packet malformed package is as follows:
    >
    > 0000 80 21 01 16 1c 03 06 02 06 2d 03 01 81 06 83 06
    > 0010 91 9f


    That can't possibly be a valid packet. It looks like it got garbled
    in transmission.

    > I supposed that VJ compression was the cause, but malformed packages
    > keep coming on same place.


    No. It can't be VJ compression. VJ compression affects only data
    packets. You're still in IPCP negotiation. There are no data packets
    here.

    The problem is lower in the stack -- it's either LCP negotiation or
    some sort of hardware trouble. Or the "interesting" mechanism that
    exports data for ethereal is itself malfunctioning ...

    --
    James Carlson, IP Systems Group
    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

  3. Re: Problem with IPCP part of PPP on CDMA access, Palm OS5 device

    James Carlson wrote in message news:...
    > groups@guia-mercosur.com (Rob) writes:
    > > It seemed that no replies on IPCP, but after some research, I found
    > > that there was reply but packets received were possible malformed, so
    > > Palm reject them without showing on LOG.
    > > So I traced all communication with debugger and converted to Ethereal
    > > format to debug. What is constant that all IPCP requests receives
    > > same answer:

    >
    > As is often the case (*sigh*), the omitted parts look like the crucial
    > ones.
    >
    > I suspect that LCP is negotiating an ACCM that isn't actually
    > supported by both peers.
    >
    > > PPP IP Control Protocol
    > > Code: Configuration Request (0x01)
    > > Identifier: 0x15
    > > Length: 7171
    > > Options: (7167 bytes)
    > > Unknown (0x06) (2 bytes)
    > > Unknown (0x06) (45 bytes)
    > > [Malformed Packet: PPP IPCP]

    >
    > That looks pretty garbled. There's nothing you can do about this at
    > this level.
    >
    > > DCE to DTE packet malformed package is as follows:
    > >
    > > 0000 80 21 01 16 1c 03 06 02 06 2d 03 01 81 06 83 06
    > > 0010 91 9f

    >
    > That can't possibly be a valid packet. It looks like it got garbled
    > in transmission.
    >
    > > I supposed that VJ compression was the cause, but malformed packages
    > > keep coming on same place.

    >
    > No. It can't be VJ compression. VJ compression affects only data
    > packets. You're still in IPCP negotiation. There are no data packets
    > here.
    >
    > The problem is lower in the stack -- it's either LCP negotiation or
    > some sort of hardware trouble. Or the "interesting" mechanism that
    > exports data for ethereal is itself malfunctioning ...



    Thanks for your fast reply!

    I think that export mechanism to Ethereal should be fine. I did other
    trial debugs on connections from Palm using direct cable to a PC and
    worked fine with the trace of all PPP success connection.

    But maybe the original dump trace will help to check:
    I extracted the same parts as posted before and added one more IPCP
    retry:



    PPP!DATA[DI]212.4.2899102
    00 0F "..."

    PPP!DATA[DI]212.4.2899161
    74 2B 63 73 6F 3D 31 32 61 74 23 37 37 37
    "at+cso=12at#777"

    PPP!DATA[DI]212.4.2805101
    00 25 "..%"

    PPP!DATA[DI]212.4.280517E
    FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 20 7D 20
    7D 20 7D 27 7D 22 7D 28 7D 22 70 34 7E "~.}#.!}!}!} }.}"}&}
    } } } }'}"}(}"p4~"

    PPP!DATA[DI]212.4.2805102
    00 25 "..%"

    PPP!DATA[DI]212.4.280517E
    FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 20 7D 20
    7D 20 7D 27 7D 22 7D 28 7D 22 70 34 7E "~.}#.!}!}!} }.}"}&}
    } } } }'}"}(}"p4~"

    PPP!DATA[DI]212.4.2811101
    00 25 "..%"

    PPP!DATA[DI]212.4.281117E
    FF 7D 23 C0 21 7D 22 7D 21 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 20 7D 20
    7D 20 7D 27 7D 22 7D 28 7D 22 4E B7 7E "~.}#.!}"}!}
    }.}"}&} } } } }'}"}(}"N.~"

    PPP!DATA[DI]212.4.2811102
    00 25 "..%"

    PPP!DATA[DI]212.4.281117E
    FF 7D 23 C0 21 7D 22 7D 21 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 20 7D 20
    7D 20 7D 27 7D 22 7D 28 7D 22 4E B7 7E "~.}#.!}"}!}
    }.}"}&} } } } }'}"}(}"N.~"

    PPP!DATA[DI]212.4.2817101
    00 22 "..""

    PPP!DATA[DI]212.4.281717E
    80 21 01 01 00 1C 03 06 00 00 00 00 02 06 00 2D 03 01 81 06 00 00 00
    00 83 06 00 00 00 00 AD 24 7E
    "~€!.............-........ƒ......$~"

    PPP!DATA[DI]212.4.2817102
    00 14 "..."

    PPP!DATA[DI]212.4.281717E
    80 21 01 01 1C 03 06 02 06 2D 03 01 81 06 83 06 AD 24 7E
    "~€!.......-....ƒ..$~"

    PPP!DATA[DI]212.4.2817101
    00 22 "..""

    PPP!DATA[DI]212.4.281717E
    80 21 01 02 00 1C 03 06 00 00 00 00 02 06 00 2D 03 01 81 06 00 00 00
    00 83 06 00 00 00 00 75 D2 7E
    "~€!.............-........ƒ.....u.~"

    PPP!DATA[DI]212.4.2817102
    00 14 "..."

    PPP!DATA[DI]212.4.281717E
    80 21 01 02 1C 03 06 02 06 2D 03 01 81 06 83 06 75 D2 7E
    "~€!.......-....ƒ.u.~"



    ================================================== ============================

    Other questions, remember I have poor experience in PPP....

    Why LCP seems to be negociated with no malformed received packages?
    and
    Why should be the possible cause, that IPCP portion always receives
    from wireless connection same error?

    Thanks again

    Rob

  4. Re: Problem with IPCP part of PPP on CDMA access, Palm OS5 device

    groups@guia-mercosur.com (Rob) writes:
    > But maybe the original dump trace will help to check:
    > I extracted the same parts as posted before and added one more IPCP
    > retry:


    If what you're posting is a binary file (and that's what this _seems_
    to be -- there are non-ASCII characters in it, and ethereal doesn't
    seem to understand its contents), please use uuencode or base64
    encoding when posting to netnews.

    I can't tell (from the data provided) who is sending or receiving
    here, but I'll take a crack at decoding it manually.

    > FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 20 7D 20
    > 7D 20 7D 27 7D 22 7D 28 7D 22 70 34 7E "~.}#.!}!}!} }.}"}&}


    That decodes as:

    FF 03 - Address and control
    C0 21 - Protocol LCP
    01 - Configure-Request
    01 - ID
    00 0E - Length 14
    02 06 00 00 00 00
    - ACCM 00000000 (nothing escaped)
    07 02 - PFC
    08 02 - ACFC
    70 34 - FCS

    > FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 20 7D 20
    > 7D 20 7D 27 7D 22 7D 28 7D 22 70 34 7E "~.}#.!}!}!} }.}"}&}


    It looks like the peer is asking for *exactly* the same set of
    parameters.

    > FF 7D 23 C0 21 7D 22 7D 21 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 20 7D 20
    > 7D 20 7D 27 7D 22 7D 28 7D 22 4E B7 7E "~.}#.!}"}!}


    That's:

    FF 03 - Address and Control
    C0 21 - LCP
    02 - Configure-Ack
    01 - ID
    00 0E - Length
    02 06 00 00 00 00
    07 02
    08 02
    4E B7

    Looks like the peer has agreed to those parameters.

    > FF 7D 23 C0 21 7D 22 7D 21 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 20 7D 20
    > 7D 20 7D 27 7D 22 7D 28 7D 22 4E B7 7E "~.}#.!}"}!}


    And the peer (presumably) agrees. LCP is done here.

    > 80 21 01 01 00 1C 03 06 00 00 00 00 02 06 00 2D 03 01 81 06 00 00 00
    > 00 83 06 00 00 00 00 AD 24 7E


    That's:

    80 21 - Protocol IPCP
    01 - Configure-Request
    01 - ID
    00 1C - Length 28
    03 06 00 00 00 00
    - IP-Address 0.0.0.0
    02 06 00 2D 03 01
    - VJ Compression, max slot 3, compressed IDs
    81 06 00 00 00 00
    - MS DNS server address request
    83 06 00 00 00 00
    - MS DNS server address request
    AD 24 - FCS

    That looks fine to me.

    > 80 21 01 01 1C 03 06 02 06 2D 03 01 81 06 83 06 AD 24 7E


    That's completely garbled. Your serial link is somehow dropping NUL
    (value 00) bytes out of the datastream. You have either broken
    hardware or software.

    One way to get around this (other than finding the root cause of the
    problem with your hardware or software) would be to set the ACCM to
    00000001 so that the NUL byte is always escaped. How that's done on
    the implementations you're using, I don't know. (It would be
    "asyncmap 00000001" on pppd ... but you're not using pppd, are you?)

    > Other questions, remember I have poor experience in PPP....
    >
    > Why LCP seems to be negociated with no malformed received packages?


    Because it negotiates with the default parameters, which include an
    ACCM (Async Control Character Map) of FFFFFFFF -- meaning that all
    control characters are escaped by default. It then negotiates this
    away.

    The symptoms you have are absolutely classic: LCP works, then all else
    fails. The ACCM is wrong.

    > and
    > Why should be the possible cause, that IPCP portion always receives
    > from wireless connection same error?


    That's not the problem. It's merely a symptom.

    --
    James Carlson, IP Systems Group
    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

  5. Re: Problem with IPCP part of PPP on CDMA access, Palm OS5 device

    James Carlson wrote in message news:...

    .....
    > That's completely garbled. Your serial link is somehow dropping NUL
    > (value 00) bytes out of the datastream. You have either broken
    > hardware or software.
    >
    > One way to get around this (other than finding the root cause of the
    > problem with your hardware or software) would be to set the ACCM to
    > 00000001 so that the NUL byte is always escaped. How that's done on
    > the implementations you're using, I don't know. (It would be
    > "asyncmap 00000001" on pppd ... but you're not using pppd, are you?)
    >
    > > Other questions, remember I have poor experience in PPP....
    > >
    > > Why LCP seems to be negociated with no malformed received packages?

    >
    > Because it negotiates with the default parameters, which include an
    > ACCM (Async Control Character Map) of FFFFFFFF -- meaning that all
    > control characters are escaped by default. It then negotiates this
    > away.
    >
    > The symptoms you have are absolutely classic: LCP works, then all else
    > fails. The ACCM is wrong.
    >
    > > and
    > > Why should be the possible cause, that IPCP portion always receives
    > > from wireless connection same error?

    >
    > That's not the problem. It's merely a symptom.



    Answer is very clear.

    I looked for some extra information Palm SDK info and says:

    ACCM PPP asynchronous characters map Defaults to 0x000A0000
    (XON/XOFF characters)

    Also I tried different speeds, from 9600 to 19200 with same results
    with flow control and without. No changes..
    I donīt think that it is a software problem, as stack is the same that
    I use with other working PPP connections (Wi-Fi, USB direct or
    Bluetooth).

    Maybe is a hardware fault, maybe a hidden parameter in CDMA wireless
    modem to work with this net. I will research in this area ...

    Thanks

    Rob

  6. Re: Problem with IPCP part of PPP on CDMA access, Palm OS5 device

    groups@guia-mercosur.com (Rob) writes:

    ]James Carlson wrote in message news:...

    ]....
    ]> That's completely garbled. Your serial link is somehow dropping NUL
    ]> (value 00) bytes out of the datastream. You have either broken
    ]> hardware or software.
    ]>
    ]> One way to get around this (other than finding the root cause of the
    ]> problem with your hardware or software) would be to set the ACCM to
    ]> 00000001 so that the NUL byte is always escaped. How that's done on
    ]> the implementations you're using, I don't know. (It would be
    ]> "asyncmap 00000001" on pppd ... but you're not using pppd, are you?)
    ]>
    ]> > Other questions, remember I have poor experience in PPP....
    ]> >
    ]> > Why LCP seems to be negociated with no malformed received packages?
    ]>
    ]> Because it negotiates with the default parameters, which include an
    ]> ACCM (Async Control Character Map) of FFFFFFFF -- meaning that all
    ]> control characters are escaped by default. It then negotiates this
    ]> away.
    ]>
    ]> The symptoms you have are absolutely classic: LCP works, then all else
    ]> fails. The ACCM is wrong.
    ]>
    ]> > and
    ]> > Why should be the possible cause, that IPCP portion always receives
    ]> > from wireless connection same error?
    ]>
    ]> That's not the problem. It's merely a symptom.


    ]Answer is very clear.

    ]I looked for some extra information Palm SDK info and says:

    ]ACCM PPP asynchronous characters map Defaults to 0x000A0000
    ](XON/XOFF characters)

    So why do you not change the parameters. Not sure how much control you
    have but choose the asyncmap to be A0001 instead.

    ]Maybe is a hardware fault, maybe a hidden parameter in CDMA wireless
    ]modem to work with this net. I will research in this area ...

    ]Thanks

    ] Rob


  7. Re: Problem with IPCP part of PPP on CDMA access, Palm OS5 device

    unruh@string.physics.ubc.ca (Bill Unruh) wrote in message news:...

    > ]I looked for some extra information Palm SDK info and says:
    >
    > ]ACCM PPP asynchronous characters map Defaults to 0x000A0000
    > ](XON/XOFF characters)
    >
    > So why do you not change the parameters. Not sure how much control you
    > have but choose the asyncmap to be A0001 instead.
    >
    > ]Maybe is a hardware fault, maybe a hidden parameter in CDMA wireless
    > ]modem to work with this net. I will research in this area ...
    >
    > ]Thanks
    >
    > ] Rob



    Not too much control On - Off - Automatic

    I tried them all same results.

    Thanks again !

+ Reply to Thread