Re: Windows CE DUN problems

John Storms (jstorms@livingston.com)
Wed, 06 Aug 1997 16:47:20 -0700

At 02:32 PM 8/6/97 -0700, Jon Rust wrote:
>
>Here's the debug output. Also, if we hard code the name server IPs into
>his palmtop, it drops the connection almost immediately. Relying on the
>server assigned DNS, it just hangs in this halfway state for ever. Of
>course HP and M$ tech support tell the guy it's all my fault -- "Your ISP
>is having problems."
>
>Help?

>Sending LCP_PROTOCOL_REJECT to port S21 of 16 bytes containing:
>08 02 00 10 80 FD 01 01 00 0A 12 06 00 00 00 01
> Packet Info: Code: 08, ID: 02, 16 bytes.
> [0x80], length: (253 bytes), [0x0101000A120600000001]

/-LCP--------------\/-Rejected-Packet------------------\
[08][02][0010][80FD][[01][01][000A][12][06 00 00 00 01]]
| | | | | | | | |
| | | | | | | | Option Data
| | | | | ID | ?Microsoft PPC Compression?
| | | | | Length: 10 bytes
| | | | LCP Configure Request
| | | Protocol field: NCP layer->Compression Control Protocol (CCP)
| | Packet Length = 10 bytes
| ID
LCP Protocol Reject

RFC1313, page 7
Protocol field values in the "0---" to "3---" range identify the
network-layer protocol of specific datagrams, and values in the "8--
-" to "b---" range identify datagrams belonging to the associated
Network Control Protocols (NCPs), if any.

It looks like the remote host was trying to negotiate Microsoft PPC
Compression, this isn't support. STAC compression will be supported in the
next release of the ComOS. I'm not 100% certain that the [12] protocol
represents PPC. I dug that out of RFC 1962, but I'm short on time and
haven't been able to research it fully.

---
jstorms@livingston.com
Diplomacy:  The art of saying good doggie
while seaching for a big rock.