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

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.2817:34:4399102
00 0F "..."
PPP!DATA[DI]212.4.2817:34:4399161
74 2B 63 73 6F 3D 31 32 61 74 23 37 37 37
"at+cso=12at#777"
PPP!DATA[DI]212.4.2817:34:4305101
00 25 "..%"
PPP!DATA[DI]212.4.2817:34:430517E
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.2817:34:4305102
00 25 "..%"
PPP!DATA[DI]212.4.2817:34:430517E
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.2817:34:4311101
00 25 "..%"
PPP!DATA[DI]212.4.2817:34:431117E
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.2817:34:4311102
00 25 "..%"
PPP!DATA[DI]212.4.2817:34:431117E
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.2817:34:4317101
00 22 "..""
PPP!DATA[DI]212.4.2817:34:431717E
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.2817:34:4317102
00 14 "..."
PPP!DATA[DI]212.4.2817:34:431717E
80 21 01 01 1C 03 06 02 06 2D 03 01 81 06 83 06 AD 24 7E
"~€!.......-....ƒ..$~"
PPP!DATA[DI]212.4.2817:34:4717101
00 22 "..""
PPP!DATA[DI]212.4.2817:34:471717E
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.2817:34:4717102
00 14 "..."
PPP!DATA[DI]212.4.2817:34:471717E
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

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

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

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

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 !