Re: fetch hangs on 6/24/04 current build

On 25-Jun-2004 Jon Noack wrote:
> On 06/24/04 23:09, Conrad J. Sabatier wrote:
>> I just upgraded both of my machines today, and since then, I'm
>> getting lots of hangs during port fetches.  I don't know if this
>> is just a local problem, or a problem with my ISP's routing, or what.
>> 
>> Any recommendations on how to diagnose what's going on here?
> 
> This happened to me a week or so ago -- the workaround for me was to
> not set the FTP_PROXY and HTTP_PROXY environment variables.  When I
> tried to use a proxy, it hung; without, everything worked fine.  By
> the way, wget worked fine even with the proxy, so it was just fetch
> that was misbehaving.  Note that I was just starting to define those
> variables when I noticed the problem; I can't say from experience
> that fetch ever worked properly with a proxy...

OK, well, that's one thing we can rule out, since I'm not using a
proxy, neither local nor remote.  :-)

I tried switching to wget, using "FETCH_CMD=wget -v -c" in
/etc/make.conf, and got the most bizarre behavior, something I've never
seen before.  wget would fail each time, complaining about "invalid
option --".  Very strange.

> If you're not using a proxy, there was a recent commit to fetch that 
> could have broken things for you:
> http://lists.freebsd.org/pipermail/cvs-src/2004-June/026022.html
> 
> This just changed the behavior of -S (checking the size); do you see
> a "size unknown" error message before the hang?  In any case, you
> could try to back out rev. 1.68 and recompile fetch.

It's not that, either.  Tried it with and without the above patch. 
Same deal.

> Speculation:
> There's a lot going on in networking right now.  ipf 3.4.35 landed 
> recently -- this could be related to that.  As I don't use ipf I'm
> not sure of a workaround.

That's a definite possibility.  ipf *was* even causing kernel panics at
boot, until Giorgos Keramidas provided a patch.

> Gross speculation at this point:
> Something else you could try is disabling SACK (it just landed a
> couple days ago).  To do that just 'sysctl net.inet.tcp.sack.enable=0'
> and try again.  However, the SACK implementation came from Yahoo.  I
> would bet it's been tested fairly well and doubt that it is to
> blame...

Hey, ya never know, right?  :-)  At this point, I'm willing to try just
about anything.
 
> I'm sure someone else more knowledgeable can provide better answers. 
> These are just my (hopefully not humorously) ignorant guesses.

Yet another possibility: my ISP (Cox Communications).  Late last night,
my digital cable TV went out completely.  I'm guessing they were doing
some major upgrades somewhere.  Perhaps it was related to that.  The
TV's back on this morning, and I notice a few channels that I *was*
having trouble with (picture/sound breaking up, getting all "blocky")
are looking good now, so it's not entirely out of the question that it
had nothing to do with FreeBSD at all.  I'll have to try some ports and
see how it goes.

Still, I have no idea why wget acted so weird; it's never done that
before.

I should mention I'm running amd64 here, gatewayed through an i386
(Athlon) box.

Thanks for the feedback; appreciate it.

-- 
Conrad J. Sabatier <conrads_at_cox.net> -- "In Unix veritas"