Bug 470676 - PPTP connection spontaneously machine-guns packets
PPTP connection spontaneously machine-guns packets
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: pptp (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Howarth
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-08 14:17 EST by James
Modified: 2008-12-22 09:07 EST (History)
1 user (show)

See Also:
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 13:58:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description James 2008-11-08 14:17:41 EST
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 13:58:00 EST
Not seen in F10 when using NM, closing.
Comment 2 Paul Howarth 2008-12-22 08:10:46 EST
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 09:07:35 EST
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.