[pptp-server] two problems: connection lost after 15 to 30 minutes / packet mix-upupon re-dialing

Matthias Suencksen ms at marcant.de
Fri Feb 9 18:51:57 CST 2001


> Matthias:
> 
> I've seen similar problems to what you describe.  On the sessions "going
> away", I haven't invested any time yet (so hopefully someone has a
> response).  On the second, where multiple pids are running, I fixed it by
> adding the following to the options file on the pptp server:
> 
> lcp-echo-failure 10
> lcp-echo-interval 3
> 

yes .. that works quite well .. !


.. in the meantime I have spent some time debugging the other 
problem.

Although I've found out some interesting things I couldn't find
the real cause of the disconnects.

For the record - the PPTP protocol requires that both link partners 
send "ACK" packets for any GRE packet received. The ACKs can go piggybacked 
with real data (the "payload").

After installing lots and lots of additional syslog() messages 
into the server ( displaying wheter a packet has a payload, an ACK
or both and every packet's sequence number and every sequence number 
which is ack'ed ) I found out:

The link goes on quite well for some time .. packet numbers increasing
on both sides to (for example ) 5000 or even 20000.

But sometimes the pptpd server will receive an ACK packet from the Windows98
peer which is completly nonsense , e.g. if the runnning sequence number
is at 5000 the pptpd server will receive an ACK for sequence 166 or sequence
38232988. After this strange packet other ACKs are received which will
continue the normal sequence.

During a call with 20000 packets I get 4-5 of this bogus packets.

I tried out the following: putting in some code which will drop these packets as they 
are obviously corrupt. I wonder where these sequence number come frome - packet
corruption on the network or maybe bugs in either pptpd or the windows client ??

However even after dropping these corrupted ACKs ( and any attached payload data - I won't
trust these packets ;)  I still get disconnects.

They seem to fall in two categories now: either the WIndows98 client says
abruptly good-bye or the pptpd server's log is overflowing with "Unsupported Protocol"
from the pppd.

The next debugging step will be in the MPPE module I think .. I already
target this "coherency count" stuff (which chooses the key to decrypt any
given packet ) .. sigh !! :-)

--
Matthias

> This says "no response to lcp echo after 3 seconds is a failed echo" and "10
> failed echo's means connection is down".  With this, the server closes the
> "dead" (no response to echo requests for 30 seconds) connection after 30
> seconds, kill the process.  You can adjust these times to suit your needs.
> There is supposed to be a default value, but I found it only works if I
> actually configure some value for these two variables.
> 
> BTW  I also add these on linux clients which also would die after some time.
> This forces the ppp interface to go down, so I can restart a client.
> 
> Hope this helpful
> 
> Gord Belsey



More information about the pptp-server mailing list