PPP connection from Pocket PC to Linux fails

I am trying to connect a Pocket PC (2005) to a linux box running pppd.
It starts out ok but then hte Pocket PC pops up a message that the
"answering modem has disconnected". From the pppd logs (see below) it
looks as if the client stops responding.

This is my pppd configuration:
dump
hide-password
noauth
/dev/ttyS3
57600
nodefaultroute
proxyarp
192.168.2.1:192.168.2.2
netmask 255.255.255.0
ms-dns x.x.x.x
ms-dns x.x.x.x
lock
asyncmap 0
logfile /tmp/pppDebug
linkname pda
connect "chat 'CLIENT' 'CLIENTSERVER\\c'"
nodetach
# HW flow control:
crtscts
# Non standard HW flow control (no DTR signaling):
#cdtrcts
# Disable HW flow control:
#nocrtscts
# Use SW flow control:
#xonxoff

(I have also tried using the options below but they don't make a
difference
lcp-echo-interval 5
lcp-echo-failure 5

I have set up the Pocket PC using XML provisioning so that I can
specify a direct connection (device type = "direct" device name =
"Serial Cable on COM1:"). I enable IP header and software compression,
baud rate 57600 8N1 etc.

This is the log file when I don't specify the IP address and DNS
servers on the client:

Trying to setdtr to 0.
setdtr to 0.
Serial connection established.
using channel 1
Using interface ppp0
Connect: ppp0 <--> /dev/ttyS3
rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <pcomp> <accomp>]
Warning - secret file /etc/ppp/pap-secrets has world and/or group
access
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x7c7c20dc> <pcomp>
<accomp>]
sent [LCP ConfAck id=0x0 <asyncmap 0x0> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x7c7c20dc> <pcomp>
<accomp>]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
rcvd [CCP ConfReq id=0x0 < 12 06 00 00 00 01>]
sent [CCP ConfReq id=0x1]
sent [CCP ConfRej id=0x0 < 12 06 00 00 00 01>]
rcvd [IPCP ConfReq id=0x0 <compress VJ 0f 00> <addr 0.0.0.0> <ms-dns1
0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
sent [IPCP ConfRej id=0x0 <ms-wins 0.0.0.0> <ms-wins 0.0.0.0>]
rcvd [proto=0x8057] 01 00 00 0e 01 0a 02 30 05 ff fe b6 3b 71
Unsupported protocol 0x8057 received
sent [LCP ProtRej id=0x2 80 57 01 00 00 0e 01 0a 02 30 05 ff fe b6 3b
71]
rcvd [IPCP ConfAck id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
************************************************** **********************************
* The client stops responding here and thinks that the linux box has
disconnected
* why????
************************************************** *************************************
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
CCP: timeout sending Config-Requests
IPCP: timeout sending Config-Requests
sent [LCP TermReq id=0x3 "No network protocols running"]
sent [LCP TermReq id=0x4 "No network protocols running"]
Connection terminated.

If I setup the client to know the IP address and DNS servers the IPCP
negotiation completes, but the client still stops responding at some
point and thinks the pppd server has disconnected:

Serial connection established.
using channel 1
Using interface ppp0
Connect: ppp0 <--> /dev/ttyS3
rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <pcomp> <accomp>]
Warning - secret file /etc/ppp/pap-secrets has world and/or group
access
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x6ef3eeed> <pcomp>
<accomp>]
sent [LCP ConfAck id=0x0 <asyncmap 0x0> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x6ef3eeed> <pcomp>
<accomp>]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
rcvd [CCP ConfReq id=0x0 < 12 06 00 00 00 01>]
sent [CCP ConfReq id=0x1]
sent [CCP ConfRej id=0x0 < 12 06 00 00 00 01>]
rcvd [IPCP ConfReq id=0x0 <compress VJ 0f 00> <addr 192.168.2.2>]
sent [IPCP ConfAck id=0x0 <compress VJ 0f 00> <addr 192.168.2.2>]
rcvd [proto=0x8057] 01 00 00 0e 01 0a 02 30 05 ff fe b6 3b 71
Unsupported protocol 0x8057 received
sent [LCP ProtRej id=0x2 80 57 01 00 00 0e 01 0a 02 30 05 ff fe b6 3b
71]
rcvd [IPCP ConfAck id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
local IP address 192.168.2.1
remote IP address 192.168.2.2
Script /etc/ppp/ip-up started (pid 202)
Script /etc/ppp/ip-up finished (pid 202), status = 0x0
sent [CCP ConfReq id=0x1]
sent [CCP ConfReq id=0x1]
sent [CCP ConfReq id=0x1]
sent [CCP ConfReq id=0x1]
sent [CCP ConfReq id=0x1]
sent [CCP ConfReq id=0x1]
sent [CCP ConfReq id=0x1]
sent [CCP ConfReq id=0x1]
sent [CCP ConfReq id=0x1]
CCP: timeout sending Config-Requests

I also get similar results if I put the noccp option in the
configuration for pppd (this works even if the client doesn't have IP
address and DNS specified, the pppd sends the IPCP message specifying
those).

Does anyone have any ideas what could be the problem here?

myrtoseraf <(E-Mail Removed)> wrote:

> I am trying to connect a Pocket PC (2005) to a linux box running pppd.
> It starts out ok but then hte Pocket PC pops up a message that the
> "answering modem has disconnected". From the pppd logs (see below) it
> looks as if the client stops responding.

> This is my pppd configuration:
> dump
> hide-password
> noauth
> /dev/ttyS3
> 57600
> nodefaultroute
> proxyarp
> 192.168.2.1:192.168.2.2
> netmask 255.255.255.0
> ms-dns x.x.x.x
> ms-dns x.x.x.x
> lock
> asyncmap 0
> logfile /tmp/pppDebug
> linkname pda
> connect "chat 'CLIENT' 'CLIENTSERVER\\c'"

Yuk!

> nodetach
> # HW flow control:
> crtscts
> # Non standard HW flow control (no DTR signaling):
> #cdtrcts
> # Disable HW flow control:
> #nocrtscts
> # Use SW flow control:
> #xonxoff

> (I have also tried using the options below but they don't make a
> difference
> lcp-echo-interval 5
> lcp-echo-failure 5

> I have set up the Pocket PC using XML provisioning so that I can
> specify a direct connection (device type = "direct" device name =
> "Serial Cable on COM1:"). I enable IP header and software compression,
> baud rate 57600 8N1 etc.

> This is the log file when I don't specify the IP address and DNS
> servers on the client:

> Trying to setdtr to 0.
> setdtr to 0.
> Serial connection established.
> using channel 1
> Using interface ppp0
> Connect: ppp0 <--> /dev/ttyS3
> rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <pcomp> <accomp>]
> Warning - secret file /etc/ppp/pap-secrets has world and/or group
> access
> sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x7c7c20dc> <pcomp>
> <accomp>]
> sent [LCP ConfAck id=0x0 <asyncmap 0x0> <pcomp> <accomp>]
> rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x7c7c20dc> <pcomp>
> <accomp>]
> sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
> rcvd [CCP ConfReq id=0x0 < 12 06 00 00 00 01>]
> sent [CCP ConfReq id=0x1]
> sent [CCP ConfRej id=0x0 < 12 06 00 00 00 01>]

Here pppd rejects a request from the peer for MPPC, Microsoft compression,
which is patented. Unfortunately, rejection almost always means that the
peer will terminate the negotiations. Or, as in this case, simply stop
responding...

> rcvd [IPCP ConfReq id=0x0 <compress VJ 0f 00> <addr 0.0.0.0> <ms-dns1
> 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
> sent [IPCP ConfRej id=0x0 <ms-wins 0.0.0.0> <ms-wins 0.0.0.0>]
> rcvd [proto=0x8057] 01 00 00 0e 01 0a 02 30 05 ff fe b6 3b 71
> Unsupported protocol 0x8057 received
> sent [LCP ProtRej id=0x2 80 57 01 00 00 0e 01 0a 02 30 05 ff fe b6 3b
> 71]

IPV6CP is rejected (it's a surprise to even see it requested).

> rcvd [IPCP ConfAck id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
> ************************************************** **********************************
> * The client stops responding here and thinks that the linux box has
> disconnected
> * why????

My guess is that it's caused by the rejection of MPPC.

> ************************************************** *************************************

<snip>

> Does anyone have any ideas what could be the problem here?

Microsoft.

--
Clifford Kite

> > rcvd [CCP ConfReq id=0x0 < 12 06 00 00 00 01>]
> > sent [CCP ConfReq id=0x1]
> > sent [CCP ConfRej id=0x0 < 12 06 00 00 00 01>]
>
> Here pppd rejects a request from the peer for MPPC, Microsoft compression,
> which is patented. Unfortunately, rejection almost always means that the
> peer will terminate the negotiations. Or, as in this case, simply stop
> responding...

Yes I did notice the request for MPPC but I didn't realise that the
client would stop responding after that. So is there no way to set up
a connection from a Pocket PC to a linux box? It must be possible to
negotiate around MPPC somehow? I hope!

The client does make one more response though, later on:
> rcvd [IPCP ConfReq id=0x0 <compress VJ 0f 00> <addr 0.0.0.0> <ms-dns1
> > 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]

Also, I did see this example log http://www.van-dijk.net/PPP-NT-HOWTO...T-HOWTO-4.html
where the MPPC is rejected but the two machines keep talking ...
>
> > rcvd [IPCP ConfReq id=0x0 <compress VJ 0f 00> <addr 0.0.0.0> <ms-dns1
> > 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
> > sent [IPCP ConfRej id=0x0 <ms-wins 0.0.0.0> <ms-wins 0.0.0.0>]
> > rcvd [proto=0x8057] 01 00 00 0e 01 0a 02 30 05 ff fe b6 3b 71
> > Unsupported protocol 0x8057 received
> > sent [LCP ProtRej id=0x2 80 57 01 00 00 0e 01 0a 02 30 05 ff fe b6 3b
> > 71]
>
> IPV6CP is rejected (it's a surprise to even see it requested).
Well as far as I can tell, the PocketPC is trying to send its MAC
address to the linux box using IPv6. Do you think this could be
causing problems?

myrtoseraf <(E-Mail Removed)> wrote:

>> > rcvd [CCP ConfReq id=0x0 < 12 06 00 00 00 01>]
>> > sent [CCP ConfReq id=0x1]
>> > sent [CCP ConfRej id=0x0 < 12 06 00 00 00 01>]
>>
>> Here pppd rejects a request from the peer for MPPC, Microsoft compression,
>> which is patented. Unfortunately, rejection almost always means that the
>> peer will terminate the negotiations. Or, as in this case, simply stop
>> responding...

> Yes I did notice the request for MPPC but I didn't realise that the
> client would stop responding after that. So is there no way to set up
> a connection from a Pocket PC to a linux box? It must be possible to
> negotiate around MPPC somehow? I hope!

If peer requires that MPPC be negotiated then the only way is to find
a non-standard pppd that implements MPPC. The standard pppd implements
MPPE, the encryption part that's not patented, but not MPPC.

> The client does make one more response though, later on:
>> rcvd [IPCP ConfReq id=0x0 <compress VJ 0f 00> <addr 0.0.0.0> <ms-dns1
>> > 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]

> Also, I did see this example log
http://www.van-dijk.net/PPP-NT-HOWTO...T-HOWTO-4.html
> where the MPPC is rejected but the two machines keep talking ...

Yes, my mistake. The NT would quit if MPPC was rejected and it had
requested both MPPC and MPPE. In the example only MPPC was requested.
I still think the MPPC rejection could be the reason for negotiation
failure. But see below.

>> > rcvd [IPCP ConfReq id=0x0 <compress VJ 0f 00> <addr 0.0.0.0> <ms-dns1
>> > 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
>> > sent [IPCP ConfRej id=0x0 <ms-wins 0.0.0.0> <ms-wins 0.0.0.0>]
>> > rcvd [proto=0x8057] 01 00 00 0e 01 0a 02 30 05 ff fe b6 3b 71
>> > Unsupported protocol 0x8057 received
>> > sent [LCP ProtRej id=0x2 80 57 01 00 00 0e 01 0a 02 30 05 ff fe b6 3b
>> > 71]

I just noticed something that's worth a try. The peer asked for and
is granted <compress VJ 0f 00> while pppd asked for and was granted
<compress VJ 0f 01>. The 01 means compress the slot identifier in
VJ header compression while 00 means do not compress it. Minimal PPP
implementations may be broken, accepting slot identifier compression
by the peer when they cannot accommodate it. Adding the pppd novjccomp
option will cause pppd to drop it's request for identifier compression.

>> IPV6CP is rejected (it's a surprise to even see it requested).
> Well as far as I can tell, the PocketPC is trying to send its MAC
> address to the linux box using IPv6. Do you think this could be
> causing problems?

No, but I'm not up to speed on IPV6 much less IPV6CP.

You may well get more authoritative answers to your questions on
comp.protocols.ppp.

--
Clifford Kite
/* Those who can't write, write manuals. */

Thanks for your last answer! (and sorry for the delay in responding)

On Jun 21, 7:20 pm, Clifford Kite <k...@not.available.tld> wrote:
> I just noticed something that's worth a try. The peer asked for and
> is granted <compress VJ 0f 00> while pppd asked for and was granted
> <compress VJ 0f 01>. The 01 means compress the slot identifier in
> VJ header compression while 00 means do not compress it. Minimal PPP
> implementations may be broken, accepting slot identifier compression
> by the peer when they cannot accommodate it. Adding the pppd novjccomp
> option will cause pppd to drop it's request for identifier compression.

I have tried using both the novjccomp and novj options and it seems to
get stuck. Here are some excerpts:

*************** with normal header compression (as before)
*********************************************
Connect: ppp0 <--> /dev/ttyS3
rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <pcomp> <accomp>]
Warning - secret file /etc/ppp/pap-secrets has world and/or group
access
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x86517350> <pcomp>
<accomp>]
sent [LCP ConfAck id=0x0 <asyncmap 0x0> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x86517350> <pcomp>
<accomp>]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
rcvd [CCP ConfReq id=0x0 < 12 06 00 00 00 01>]
sent [CCP ConfReq id=0x1]
sent [CCP ConfRej id=0x0 < 12 06 00 00 00 01>]
rcvd [IPCP ConfReq id=0x0 <compress VJ 0f 00> <addr 0.0.0.0> <ms-dns1
0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
sent [IPCP ConfRej id=0x0 <ms-wins 0.0.0.0> <ms-wins 0.0.0.0>]
rcvd [proto=0x8057] 01 00 00 0e 01 0a 02 30 05 ff fe b6 3b 71
Unsupported protocol 0x8057 received
sent [LCP ProtRej id=0x2 80 57 01 00 00 0e 01 0a 02 30 05 ff fe b6 3b
71]
rcvd [IPCP ConfAck id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
CCP: timeout sending Config-Requests
IPCP: timeout sending Config-Requests
sent [LCP TermReq id=0x3 "No network protocols running"]
sent [LCP TermReq id=0x4 "No network protocols running"]
Connection terminated.
************************************************** ************************************************** ****************

*************** with novjccomp option
************************************************** ************************
Connect: ppp0 <--> /dev/ttyS3
rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <pcomp> <accomp>]
Warning - secret file /etc/ppp/pap-secrets has world and/or group
access
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xf4305cad> <pcomp>
<accomp>]
sent [LCP ConfAck id=0x0 <asyncmap 0x0> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xf4305cad> <pcomp>
<accomp>]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 00>]
rcvd [CCP ConfReq id=0x0 < 12 06 00 00 00 01>]
sent [CCP ConfReq id=0x1]
sent [CCP ConfRej id=0x0 < 12 06 00 00 00 01>]
rcvd [IPCP ConfReq id=0x0 <compress VJ 0f 00> <addr 0.0.0.0> <ms-dns1
0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
sent [IPCP ConfRej id=0x0 <ms-wins 0.0.0.0> <ms-wins 0.0.0.0>]
rcvd [proto=0x8057] 01 00 00 0e 01 0a 02 30 05 ff fe b6 3b 71
Unsupported protocol 0x8057 received
sent [LCP ProtRej id=0x2 80 57 01 00 00 0e 01 0a 02 30 05 ff fe b6 3b
71]
rcvd [IPCP ConfAck id=0x1 <addr 192.168.2.1> <compress VJ 0f 00>]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 00>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 00>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 00>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 00>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 00>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 00>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 00>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 00>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 00>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 00>]
CCP: timeout sending Config-Requests
IPCP: timeout sending Config-Requests
sent [LCP TermReq id=0x3 "No network protocols running"]
sent [LCP TermReq id=0x4 "No network protocols running"]
Connection terminated.
************************************************** ************************************************** ****************

**************** with novj option
************************************************** *******************************
Connect: ppp0 <--> /dev/ttyS3
rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <pcomp> <accomp>]
Warning - secret file /etc/ppp/pap-secrets has world and/or group
access
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xd0681d4e> <pcomp>
<accomp>]
sent [LCP ConfAck id=0x0 <asyncmap 0x0> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xd0681d4e> <pcomp>
<accomp>]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1>]
rcvd [CCP ConfReq id=0x0 < 12 06 00 00 00 01>]
sent [CCP ConfReq id=0x1]
sent [CCP ConfRej id=0x0 < 12 06 00 00 00 01>]
rcvd [IPCP ConfReq id=0x0 <compress VJ 0f 00> <addr 0.0.0.0> <ms-dns1
0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
sent [IPCP ConfRej id=0x0 <compress VJ 0f 00> <ms-wins 0.0.0.0> <ms-
wins 0.0.0.0>]
rcvd [proto=0x8057] 01 00 00 0e 01 0a 02 30 05 ff fe b6 3b 71
Unsupported protocol 0x8057 received
sent [LCP ProtRej id=0x2 80 57 01 00 00 0e 01 0a 02 30 05 ff fe b6 3b
71]
rcvd [IPCP ConfAck id=0x1 <addr 192.168.2.1>]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1>]
sent [CCP ConfReq id=0x1]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1>]
CCP: timeout sending Config-Requests
IPCP: timeout sending Config-Requests
sent [LCP TermReq id=0x3 "No network protocols running"]
sent [LCP TermReq id=0x4 "No network protocols running"]
Connection terminated.
************************************************** *************************************

The interesting thing is that at some point in the negotiation the
linux box (pppd server) sends the IPCP request:
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f
01>]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f
00>]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1>]
and after various negotiations the client (PocketPC) responds to this:
rcvd [IPCP ConfAck id=0x1 <addr 192.168.2.1> <compress VJ 0f
01>]
rcvd [IPCP ConfAck id=0x1 <addr 192.168.2.1> <compress VJ 0f
00>]
rcvd [IPCP ConfAck id=0x1 <addr 192.168.2.1>]
at exactly which point the Pocket PC claims the server disconnected,
whereas the server re-issues the exact same request (with same ID)
repeatedly until it determines that the connection is dead.

I will try posting to comp.protocols.ppp as you suggest. Thanks!!!

myrtoseraf <(E-Mail Removed)> wrote:
> Thanks for your last answer! (and sorry for the delay in responding)

> On Jun 21, 7:20 pm, Clifford Kite <k...@not.available.tld> wrote:
>> I just noticed something that's worth a try. The peer asked for and
>> is granted <compress VJ 0f 00> while pppd asked for and was granted
>> <compress VJ 0f 01>. The 01 means compress the slot identifier in
>> VJ header compression while 00 means do not compress it. Minimal PPP
>> implementations may be broken, accepting slot identifier compression
>> by the peer when they cannot accommodate it. Adding the pppd novjccomp
>> option will cause pppd to drop it's request for identifier compression.

> I have tried using both the novjccomp and novj options and it seems to
> get stuck. Here are some excerpts:

Right, nothing significant changed.

> *************** with normal header compression (as before)
> *********************************************
> Connect: ppp0 <--> /dev/ttyS3
> rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <pcomp> <accomp>]
> Warning - secret file /etc/ppp/pap-secrets has world and/or group
> access
> sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x86517350> <pcomp>
> <accomp>]
> sent [LCP ConfAck id=0x0 <asyncmap 0x0> <pcomp> <accomp>]
> rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x86517350> <pcomp>
> <accomp>]
> sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
> rcvd [CCP ConfReq id=0x0 < 12 06 00 00 00 01>]
> sent [CCP ConfReq id=0x1]
> sent [CCP ConfRej id=0x0 < 12 06 00 00 00 01>]
> rcvd [IPCP ConfReq id=0x0 <compress VJ 0f 00> <addr 0.0.0.0> <ms-dns1
> 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
> sent [IPCP ConfRej id=0x0 <ms-wins 0.0.0.0> <ms-wins 0.0.0.0>]
> rcvd [proto=0x8057] 01 00 00 0e 01 0a 02 30 05 ff fe b6 3b 71
> Unsupported protocol 0x8057 received
> sent [LCP ProtRej id=0x2 80 57 01 00 00 0e 01 0a 02 30 05 ff fe b6 3b
> 71]
> rcvd [IPCP ConfAck id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]

This Ack response (as modified by VJ options) is the last request or
response received from the peer in all cases. So at this point either
the peer is no longer negotiating or it's requests are getting lost.

I first suggested the problem was the patent-encumbered MPPC and then
backed off, but not without some doubt remaining. Now the VJ change
I suggested has had virtually no effect. So my track record is zip but
here is my last shot, a wild guess: Try adding bogus ms-wins addresses
so pppd will not issue a IPCP ConfRej for them and, hopefully, IPCP will
at least complete. Of course even if IPCP completes things may still
stall out...

> sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
> sent [CCP ConfReq id=0x1]

[ect.]

> I will try posting to comp.protocols.ppp as you suggest. Thanks!!!

Good Luck.

--
Clifford Kite
/* Speak softly and carry a +6 two-handed sword. */

On Jul 9, 7:09 pm, Clifford Kite <k...@not.available.tld> wrote:
> > rcvd [IPCP ConfAck id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
>
> This Ack response (as modified by VJ options) is the last request or
> response received from the peer in all cases. So at this point either
> the peer is no longer negotiating or it's requests are getting lost.

Yes I agree. I think basically whatever happens the pppd servers first
CCP request
*** sent [CCP ConfReq id=0x1]
never gets acknowledged by the client. If you change the options (e.g.
novj/noccp/novjccomp, etc) on the pppd server then the last
acknowledged message may change, but the CCP request still remains
unacknowledged.


> I first suggested the problem was the patent-encumbered MPPC and then
> backed off, but not without some doubt remaining. Now the VJ change

I'm not necessarily disagreeing with you, but I have seen cases where
the request for MPPC is rejected and the client continues negotiating
(as it should !!!) so I'm not sure why it might be a problem here. (As
for example in that link I originally quoted)

> I suggested has had virtually no effect. So my track record is zip but
> here is my last shot, a wild guess: Try adding bogus ms-wins addresses
> so pppd will not issue a IPCP ConfRej for them and, hopefully, IPCP will
> at least complete. Of course even if IPCP completes things may still
> stall out...

Yes they do, this is something I have already tried and the result is:

************** Log with DNS/MS-WINS addresses specified on both sides
*************
Serial connection established.
using channel 1
Using interface ppp0
Connect: ppp0 <--> /dev/ttyS3
rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <pcomp> <accomp>]
Warning - secret file /etc/ppp/pap-secrets has world and/or group
access
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xcbc610f3> <pcomp>
<accomp>]
sent [LCP ConfAck id=0x0 <asyncmap 0x0> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xcbc610f3> <pcomp>
<accomp>]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
rcvd [CCP ConfReq id=0x0 < 12 06 00 00 00 01>]
sent [CCP ConfReq id=0x1]
sent [CCP ConfRej id=0x0 < 12 06 00 00 00 01>]
rcvd [IPCP ConfReq id=0x0 <compress VJ 0f 00> <addr 192.168.2.2>]
sent [IPCP ConfAck id=0x0 <compress VJ 0f 00> <addr 192.168.2.2>]
rcvd [proto=0x8057] 01 00 00 0e 01 0a 02 30 05 ff fe b6 3b 71
Unsupported protocol 0x8057 received
sent [LCP ProtRej id=0x2 80 57 01 00 00 0e 01 0a 02 30 05 ff fe b6 3b
71]
rcvd [IPCP ConfAck id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
Cannot determine ethernet address for proxy ARP
local IP address 192.168.2.1
remote IP address 192.168.2.2
Script /etc/ppp/ip-up started (pid 207)
Script /etc/ppp/ip-up finished (pid 207), status = 0x0
sent [CCP ConfReq id=0x1]
sent [CCP ConfReq id=0x1]
sent [CCP ConfReq id=0x1]
sent [CCP ConfReq id=0x1]
sent [CCP ConfReq id=0x1]
sent [CCP ConfReq id=0x1]
sent [CCP ConfReq id=0x1]
sent [CCP ConfReq id=0x1]
sent [CCP ConfReq id=0x1]
CCP: timeout sending Config-Requests
************************************************** ************************************************

Thank you very much for trying to help me though! This issue has
really got me stumped!!!

Myrto

myrtoseraf <(E-Mail Removed)> wrote:
> On Jul 9, 7:09 pm, Clifford Kite <k...@not.available.tld> wrote:
>> > rcvd [IPCP ConfAck id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
>>
>> This Ack response (as modified by VJ options) is the last request or
>> response received from the peer in all cases. So at this point either
>> the peer is no longer negotiating or it's requests are getting lost.

> Yes I agree. I think basically whatever happens the pppd servers first
> CCP request
> *** sent [CCP ConfReq id=0x1]
> never gets acknowledged by the client. If you change the options (e.g.
> novj/noccp/novjccomp, etc) on the pppd server then the last
> acknowledged message may change, but the CCP request still remains
> unacknowledged.

I'm surprised that using "noccp" results in pppd generating any CCP
requests at all. It should result in a Protocol-Reject from pppd in
response to the peer CCP request and no CCP requests from pppd - in
my opinion.

If that is indeed the case then perhaps a pppd upgrade is in order,
pppd 2.4.4 appears to be the latest. The source is available at
ftp.samba.org in pub/ppp.

>> I first suggested the problem was the patent-encumbered MPPC and then
>> backed off, but not without some doubt remaining. Now the VJ change

> I'm not necessarily disagreeing with you, but I have seen cases where
> the request for MPPC is rejected and the client continues negotiating
> (as it should !!!) so I'm not sure why it might be a problem here. (As
> for example in that link I originally quoted)

I'm not sure what is meant by "cases" but PPP implementations vary in
capability and quality.

>> I suggested has had virtually no effect. So my track record is zip but
>> here is my last shot, a wild guess: Try adding bogus ms-wins addresses
>> so pppd will not issue a IPCP ConfRej for them and, hopefully, IPCP will
>> at least complete. Of course even if IPCP completes things may still
>> stall out...

> Yes they do, this is something I have already tried and the result is:

> ************** Log with DNS/MS-WINS addresses specified on both sides
> *************
> Serial connection established.
> using channel 1
> Using interface ppp0
> Connect: ppp0 <--> /dev/ttyS3
> rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <pcomp> <accomp>]
> Warning - secret file /etc/ppp/pap-secrets has world and/or group
> access
> sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xcbc610f3> <pcomp>
> <accomp>]
> sent [LCP ConfAck id=0x0 <asyncmap 0x0> <pcomp> <accomp>]
> rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xcbc610f3> <pcomp>
> <accomp>]
> sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
> rcvd [CCP ConfReq id=0x0 < 12 06 00 00 00 01>]
> sent [CCP ConfReq id=0x1]
> sent [CCP ConfRej id=0x0 < 12 06 00 00 00 01>]
> rcvd [IPCP ConfReq id=0x0 <compress VJ 0f 00> <addr 192.168.2.2>]
> sent [IPCP ConfAck id=0x0 <compress VJ 0f 00> <addr 192.168.2.2>]
> rcvd [proto=0x8057] 01 00 00 0e 01 0a 02 30 05 ff fe b6 3b 71
> Unsupported protocol 0x8057 received
> sent [LCP ProtRej id=0x2 80 57 01 00 00 0e 01 0a 02 30 05 ff fe b6 3b 71]
> rcvd [IPCP ConfAck id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
> Cannot determine ethernet address for proxy ARP
> local IP address 192.168.2.1
> remote IP address 192.168.2.2
> Script /etc/ppp/ip-up started (pid 207)
> Script /etc/ppp/ip-up finished (pid 207), status = 0x0

At this point the PPP interface should be up and the link usable.

> sent [CCP ConfReq id=0x1]
> sent [CCP ConfReq id=0x1]
> sent [CCP ConfReq id=0x1]
> sent [CCP ConfReq id=0x1]
> sent [CCP ConfReq id=0x1]
> sent [CCP ConfReq id=0x1]
> sent [CCP ConfReq id=0x1]
> sent [CCP ConfReq id=0x1]
> sent [CCP ConfReq id=0x1]
> CCP: timeout sending Config-Requests

This is pppd trying to bring CCP to the Open state (providing closure)
with no options, something the peer is apparently not able, or willing,
to handle. Does the timeout cause a link failure?

--
Clifford Kite

On Jul 10, 7:31 pm, Clifford Kite <k...@not.available.tld> wrote:
> I'm surprised that using "noccp" results in pppd generating any CCP
> requests at all. It should result in a Protocol-Reject from pppd in
> response to the peer CCP request and no CCP requests from pppd - in
> my opinion.

Sorry, my mistake about the noccp option, I had tried this sometime
ago while still tinkering with the options, but I tried it again now
and here is what happens:

************************************************** **************************************
erial connection established.
using channel 1
Using interface ppp0
Connect: ppp0 <--> /dev/ttyS3
rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <pcomp> <accomp>]
Warning - secret file /etc/ppp/pap-secrets has world and/or group
access
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xefb5415d> <pcomp>
<accomp>]
sent [LCP ConfAck id=0x0 <asyncmap 0x0> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xefb5415d> <pcomp>
<accomp>]
sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
rcvd [CCP ConfReq id=0x0 < 12 06 00 00 00 01>]
Unsupported protocol 'Compression Control Protocol' (0x80fd) received
sent [LCP ProtRej id=0x2 80 fd 01 00 00 0a 12 06 00 00 00 01]
rcvd [IPCP ConfReq id=0x0 <compress VJ 0f 00> <addr 0.0.0.0> <ms-dns1
0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
sent [IPCP ConfRej id=0x0 <ms-wins 0.0.0.0> <ms-wins 0.0.0.0>]
rcvd [proto=0x8057] 01 00 00 0e 01 0a 02 30 05 ff fe b6 3b 71
Unsupported protocol 0x8057 received
sent [LCP ProtRej id=0x3 80 57 01 00 00 0e 01 0a 02 30 05 ff fe b6 3b
71]
rcvd [IPCP ConfAck id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>]
rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 00> <addr 0.0.0.0> <ms-dns1
0.0.0.0> <ms-dns3 0.0.0.0>]
sent [IPCP ConfNak id=0x1 <addr 192.168.2.2> <ms-dns1 195.167.65.194>
<ms-dns3 213.249.17.11>]
rcvd [IPCP ConfReq id=0x2 <compress VJ 0f 00> <addr 192.168.2.2> <ms-
dns1 195.167.65.194> <ms-dns3 213.249.17.11>]
sent [IPCP ConfAck id=0x2 <compress VJ 0f 00> <addr 192.168.2.2> <ms-
dns1 195.167.65.194> <ms-dns3 213.249.17.11>]
Cannot determine ethernet address for proxy ARP
local IP address 192.168.2.1
remote IP address 192.168.2.2
Script /etc/ppp/ip-up started (pid 144)
Script /etc/ppp/ip-up finished (pid 144), status = 0x0
************************************************** ***********************************************

As you say the pppd correctly rejects the CCP requests. The
negotiation here seems (to me) to work fine, however the PocketPC
still reports that "the answering modem has disconnected" (this seems
to happen at about the time when the scripts finish executing but I
can't be sure) whereas the pppd server does not 'see' this
disconnection and gets stuck in this state with the link open (?) and
unable to receive a new connection attempt.

>
> If that is indeed the case then perhaps a pppd upgrade is in order,
> pppd 2.4.4 appears to be the latest. The source is available at
> ftp.samba.org in pub/ppp.

The pppd I'm using is an old version but unfortunately this is one of
the problems here. I am absolutely stuck with it as this is a comms
device running a limited linux OS which I have no control over.

>
> >> I first suggested the problem was the patent-encumbered MPPC and then
> >> backed off, but not without some doubt remaining. Now the VJ change
> > I'm not necessarily disagreeing with you, but I have seen cases where
> > the request for MPPC is rejected and the client continues negotiating
> > (as it should !!!) so I'm not sure why it might be a problem here. (As
> > for example in that link I originally quoted)
>
> I'm not sure what is meant by "cases" but PPP implementations vary in
> capability and quality.

Well I meant that by searching on the internet for the MPPC request/
reject (ie. search for "ConfRej" and "< 12 06 00 00 00 01>") I was
able to see several logs (some where the client is a PocketPC) where
the MPPC is rejected and the negotiation continues just fine.


> > sent [CCP ConfReq id=0x1]
> > sent [CCP ConfReq id=0x1]
> > sent [CCP ConfReq id=0x1]
> > sent [CCP ConfReq id=0x1]
> > CCP: timeout sending Config-Requests
>
> This is pppd trying to bring CCP to the Open state (providing closure)
> with no options, something the peer is apparently not able, or willing,
> to handle. Does the timeout cause a link failure?
Well yes and no. The Pocket PC claims the link failure occurs at about
the same time as the pppd starts re-issuing the CCP ConfReq's, i.e.
just after the PocketPC's final response (ConfAck).

myrtoseraf <(E-Mail Removed)> wrote:

> Sorry, my mistake about the noccp option, I had tried this sometime
> ago while still tinkering with the options, but I tried it again now
> and here is what happens:
....

> local IP address 192.168.2.1
> remote IP address 192.168.2.2
> Script /etc/ppp/ip-up started (pid 144)
> Script /etc/ppp/ip-up finished (pid 144), status = 0x0
> ************************************************** ***********************************************

> As you say the pppd correctly rejects the CCP requests. The
> negotiation here seems (to me) to work fine, however the PocketPC
> still reports that "the answering modem has disconnected" (this seems
> to happen at about the time when the scripts finish executing but I
> can't be sure) whereas the pppd server does not 'see' this
> disconnection and gets stuck in this state with the link open (?) and
> unable to receive a new connection attempt.

Pppd is apparently satisfied the link is up on it's end. There is no
modem involved so what "the answering modem has disconnected" means is
whatever Windows wants it to mean. E.g., the PDA system has detected
(or not detected) something indicating to it that the serial link is
not functional. Here I would expect the serial link to be established
using a nullmodem cable.

If the PDA-to-Linux connection is a 3-wire nullmodem cable then "crtscts"
should be replaced by "xonxoff local" . In regard to a full nullmodem
cable my notes about an old post imply that adding "local" to pppd options
where crtscts was already present helped with someone's problem (nature
of problem not recorded), although for a properly wired full nullmodem
cable doing that would be wrong. Your current pppd configuration is
correct for a full nullmodem cable.

>> I'm not sure what is meant by "cases" but PPP implementations vary in
>> capability and quality.

> Well I meant that by searching on the internet for the MPPC request/
> reject (ie. search for "ConfRej" and "< 12 06 00 00 00 01>") I was
> able to see several logs (some where the client is a PocketPC) where
> the MPPC is rejected and the negotiation continues just fine.

Weel, even PocketPCs seem likely to have differing versions (or patch
levels?) of Windows as time goes on.

Regards-
--
Clifford Kite