Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 Dec 2000 00:17:33 -0800
From:      "Crist J . Clark" <cjclark@reflexnet.net>
To:        Peter Wemm <peter@netplex.com.au>
Cc:        freebsd-chat@FreeBSD.ORG
Subject:   Re: CVSup Problems
Message-ID:  <20001205001732.D99903@149.211.6.64.reflexcom.com>
In-Reply-To: <200012040909.eB4993D55119@mobile.wemm.org>; from peter@netplex.com.au on Mon, Dec 04, 2000 at 01:09:03AM -0800
References:  <20001203214209.A99903@149.211.6.64.reflexcom.com> <200012040909.eB4993D55119@mobile.wemm.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 04, 2000 at 01:09:03AM -0800, Peter Wemm wrote:
> "Crist J . Clark" wrote:
> > There was a thread that found its way on to here the other day. The
> > topic was how easy and low-bandwidth CVSup is to use with people
> > making statements like, "5 minutes on a dial-up link," to CVSup an
> > existing source tree.
> > 
> > I once would have agreed, but I have been having a really frustrating
> > time with CVSup. I am hoping someone can help me debug this.

[snip]

> I have seen strange cvsup stuff in the recent past that was solved by using
> the "-Pa" (active mode) or "-P-" (passive mode).

Since I'm behind by ipfw(8), I always explicitly tell it to run
passive, '-P-'.

> The other thing to try is to do something like this:
> 
> route change default -lock -mtu 1400
> and/or
> route change cvsup11.freebsd.org -lock -mtu 1400
> 
> You can try lower numbers, down to say 500..

Yeah, I have tried that. Things seem to get a little farther
sometimes, but it still usually times out.

> The interesting thing is that the cvsup client mostly *uploads* data, which
> is in the opposite direction to usual ISP dialup traffic.  This means you
> can run into outbound problems that you didn't know you had, eg: a silent
> MTU problem.
> 
> Anyway, there are a couple of ideas to try.

I just ran it with a 1000 MTU, and it got past src-gnu which is the
other toughie besides src-contrib. But I wonder if the problem isn't
this,

  # tcpdump -nvv src host cvsup11.freebsd.org
  tcpdump: listening on fxp0
  00:12:38.149999 63.87.62.77.5999 > 64.6.211.149.3860: . 873996964:873996964(0) ack 818321386 win 17520 (DF) (ttl 54, id 12958)
  00:12:38.372235 63.87.62.77.5999 > 64.6.211.149.3860: . 0:0(0) ack 1921 win 17520 (DF) (ttl 54, id 12959)
  00:12:38.497451 63.87.62.77.5999 > 64.6.211.149.3860: P 0:55(55) ack 2881 win 17520 (DF) (ttl 54, id 12961)
  00:12:38.668107 63.87.62.77.5999 > 64.6.211.149.3860: P 55:620(565) ack 2881 win 17520 (DF) (ttl 54, id 12964)
  00:12:38.669711 63.87.62.77.2436 > 64.6.211.149.3861: P 877097933:877098029(96) ack 820899035 win 17520 (DF) (ttl 54, id 12965)
  00:12:38.783758 63.87.62.77.2436 > 64.6.211.149.3861: P 96:188(92) ack 687 win 17520 (DF) (ttl 54, id 12967)
  00:12:38.991456 63.87.62.77.2436 > 64.6.211.149.3861: P 188:1111(923) ack 687 win 17520 (DF) (ttl 54, id 12968)

Why does it insist on setting the DF bit? But this is downstream and
that does not seem to be the likely problem.

Oh well.
-- 
Crist J. Clark                           cjclark@alum.mit.edu


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001205001732.D99903>