Intrepid Slow PPTP Performance - retransmits and lost ACKs

[John]

Binary package hint: network-manager-pptp

I'm using a fresh install of Intrepid 64bit on a machine with 4GB of memory. I've got a PPTP tunnel running back to work. I quickly noticed that performance was very poor over this link. There are a lot of stalls; web pages take a very long time to render and SSH connections stall a lot. I may be a bit presumptuous in assuming this is a bug - but this issue is not present with Hardy 32bit. While diagnosing the issue I noticed a lot of packet buffering mesages in the syslog:

Nov 2 08:42:41 john00-desktop2 pptp[8338]: nm-pptp-service-8329 log[decaps_gre:pptp_gre.c:414]: buffering packet 1576 (expecting 1575, lost or reordered)
Nov 2 08:42:41 john00-desktop2 pptp[8338]: nm-pptp-service-8329 log[decaps_gre:pptp_gre.c:414]: buffering packet 1577 (expecting 1575, lost or reordered)
Nov 2 08:42:41 john00-desktop2 pptp[8338]: nm-pptp-service-8329 log[decaps_gre:pptp_gre.c:414]: buffering packet 1584 (expecting 1583, lost or reordered)
Nov 2 08:42:41 john00-desktop2 pptp[8338]: nm-pptp-service-8329 log[decaps_gre:pptp_gre.c:414]: buffering packet 1585 (expecting 1583, lost or reordered)
Nov 2 08:42:42 john00-desktop2 pptp[8338]: nm-pptp-service-8329 log[decaps_gre:pptp_gre.c:414]: buffering packet 1589 (expecting 1588, lost or reordered)
Nov 2 08:42:42 john00-desktop2 pptp[8338]: nm-pptp-service-8329 log[decaps_gre:pptp_gre.c:414]: buffering packet 1590 (expecting 1588, lost or reordered)
Nov 2 08:42:42 john00-desktop2 pptp[8338]: nm-pptp-service-8329 log[decaps_gre:pptp_gre.c:414]: buffering packet 1593 (expecting 1592, lost or reordered)

My Wireshark packet captures show a lot of retransmissions and duplicate ACK's which appear to be the cause of the performance problems:

18 39.050106 172.29.14.101 172.29.17.192 TCP [TCP Previous segment lost] [TCP segment of a reassembled PDU]
19 39.050145 172.29.17.192 172.29.14.101 TCP [TCP Dup ACK 15#1] 45754 > http [ACK] Seq=438 Ack=4333 Win=14592 Len=0 TSV=2398754 TSER=75797622 SLE=5777 SRE=6961
29 39.425900 172.29.14.101 172.29.17.192 TCP http > 45756 [ACK] Seq=1 Ack=453 Win=50540 Len=0 TSV=75797662 TSER=2398760
30 39.747035 172.29.14.101 172.29.17.192 TCP [TCP Previous segment lost] [TCP segment of a reassembled PDU]
31 39.747055 172.29.17.192 172.29.14.101 TCP [TCP Dup ACK 25#1] 45756 > http [ACK] Seq=453 Ack=1 Win=5888 Len=0 TSV=2398928 TSER=75797662 SLE=1445 SRE=1705
32 39.834203 172.29.14.101 172.29.17.192 HTTP [TCP Retransmission] HTTP/1.1 200 OK (text/html)

I'm not sure how to go about further diagnosing this issue. Perhaps it's related to other known issues with Network Manager. This is a test machine so I'm not afraid to break it.

Thank you,
John

[John (john-navarro)]

I installed the 32bit version of Intrepid on my Dell laptop (fresh install). It's exhibiting the same problems but much worse. The PPTP tunnel is unusable. This all worked at one point during the alpha phase. Wish I find my install CD's so I could determine at what point it broke. Here is an excerpt of the syslog file:

Nov 2 20:43:21 john00-laptop pptp[6626]: nm-pptp-service-6621 log[decaps_gre:pptp_gre.c:414]: buffering packet 82 (expecting 80, lost or reordered)
Nov 2 20:43:23 john00-laptop pptp[6626]: nm-pptp-service-6621 log[decaps_gre:pptp_gre.c:414]: buffering packet 85 (expecting 84, lost or reordered)
Nov 2 20:43:24 john00-laptop pptp[6626]: nm-pptp-service-6621 log[decaps_gre:pptp_gre.c:414]: buffering packet 91 (expecting 90, lost or reordered)
Nov 2 20:43:24 john00-laptop pptp[6626]: nm-pptp-service-6621 log[decaps_gre:pptp_gre.c:414]: buffering packet 92 (expecting 90, lost or reordered)
Nov 2 20:43:24 john00-laptop pptp[6626]: nm-pptp-service-6621 log[decaps_gre:pptp_gre.c:414]: buffering packet 95 (expecting 94, lost or reordered)
Nov 2 20:43:30 john00-laptop pptp[6626]: nm-pptp-service-6621 log[decaps_gre:pptp_gre.c:414]: buffering packet 98 (expecting 97, lost or reordered)
Nov 2 20:43:39 john00-laptop pptp[6626]: nm-pptp-service-6621 log[decaps_gre:pptp_gre.c:414]: buffering packet 114 (expecting 109, lost or reordered)
Nov 2 20:43:46 john00-laptop pptp[6626]: nm-pptp-service-6621 log[decaps_gre:pptp_gre.c:414]: buffering packet 122 (expecting 118, lost or reordered)
Nov 2 20:43:47 john00-laptop pptp[6626]: nm-pptp-service-6621 log[decaps_gre:pptp_gre.c:414]: buffering packet 123 (expecting 118, lost or reordered)
Nov 2 20:43:47 john00-laptop pptp[6626]: nm-pptp-service-6621 log[decaps_gre:pptp_gre.c:414]: buffering packet 130 (expecting 129, lost or reordered)
Nov 2 20:43:47 john00-laptop pptp[6626]: nm-pptp-service-6621 log[decaps_gre:pptp_gre.c:414]: buffering packet 131 (expecting 129, lost or reordered)

[John (john-navarro)]

OK, I figured out what is goin on here. The difference between Hardy and Intrepid PPTP connections is that with Hardy the MTU is automatically set to 1416 during tunnel creation; this does not happen with Intrepid. I tested this hypothesis within Intrepid by issuing "sudo ifconfig ppp0 mtu 1416" after the tunnel was created and performance matches that of Hardy. The error messages in syslog have stopped as well. Here are the pptp startup parameters on both platforms:

INTREPID 32bit
root 8459 8458 0 21:12 ? 00:00:00 /usr/sbin/pppd pty /usr/sbin/pptp a.b.c.d --nolaunchpppd --logstring nm-pptp-service-8458 ipparam nm-pptp-service-8458 nodetach lock usepeerdns noipdefault require-mppe-128 nobsdcomp nodeflate novj lcp-echo-failure 5 lcp-echo-interval 30 plugin /usr/lib/pppd/2.4.4/nm-pptp-pppd-plugin.so

HARDY 32bit
root 7060 1 0 21:45 ? 00:00:00 /usr/sbin/pppd pty /usr/sbin/pptp a.b.c.d --nolaunchpppd remotename a.b.c.d ipparam NetworkManager usepeerdns require-mppe-128 nodeflate nobsdcomp lock noauth mtu 1416 mru 1416 lcp-echo-failure 10 lcp-echo-interval 10 plugin nm-pppd-plugin.so

[Alexander Sack (asac)]

where does that 1412 MTU value come from ... is that something set for all VPNs or is that information exported/negotiated by the vpn server or something?

[Alexander Sack (asac)]

moving to master bug.

[John (john-navarro)]

1416 is a default value set by Hardy - you can change it, but I left it at the default. The value can be seen in the nm-applet 0.66 Edit VPN Connections Menu under PPP Options. There under the Packet Parameters section you will see the MTU fields.

> From: <email address hidden>
> To: <email address hidden>
> Date: Mon, 3 Nov 2008 10:43:09 +0000
> Subject: [Bug 292799] Re: Intrepid Slow PPTP Performance - retransmits and lost ACKs
>
> *** This bug is a duplicate of bug 258743 ***
> https://bugs.launchpad.net/bugs/258743
>
> where does that 1412 MTU value come from ... is that something set for
> all VPNs or is that information exported/negotiated by the vpn server or
> something?
>
> ** Changed in: network-manager-pptp (Ubuntu)
> Status: New => Incomplete
>
> --
> Intrepid Slow PPTP Performance - retransmits and lost ACKs
> https://bugs.launchpad.net/bugs/292799
> You received this bug notification because you are a direct subscriber
> of the bug.

_________________________________________________________________
Get more out of the Web. Learn 10 hidden secrets of Windows Live.
http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!550F681DAD532637!5295.entry?ocid=TXT_TAGLM_WL_domore_092008

[Petzl (petzl)]

Solved my PPTP problem with :

sudo ifconfig ppp0 mtu 1416

it only happens if i am connected from the router at my home, if using HSDPA card i have no problems

home router : monowall
work router : monowall

Problem not solved after network manager update 03-12-2008

i also had a problem with saving pptp passwords this is solved afther update on 03-12-2008

[Alexander Sack (asac)]

Petzl wrote:
> *** This bug is a duplicate of bug 258743 ***
> https://bugs.launchpad.net/bugs/258743
>
> Solved my PPTP problem with :
>
> sudo ifconfig ppp0 mtu 1416
>
> it only happens if i am connected from the router at my home, if using
> HSDPA card i have no problems
>
> home router : monowall
> work router : monowall
>
> Problem not solved after network manager update 03-12-2008
>
> i also had a problem with saving pptp passwords this is solved afther
> update on 03-12-2008
>
>
Is this issue fixed in latest packages available in
http://launchpad.net/~network-manager/+archive PPA?

[John (john-navarro)]

No - the latest packages don't provide a PPTP MTU settting withing NM.

[Whitehat (i-whitehat)]

Have the same thing in 9.10 :(
In Windows I have about 15mbits through pptp, and in ubuntu - only 3
syslog is spammed by:
Nov 19 23:44:16 invader pptp[5965]: nm-pptp-service-5591 log[decaps_gre:pptp_gre.c:414]: buffering packet 11148 (expecting 11142, lost or reordered)
Nov 19 23:44:16 invader pptp[5965]: nm-pptp-service-5591 log[decaps_gre:pptp_gre.c:414]: buffering packet 11149 (expecting 11142, lost or reordered)
Nov 19 23:44:16 invader pptp[5965]: nm-pptp-service-5591 log[decaps_gre:pptp_gre.c:414]: buffering packet 11150 (expecting 11142, lost or reordered)

I set MTU 1416, 1500, 1300, 1400 and even 150 with "sudo ifconfig ppp0 mtu ****" - no affect