Newbie Issues (networking w/ FreeBSD)

[Kevin Stevens]

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