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".
Not seen in F10 when using NM, closing.
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.
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.