On Jun 14, 2004, at 05:08, Jon Adams wrote:
My network connectivity is ridiculously slow... I had OpenSSH timeout set to
the default, 120 secs, and the messages file said the connections (on the same
100MBPs hub mind you) were timing out before authentication (password). I went
in and doubled the timeout, and after a long wait (I didnt check the time) I
could get a password prompt... at first I thought this was just a SSH problem,
but it is the same if I use telnet (or any other network service). I have
several devices on my Lan including 2 (eww) Windows XP laptops, and a PS2 and a
XP workstation. I have 3 public IPs, (Speakeasy is the ISP) The laptops use a
LinkSys 54G Wireless Hub and one public IP (its plugged into a NetGear 4 port
hub), I split another IP with the Desktop and PS2, and the FreeBSD box will
have its own IP, of course the final port is the uplink. There are absolutly
no connectivity problems with the other machines. The FreeBSD box cannot
connect to the dns servers (on three different networks) or much of anything
else.
Here is the really weird part, when I run an NMAP scan from inside the network
and one from outside the network, the box is reachable (NMAP can see the ports
and determine the OS), but nothing can connect to it (all connections time out).
If you can ping devices by ip address, you have basic connectivity. Start with the local interface itself, then devices on the same physical network, then devices on other subnets of the local LAN. Any of these local devices should respond in single-digit milliseconds, with perhaps a drop of the first ping packet. If you get "no route to host" messages, or other total failure messages, check for correct/consistent subnet masking on all devices involved, or potential firewall blocking (if appropriate to configuration). If you get poor response (high dropped packet percentage, excessive delays), check for port speed/duplex matching problems or bad cabling.
Assuming basic connectivity, many application timeout issues in Unix systems result from either forward or reverse name resolution failure. It can be frustrating to resolve, generally hard-coding the host and FQDN entries in the local hosts file and with the hostname utility is a good debugging step.
KeS
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
