ng_pptpgre problems: tcp connections reset unexpectedly

Mon Jan 29 10:40:26 UTC 2007

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