Date: Mon, 29 Jan 2007 12:43:35 +0200 From: Nikos Vassiliadis <nvass@teledomenet.gr> To: Alexander Motin <mav@alkar.net> Cc: net@freebsd.org Subject: Re: ng_pptpgre problems: tcp connections reset unexpectedly Message-ID: <200701291243.36380.nvass@teledomenet.gr> In-Reply-To: <45BABDE2.4010503@alkar.net> References: <1169850194.00677461.1169839202@10.7.7.3> <45BABDE2.4010503@alkar.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 27 January 2007 04:50, Alexander Motin wrote: > 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. Perfect points, it would be very unfair to ask you such a thing. I use mpd3 cause it's what was available in ports at the time of the installation. I already have an mpd4 installation working, but had some problems using pptp with it. I will try again with the RC you just released. > > > 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. 1) > delayed-ack enable > always-ack disable > windowing enable failed 2) > delayed-ack enable > always-ack enable > windowing enable failed 3) > delayed-ack disable > always-ack enable > windowing enable failed 4) > delayed-ack disable > always-ack enable > windowing disable seem to work, sometimes it's not that easy to reproduce the problem. > > > 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 <nop,nop,timestamp 50979088 694225824> > > 11:31:40.797294 IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20696745 win 32476 <nop,nop,timestamp 694225916 50979088> > > 11:31:40.797697 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20696745:20698157(1412) ack 1 win 5792 <nop,nop,timestamp 50979088 694225824> > > 11:31:40.797780 IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20698157 win 33182 <nop,nop,timestamp 694225916 50979088> > > 11:31:40.798589 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20698157:20699569(1412) ack 1 win 5792 <nop,nop,timestamp 50979089 694225826> > > 11:31:40.798739 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20699569:20700981(1412) ack 1 win 5792 <nop,nop,timestamp 50979089 694225826> > > 11:31:40.798748 IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20700981 win 32476 <nop,nop,timestamp 694225917 50979089> > > 11:31:40.798877 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20700981:20702393(1412) ack 1 win 5792 <nop,nop,timestamp 50979089 694225826> > > 11:31:40.798924 IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20702393 win 33182 <nop,nop,timestamp 694225917 50979089> > > 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 <nop,nop,timestamp 50979098 694225914> > > 11:31:40.887859 IP 134.76.12.3.56123 > 213.142.137.253.64016: P 20703805:20705217(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225914> > > 11:31:40.888005 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20705217:20706629(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225914> > > 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. To complicate things a bit more sftp over the same the link works reliably (different sockopts?). http fails, ftp fails but sftp works as usual. Eventually a read(2) fails: 1794 fetch CALL read(0x3,0x8057730,0xd0) 1794 fetch RET read -1 errno 60 Operation timed out > Is it the same machine where fetch and tcpdump running? Yes. > Wasn't there some kind of time synchronization or NAT restart or some other external event? There is no NAT involved. But i had the feeling that routers load is relevant. That's because there was no problem when some of the clients where moved to a second router and the router I am conne- cting to became less loaded. I also have to add that the router is two hops away, and I think the reliability of the link is quite good. It seems to work with disabled windowing. If you are interested in tracking down this, I would be glad to help. Thanks, Nikos
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200701291243.36380.nvass>