Re: ng_pptpgre problems: tcp connections reset unexpectedly

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

Relevant Pages

  • Re: Remote access questions
    ... Terminal Service' but I have no luck when connecting from a computer outside ... Could there be a problem with the client settings? ... > Make sure your calling the correct public IP for the router. ... access them through a VPN tunnel on the default port for each. ...
    (microsoft.public.windowsxp.work_remotely)
  • Re: SSH not working
    ... This is often called Virtual Servers in router config. ... > of ssh) server and client I used the same strategy I tried for ssh. ... regularly tickle their server to grab your connecting internet IP. ...
    (alt.os.linux)
  • Re: Dynamic DNS
    ... I'm using DynSite as the client and i'm connecting to ZoneEdit. ... the router has the Dynamic DNS built in. ... > is likely that you need to open some ports on ISA. ...
    (microsoft.public.backoffice.smallbiz2000)
  • Re: Urgent! New router and big disaster
    ... it's quite possible you misconnected the nics when you put the server ... just File and Printer Sharing and the Microsoft Client ... running the internet connection wizard, ... I wonder if I may have missed a firewall setting on the router as well. ...
    (microsoft.public.windows.server.sbs)
  • Re: DI 624 revC- severe wireless latency after consistent throughput
    ... What radio are you using for a client? ... know is that the wall between the router and the client is drywall. ... >it's probably not some firmware anomaly but some form of interference. ...
    (alt.internet.wireless)