From owner-freebsd-net Sat Sep 21 18: 5:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B30B37B401 for ; Sat, 21 Sep 2002 18:05:43 -0700 (PDT) Received: from phalanx.trit.org (phalanx.trit.org [63.198.170.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB85C43E6A for ; Sat, 21 Sep 2002 18:05:42 -0700 (PDT) (envelope-from dima@trit.org) Received: from phalanx.trit.org (localhost [127.0.0.1]) by phalanx.trit.org (Postfix) with ESMTP id AB18ED576 for ; Sun, 22 Sep 2002 01:05:42 +0000 (UTC) To: net@freebsd.org Subject: Latency spike over VPN using SSH (delayed ack problem) Date: Sun, 22 Sep 2002 01:05:42 +0000 From: Dima Dorfman Message-Id: <20020922010542.AB18ED576@phalanx.trit.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have a VPN setup where the client opens an SSH connection to the VPN router and runs "ppp -direct client-vpn" (i.e., I'm tunneling a PPP connection over SSH). My configuration looks very similar to the example of how to do this in share/examples/ppp/ppp.conf.sample. Now, there are three computers: C is the VPN client, R is the VPN router, and S is a server on the other side of the VPN. After establishing a VPN connection, if I SSH from C to S and run "ping C", the first response time will be ~190 ms more than it should be. Note that this *only* happens if I connected *from* C to S and *then* run ping; if I connect to S in another way and run ping, the latency spike isn't present (I'm not sure how or if this is relevant, but I thought I'd add it anyway). C and R are usually connected over 801.11b (wireless), but the symptoms are present regardless of how they're connected (I've tried fast ethernet and WAN (Internet)). Originally I suspected the "Secure" (CPU-intensive crypto) part of SSH and PPP compression, but neither of these helped; I turned off all PPP compression and replaced ssh with rsh, and the problem remained. Now, if I turned off delayed acks on C xor R, the latency spike drops to ~95 ms. If I turn it off on C *and* R, the latency spike disappears--hence the "delayed ack problem" part of the subject. Just for reference, here's what the symptom looks like *with* delayed acks: dima@SERVER% ping CLIENT PING CLIENT (192.168.4.193): 56 data bytes 64 bytes from 192.168.4.193: icmp_seq=0 ttl=63 time=193.025 ms 64 bytes from 192.168.4.193: icmp_seq=1 ttl=63 time=3.376 ms 64 bytes from 192.168.4.193: icmp_seq=2 ttl=63 time=3.420 ms 64 bytes from 192.168.4.193: icmp_seq=3 ttl=63 time=4.003 ms 64 bytes from 192.168.4.193: icmp_seq=4 ttl=63 time=5.393 ms ^C --- CLIENT ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 3.376/41.843/193.025/75.594 ms Note also that this isn't just for ICMP; the spike can occasionally be "felt" in interactive sessions. Now, my question is: Is this a known bug, and if it is, is there a fix? If someone wants tcpdumps, just let me know where (on which machine), on what (which interface--do you want to see the ICMP packets (inside the tunnel) or the SSH packets (outside the tunnel)), and when to run them. Thanks in advance, Dima. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message