headers
James Cameron | 3 Apr 2006 06:05
Picon
Favicon

Re: pptp works great on fc5

On Fri, Mar 31, 2006 at 05:07:52PM +0100, Paul Howarth wrote:
> One thing I've noticed is that using "--without bcrelay" in configure 
> seems to have no effect.

Agreed, this is a defect.  Added to the TODO list ...

20060403-1, 1.3.1, the configure option --without-bcrelay does the
opposite of what it implies, reported by Paul Howarth on
pptpclient-devel@...  We shouldn't be using --with
and --without anyway, since they are for external programs.  Convert
this to --enable-bcrelay instead.

> I haven't updated cvs because sf.net's cvs server appears to be down.

Same here.  So I've not committed the TODO list change.  ;-}

--

-- 
James Cameron                         http://quozl.netrek.org/
HP Open Source, Volunteer             http://opensource.hp.com/
PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/
Permalink | Reply | 0 comments |
headers
Ray Van Dolson | 5 Apr 2006 08:47

Major slowdown w/ Poptop >= 1.3.0 and CentOS

Finally upgraded our Poptop server images to use CentOS 4.3 instead of
Fedora Core 2, and upgraded Poptop to 1.3.0 at the same time...

Everything seemed to work fine, however once a client connected and began
pulling traffic we observed that traffic through the tunnel was moving
*very* slowly.  Around ~260Kbps max.

Tried many things including messing with MTU settings, MSS clamping,
changing the kernel (was using a custom 2.6.16 build, also used default
Centos 2.6.9.x kernel with DKMS), enabling/disabling auditd, upgraded to
pppd 2.4.4...  Nothing made a difference.

Finally removed pptpd 1.3.0 and installed 1.2.3.  Problem went away
immediately!  As soon as I reverted back to 1.3.0 the slow transfers came
back.  I compared strace output from the pptpctrl processes from each
version:

From 1.2.3:

Process 14016 attached - interrupt to quit
select(8, [0 3 6 7], NULL, NULL, {56, 356000}) = 1 (in [7], left {52, 348000})
read(7, "E\0\0W27\0\0\200/\204\'\300\250\1\226\300\250\00130\1\210"..., 8260) = 87
write(6, "~\377}#\375\220C\357\332\216)i\270}2\276}0\361\327\352"..., 66) = 66
select(8, [0 3 6 7], NULL, NULL, {0, 50000}) = 1 (in [6], left {0, 50000})
read(6, "~\377}#\375\220}%\3511\277\243\254}*\363}8,\346\241{nO"..., 8196) = 73
writev(7, [{"0\201\210\v\0007\200\0\0\0\0\26\0\0\0S", 16},
{"\377\3\375\220\5\3511\277\243\254\n\363\30,\346\241{nO"..., 55}], 2) = 71
select(8, [0 3 6 7], NULL, NULL, {65, 0}) = 1 (in [7], left {65, 0})
read(7, "E\0\0S29\0\0\200/\204)\300\250\1\226\300\250\00130\201"..., 8260) = 83
write(6, "~\377}#\375\220DO\220J}>a\242\231\212\347Y:\\e}+j4\302"..., 54) = 54
(Continue reading)

Permalink | Reply | 4 comments |
headers
gARetH baBB | 5 Apr 2006 08:58

Re: Major slowdown w/ Poptop >= 1.3.0 and CentOS

On Tue, 4 Apr 2006, Ray Van Dolson wrote:

> My guess is that pptpgre.c is writing every single received GRE packet to
> syslog, and since I happen to have had a target set up to handle it, it's
> slowing everything down. :)

Oh yes, big time, when you get load averages of 10 and you have one pptp 
going you know you have a problem ...

There are two LOG_DEBUG things I remove.

diff -r -u pptpd-1.3.1/pptpgre.c pptpd-1.3.1_/pptpgre.c
--- pptpd-1.3.1/pptpgre.c	2005-12-29 00:10:32.000000000 +0000
+++ pptpd-1.3.1_/pptpgre.c	2006-02-18 12:27:39.000000000 +0000
 <at>  <at>  -319,7 +319,6  <at>  <at> 
 			stats.rx_lost += head->seq - gre.seq_recv - 1;
 			syslog(LOG_DEBUG, "GRE: timeout waiting for %d packets", head->seq - gre.seq_recv - 1);        
 		}
-		syslog(LOG_DEBUG, "GRE: accepting #%d from queue", head->seq);
 		gre.seq_recv = head->seq;
 		status = callback(cl, head->packet, head->packlen);
 		pqueue_del(head);
 <at>  <at>  -399,7 +398,6  <at>  <at> 
 		}
 		/* check for out-of-order sequence number */
 		if (seq_greater(seq, gre.seq_recv)) {
-			syslog(LOG_DEBUG, "GRE: accepting packet #%d", seq);
 			stats.rx_accepted++;
 			gre.seq_recv = seq;
 			return cb(cl, buffer + ip_len + headersize, payload_len);
(Continue reading)

Permalink | Reply | 1 comment |
headers
James Cameron | 5 Apr 2006 08:59
Picon
Favicon

Re: Major slowdown w/ Poptop >= 1.3.0 and CentOS

Ray wrote:
> My guess is that pptpgre.c is writing every single received GRE packet to
> syslog, and since I happen to have had a target set up to handle it, it's
> slowing everything down. :)

Yes, that seems likely.  It would certainly cause an additional context
switch on each packet.  There is a patch discussed already which is in
CVS, yet to be released, probably slated for 1.3.2.  Patch is dated 27th
March.

--

-- 
James Cameron                         http://quozl.netrek.org/
HP Open Source, Volunteer             http://opensource.hp.com/
PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/
Permalink | Reply | 1 comment |
headers
James Cameron | 5 Apr 2006 09:01
Picon
Favicon

Re: Major slowdown w/ Poptop >= 1.3.0 and CentOS

The patch in CVS only reports the packet in debug mode.

--

-- 
James Cameron                         http://quozl.netrek.org/
HP Open Source, Volunteer             http://opensource.hp.com/
PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
Permalink | Reply | 0 comments |
headers
Ray Van Dolson | 5 Apr 2006 09:22

Re: Major slowdown w/ Poptop >= 1.3.0 and CentOS

On Wed, Apr 05, 2006 at 04:59:34PM +1000, James Cameron wrote:
> Yes, that seems likely.  It would certainly cause an additional context
> switch on each packet.  There is a patch discussed already which is in
> CVS, yet to be released, probably slated for 1.3.2.  Patch is dated 27th
> March.
> 

Excellent.  Thanks James.  I've merged this in to my tree.  Apologies if I
missed discussion on the list regarding this previously.

All is well again.

Ray

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
Permalink | Reply | 0 comments |
headers
Andreas Schachl | 5 Apr 2006 12:18
Picon

Problems with reverse NAT

Hello!

My setup looks like this:

local Network -> Firewall (own) -> Internet -> Firewall -> branch

I have installed poptop on our firewall (gentoo with kernel 2.6-12) and 
want to allow a user sitting in our second office to connect using VPN. 
The problem is that whenever he tries to login (using win xp sp2) he 
gets error 619 - unknown error. The log file on our firewall tells me:

Code:

Apr  4 11:29:17 [pptpd] CTRL: Client w.x.y.z control connection started
Apr  4 11:29:17 [pptpd] CTRL: Starting call (launching pppd, opening GRE)
Apr  4 11:29:18 [pppd] Plugin /usr/lib/pptpd/pptpd-logwtmp.so loaded.
Apr  4 11:29:18 [pppd] pptpd-logwtmp: $Version$
Apr  4 11:29:18 [pppd] pppd 2.4.2 started by root, uid 0
Apr  4 11:29:18 [pppd] Using interface ppp0
Apr  4 11:29:18 [pppd] Connect: ppp0 <--> /dev/pts/1
Apr  4 11:29:48 [pppd] LCP: timeout sending Config-Requests_
Apr  4 11:29:48 [pppd] Connection terminated.
Apr  4 11:29:48 [pppd] Exit.
Apr  4 11:29:48 [pptpd] GRE: read(fd=6,buffer=804d560,len=8196) from PTY 
failed: status = -1 error = Input/output error, usually caused by 
unexpected termination of pppd, check option syntax and pppd logs
Apr  4 11:29:48 [pptpd] CTRL: PTY read or GRE write failed (pty,gre)=(6,7)
Apr  4 11:29:48 [pptpd] CTRL: Client w.x.y.z control connection finished

My guess would be that the second firewall is blocking the reverse
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jakob Curdes | 5 Apr 2006 14:23
Picon
Favicon

Re: Problems with reverse NAT


> Apr  4 11:29:48 [pptpd] CTRL: PTY read or GRE write failed 
> (pty,gre)=(6,7)
> Apr  4 11:29:48 [pptpd] CTRL: Client w.x.y.z control connection finished

My guess would be that the seconf firewall blocks GRE packets. If so, 
you have no options available other than to allow them.
Check with tcpdump if GRE packets are received on your firewall when the 
client starts a connection.

To diagnose your setup, you find helpful hints at

http://pptpclient.sourceforge.net/howto-diagnosis.phtml

Most of the document is valid for the server situation also as it is the 
same pppd invoking the connection.

Hope this helps,
Jakob Curdes

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
Permalink | Reply | 0 comments |
headers
Gene Nazarov | 5 Apr 2006 15:42

RE: Problems with reverse NAT

I had pretty much the same issue... Turned out my firewall was with
modules only so I had to load bunch of modules to get it to work. (It is
most likely connection tracking on the iptables, if you got them).

gix ~ # less /etc/modules.autoload.d/
tun
ppp_mppe
ip_conntrack
ip_conntrack_ftp
ip_nat_ftp
ip_nat_pptp
ppp_generic
ppp_deflate
bsd_comp
ip_conntrack_pptp
ip_nat_h323
ip_conntrack_h323

gix ~ # uname -a
Linux gix 2.6.15-gentoo-r7 #1 SMP PREEMPT Tue Mar 21 18:41:23 CST 2006
i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux
gix ~ #

Btw, I highly HIGHLY recommend going all the way up gentoo-sources.
Connection tracking and ppp in general is greatly improved in the 2.6.15
and up. (you will need to reemerge ppp and pptpd once you upgrade due to
module renaming). I recommend making sure that the pptpd works without
any firewalls (on local lan) and then going from there.

Thank you.
(Continue reading)

Permalink | Reply | 0 comments |
headers
MRgreiner | 5 Apr 2006 17:37
Picon

CPU surges

After seeing some CPU surges on my vpn server (sometimes reaching 7
according to top, with just 5 users connected!), I did some checking,
and found that pppd was starting exim4 for each new VPN connection
started by PopTop.

Does somebody know why is this, and what would be the proper way to
handle this? I don't need any kind of message generated for each new
connection (even less when that loads my server like that, taking it
from zero to a load of 7 just a mere 5 users).

For now, I've just moved the exim4 script from /etc/ppp/ip-up.d to a new
/etc/ppp/ip-up.d.backup folder. Since I don't have a clue on why exim4
was being started, could somebody help me understanding why it was being
started and if just removing the script like I did is the proper way to
deal with it?

Thank you,

Marcos Roberto

PS: My server config:
AMD Sempron 3000+
512MB RAM
80GB HD
Debian Sarge
ppp 2.4.3 (package installed)
poptop 1.2.3 (compiled from source)

--

-- 
 -------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |

Gmane