Subject: Really large latencies and netstat problems after upgrading to 1.5
To: None <netbsd-help@netbsd.org>
From: Nathan Arthur <truist@truist.com>
List: netbsd-help
Date: 01/17/2001 21:53:20
I am running NetBSD 1.5, upgraded from 1.4.2 a few weeks ago. In the
intervening time, I have updated my /etc to have all my old modifications in
it, and recompiled everything I had installed in pkgsrc. I have played with
my dns configuration a bit in the meantime, however I believe that nothing
of significance is changed (but I don't really understand the ipv6 bits).
My machine has the static ip 64.32.145.41, on which I host truist.com. I
have one internal computer set up, and am have reverse dns forwarded from my
ISP. This is over a DSL line.
My problem is that I can't seem to use a connection to or from any machine
which is not local (10.0.0.*) without massive delays before the initial
response, and then sometimes fast responses, and sometimes more delays after
the response starts.
I noticed this a while ago when it was taking 10 minutes do download my
mail, when it usually takes seconds. I also can't seem to access (nor can
anyone else) the web pages or ssh connections quickly at all. I have
fiddled with a number of things, like the dns settings and firewall rules
(turning them off doesn't seem to work). I am aware that my firewall rules
are perhaps a little flaky (they are a "first draft"), but they didn't
change across the upgrade.
I just recently discovered that "netstat -a" seems to behave oddly whenever
I have a connection to an outside host (outside of my 10.0.0.* network). It
gives a few lines, then pauses for a long time, then says:
netstat: kvm_read: Bad address
then displays a few more lines, then says:
???
as one of the lines, then finishes normally. If I don't have an outside
connection, netstat works perfectly.
Any ideas? I am not even sure how to proceed from here. If you want my
filter rules I can send those privately, or I can quickly provide the
outputs of netstat and anything else (as long as I am at the machine - from
remote locations, things get tricky).
Thanks!
Nathan Arthur