Bug 470676

Summary:	PPTP connection spontaneously machine-guns packets
Product:	[Fedora] Fedora	Reporter:	James <james>
Component:	pptp	Assignee:	Paul Howarth <paul>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	9	CC:	paul
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	pptp-1.7.2-3.fc10.x86_64	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-12-21 18:58:00 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description James 2008-11-08 19:17:41 UTC

Description of problem:
This is something I've noticed happen a couple of times with two different PPTP servers. I'm running a network activity monitor in gKrellm --- otherwise I wouldn't have noticed this. Occasionally, after the PPP connection has been up for a while, the rate of data flowing out of it suddenly shoots up to around 9--10 MiB/s. This takes the CPU load up high, and top shows pptpgw taking up 98% runtime.

I cannot account for this activity in any of the applications I have running (I shut them down to check). Eventually the connection collapsed on its own, having "sent" just under 600 MiB. However, none of these packets actually ever made it out since I saw no corresponding activity on the wireless interface (I believe once I *did* see it using a wired connection, but I may be mistaken...) and my DSL upload rate is 448 kiB/s anyway.

The relevant log entries nearest to the incident are:

Nov  8 18:57:39 rhapsody pppd[3290]: LCP terminated by peer (MPPE disabled)
Nov  8 18:57:39 rhapsody pppd[3290]: Connect time 541.9 minutes.
Nov  8 18:57:39 rhapsody pppd[3290]: Sent 565805934 bytes, received 157651 bytes.
Nov  8 18:57:40 rhapsody pptp[3259]: anon log[pptp_read_some:pptp_ctrl.c:544]: read returned zero, peer has closed
Nov  8 18:57:40 rhapsody pptp[3259]: anon log[callmgr_main:pptp_callmgr.c:258]: Closing connection (shutdown)
Nov  8 18:57:40 rhapsody pptp[3259]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'
Nov  8 18:57:40 rhapsody pptp[3259]: anon log[pptp_read_some:pptp_ctrl.c:544]: read returned zero, peer has closed
Nov  8 18:57:40 rhapsody pptp[3259]: anon log[call_callback:pptp_callmgr.c:79]: Closing connection (call state)
Nov  8 18:57:40 rhapsody pppd[3290]: Modem hangup
Nov  8 18:57:40 rhapsody pppd[3290]: Connection terminated.
Nov  8 18:57:45 rhapsody pppd[3290]: Exit.

Before this, there were a number of:

Nov  8 18:27:38 rhapsody pptp[3241]: anon log[decaps_gre:pptp_gre.c:414]: buffer
ing packet 1956 (expecting 1955, lost or reordered)

Version-Release number of selected component (if applicable):
pptp-1.7.2-3.fc9.x86_64

How reproducible:
Intermittently

Steps to Reproduce:
1. Use connection until it goes off the deep end.

Additional information:
I run all my PPTP connections with "mtu 1400 mru 1400".

Comment 1 James 2008-12-21 18:58:00 UTC

Not seen in F10 when using NM, closing.

Comment 2 Paul Howarth 2008-12-22 13:10:46 UTC

Thanks for letting me know about this.

I did raise the problem on the upstream mailing list but got no responses.

My gut feel is that something happened to the routing table to cause a routing loop, which is the usual cause of vast amounts of traffic appearing to go down the tunnel.

Comment 3 James 2008-12-22 14:07:35 UTC

Yes, I think it was a routing issue. There was a similar issue raised earlier where PPTP connections do this more or less straight away after connection due to a loop-back in the routes. In my case, the packet blast would happen hours into running an otherwise fine connection. I was using pptpconfig to start the tunnel --- perhaps the trouble was triggered by NM changing the underlying connection's parameters from beneath it. I now use NM to manage the connection, and it's behacing itself.