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 _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
