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

Mon Feb 5 15:22:48 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

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
-----Original Message-----
From: pptp-server-admin at lists.schulte.org
[mailto:pptp-server-admin at lists.schulte.org]On Behalf Of Matthias
Suencksen
Sent: Saturday, February 03, 2001 1:58 AM
To: pptp-server at lists.schulte.org
Subject: [pptp-server] two problems: connection lost after 15 to 30
minutes / packet mix-upupon re-dialing

Hello!

I've been playing around with pptp but run into Anybody has expierenced
problems with sudden
drops of the connection ?

I've got an pptp 1.1.2 server(linux) which
serves windows 98 dialup clients. also there is a
checkpoint-1 firewall in front of the server which
passes traffic to it.

Things go mostly well but when the client does ftp uploads/downloads
(and using their ISDN 8KB/s bandwidth to the max) the connections
usually drop after 15 - 30 minutes ..

.. this does not occur when doing low bandwidth stuff like
telnet over the vpn connection ( the connections lasts
for hours then ).

So in the case where the ISDN line is filled up with
traffic the following happens:

Either the win98 computer says that the vpn adapter
has hung up ( the dial-up connections is still active though)
OR the pptp server says something like "can't read packet header"
and quits the connection itself.

Strace'ing the server in the latter case showed a ECONNRESET
on the GRE socket ( unfortunatelay I forgot wheter it was
during read or write ).

In the former case where the win98 reported that the vpn has hung
up the following happened what I suspect as a bug in the pptp server
(which is second problem I want to report and which may be
completly unrelated to the connection-dropping-stuff !)

The pptp-child processes didn't notice that the windows 98
client already had declared the connection for dead.

After using "reconnect" on the the windows client a new
pptp child process was spawned but the original pptp
process seemed to eat up the packets for the new connection.

Consequently I wasn't able to do even do a "ping".

This resulted in the following interesting log:

Feb  3 08:39:11 server2 pptpd[7504]: CTRL: Sent packet to client
Feb  3 08:40:27 server2 pptpd[7504]: CTRL: Received PPTP Control Message
(type: 5)
Feb  3 08:40:27 server2 pptpd[7504]: CTRL: Made a ECHO RPLY packet
Feb  3 08:40:27 server2 pptpd[7504]: CTRL: I wrote 20 bytes to the
client.
Feb  3 08:40:27 server2 pptpd[7504]: CTRL: Sent packet to client
Feb  3 08:41:59 server2 pptpd[7504]: CTRL: Received PPTP Control Message
(type: 5)
Feb  3 08:41:59 server2 pptpd[7504]: CTRL: Made a ECHO RPLY packet
Feb  3 08:41:59 server2 pptpd[7504]: CTRL: I wrote 20 bytes to the
client.
Feb  3 08:41:59 server2 pptpd[7504]: CTRL: Sent packet to
client

At this point the pptp server does not any long receive type 5
control messages from the client. the windows computer popped
up a message that the vpn adapter has been hung up. I then
type "reconnect":

Feb  3 08:44:10 server2 pptpd[7809]: MGR: Launching
/usr/local/sbin/pptpctrl to handle client
Feb  3 08:44:10 server2 pptpd[7809]: CTRL: local address = 172.19.210.10
Feb  3 08:44:10 server2 pptpd[7809]: CTRL: remote address =
172.19.212.2

So process no 7809 is the new handler for the new connection.

[..]
Feb  3 08:44:10 server2 pppd[7810]: pppd 2.3.11 started by root, uid 0
Feb  3 08:44:10 server2 pppd[7810]: Using interface ppp1
Feb  3 08:44:10 server2 pppd[7810]: Connect: ppp1 <--> /dev/pts/6
Feb  3 08:44:10 server2 pppd[7810]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <auth chap 81> <magic 0xcbda4a08> <pcomp> <accomp>]
Feb  3 08:44:10 server2 pppd[7810]: Timeout 0x8050444:0x80788a0 in 3
seconds.

Now:

Feb  3 08:44:10 server2 pptpd[7504]: Discarding out-of-order packet 1,
already have 24692

It is strange that the "old" pptpd process no. 7504 wants to handle the
packets for the new connection whild should be handled by no.7809 (see
above) - of course
"packet 1" is out of sync with its own sequence number of 24692 ..!

Their seems to be contention for incoming packets:

Feb  3 08:44:10 server2 pptpd[7504]: Discarding out-of-order packet 1,
already have 24692
Feb  3 08:44:10 server2 pptpd[7809]: Buffering out-of-order packet; got
1 after 4294967295
Feb  3 08:44:13 server2 pppd[7810]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <auth
 chap 81> <magic 0xcbda4a08> <pcomp> <accomp>]
Feb  3 08:44:13 server2 pppd[7810]: Timeout 0x8050444:0x80788a0 in 3
seconds.
Feb  3 08:44:13 server2 pptpd[7504]: Discarding out-of-order packet 2,
already have 24692
Feb  3 08:44:13 server2 pptpd[7809]: Packet reorder timeout waiting for
0

.. any ideas appreciated ..!

my pppd setup is:

auth
require-chap
# proxyarp
+chapms-v2
mppe-40
mppe-128
mppe-stateless
# be strict
require-mppe
require-mppe-stateless
# workaround silly Windows clients which send NT-domain prefix
chapms-strip-domain

--
Matthias
_______________________________________________
pptp-server maillist  -  pptp-server at lists.schulte.org
http://lists.schulte.org/mailman/listinfo/pptp-server
List services provided by www.schulteconsulting.com!