Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 470676 - PPTP connection spontaneously machine-guns packets
Summary: PPTP connection spontaneously machine-guns packets
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: pptp
Version: 9
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Paul Howarth
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-11-08 19:17 UTC by James
Modified: 2008-12-22 14:07 UTC (History)
1 user (show)

Fixed In Version: pptp-1.7.2-3.fc10.x86_64
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-12-21 18:58:00 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.