From owner-freebsd-net@FreeBSD.ORG Sat Jan 27 03:50:18 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E71816A4A6 for ; Sat, 27 Jan 2007 03:50:18 +0000 (UTC) (envelope-from mav@alkar.net) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 0C99E13C48D for ; Sat, 27 Jan 2007 03:50:16 +0000 (UTC) (envelope-from mav@alkar.net) Received: from [195.248.178.122] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.0.11) with ESMTPA id 20211520; Sat, 27 Jan 2007 04:50:15 +0200 Message-ID: <45BABDE2.4010503@alkar.net> Date: Sat, 27 Jan 2007 04:50:10 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nikos Vassiliadis References: <1169850194.00677461.1169839202@10.7.7.3> In-Reply-To: <1169850194.00677461.1169839202@10.7.7.3> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: ng_pptpgre problems: tcp connections reset unexpectedly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 03:50:18 -0000 Hi. Nikos Vassiliadis wrote: > It seems that tcp connections over pptp reset unexpectedly. I have > tried several things such as connecting from a FBSD-4 to a FBSD-6, > connecting from a FBSD-[46] to a Cisco router(*). There are times which > the client box gets from the other peer an echo-request msg, which is > not supposed to happen while downloading. Perhaps it's relevant to > this: > > (*) the result is always the same. > > What i have not tried, is a newer mpd, Alexander Motin seems to > maintain mpd very actively, he sends a patch every 5 minutes or so:) > I am using at the moment 6.2-PRE, just a few days before RELEASE, > and mpd-3.18_4. Actually I have spent so much time working on mpd4 that I dont like to even hear about some problems in ancient mpd3. :) There so much work was done in mpd4 that it is mostly pointless to debug something in mpd3. > Could you please help? any workarounds, tunables, suggestions? > It's my connection to the internet and from time to time I need > to download something bigger than a few megs... I do not use pptp actively, to say for sure, but you can try to play with such pptp options like delayed-ack, always-ack and windowing. > Thanks in advance, Nikos > > root:2:~/tst1# fetch ftp://ftp2.de.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/6.2/6.2-RELEASE-i386-disc1.iso; date > 6.2-RELEASE-i386-disc1.iso 3% of 573 MB 185 kBps 50m56s > fetch: transfer timed out > fetch: 6.2-RELEASE-i386-disc1.iso appears to be truncated: 20702208/601229312 bytes > Fri Jan 26 11:31:40 EET 2007 > tcpdump.ng0: > 11:31:40.797285 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20695333:20696745(1412) ack 1 win 5792 > 11:31:40.797294 IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20696745 win 32476 > 11:31:40.797697 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20696745:20698157(1412) ack 1 win 5792 > 11:31:40.797780 IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20698157 win 33182 > 11:31:40.798589 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20698157:20699569(1412) ack 1 win 5792 > 11:31:40.798739 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20699569:20700981(1412) ack 1 win 5792 > 11:31:40.798748 IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20700981 win 32476 > 11:31:40.798877 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20700981:20702393(1412) ack 1 win 5792 > 11:31:40.798924 IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20702393 win 33182 > 11:31:40.859025 IP 213.142.137.253.64016 > 134.76.12.3.56123: R 1:1(0) ack 20702393 win 33182 > 11:31:40.887739 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20702393:20703805(1412) ack 1 win 5792 > 11:31:40.887859 IP 134.76.12.3.56123 > 213.142.137.253.64016: P 20703805:20705217(1412) ack 1 win 5792 > 11:31:40.888005 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20705217:20706629(1412) ack 1 win 5792 Looking here I can see that it is your local machine (213.142.137.253) sent "R" - Reset request just after normal acknowledge packet. I don't see the reason for such it's behaviour. Is it the same machine where fetch and tcpdump running? Wasn't there some kind of time synchronization or NAT restart or some other external event? -- Alexander Motin mav@alkar.net Optima Telecom