static IP configuration problem

[Benjamin Scott]

On Sep 22 at 11:41pm, Greg Rundlett wrote:
> recap: DHCP will work ...

   For starters, your mail program appears to be operating under the assumption 
that HTML email is a good idea.  While debating that in the general case is a 
bit outside the scope of this this group, it is certainly munging up your 
messages quite well in this specific case, as it tries to "help" by turning IP 
addresses into hotlinks, reformatting output, and other such things.  Could 
you please inhibit that behavior for this thread?  This is hard enough without 
software rewriting things for us.

> ... did not result in a working interface (that could get to the internet). 
> Apparently the interface is working, b/c I can ping other hosts on the 
> network, I just can't get out onto the web.

   Have you tried ping'ing hosts by name and by IP address in your tests? 
Browsing the web is a surprisingly complicated act; it's best to start small 
and build up.  Suggested steps:

   1. Try pinging your default gateway by IP address.

   1. a.  If that fails, you won't be reaching the Internet, but the problem 
might still be in a number of places.  Try pinging another host on your local 
network by IP address.  If that fails, too, the problem is almost certainly on 
the host you're testing from.  If that succeeds, you've got some kind of weird 
problem between the local host and the gateway (or the gateway is down).

   2. Trying pinging a host on the Internet by IP address.  I suggest 
132.177.132.99, which is the UNH main public web server.  The name and IP 
address are unlikely to change, it isn't a shared host, and it responds to 
ping.  If this fails (but step 1 succeeded), there is a problem in or past 
your gateway.

   3. Try pinging the same host as step 2, but use the name (www.unh.edu), 
rather then the IP address.  This will test DNS nicely.  If it fails but step 
2 succeeds, then you've got something breaking DNS -- either DNS itself, or 
connectivity to your resolver.  Check /etc/resolv.conf and see how things are 
configured.  You should see one or more name servers listed as IP addresses.

   3. a. Try pinging each name server by IP address.  Any failures indicate a 
misconfiguration or trouble that will likely affect all aspects of network 
usage.

   3. b. If you can ping all addresses, try sending some DNS queries manually. 
For example, if one of your name server IP addresses is 192.0.2.42, try the 
command "host a.root-servers.net. 192.0.2.42".  Try different names (e.g., 
"www.unh.edu") to see if some things work but others don't.  If you have 
multiple name server addresses, try the same queries on all of them. 
Timeouts indicate the nameserver is down or itself has connectivity issues. 
Inconsistencies between nameservers can be a serious problem, also.

   Let us know how far you get in the above list.

> ######### The /etc/network/interfaces file ###########
> auto lo
> iface lo inet loopback
> 
> auto eth0
> iface eth0 inet static
> address 192.168.1.111 <http://192.168.1.111>
> netmask 255.255.255.0 <http://255.255.255.0>
> gateway 192.168.1.15 <http://192.168.1.15>

   I believe the Debian /etc/interfaces file requires you to indent the 
sub-parameters of each "iface" stanza.  (A brief search could not find 
authoritative documentation on the web, and I don't have a Debian system handy 
to check.  Debian experts, please correct me if I'm wrong.)  In the above, 
everything is flush against the left margin.  This might just be a result of 
the HTML lossage I mentioned.  If not, you will probably need to fix that. 
I believe it should look like:

iface eth0 inet static
 	address 192.168.1.111
 	netmask 255.255.255.0
 	gateway 192.168.1.15

   The output of the various commands you've posted is also garbled due to 
HTMLization.  You're also changing too many things at once (e.g., reseting the 
router to factory defaults *and* switching your host to be a DHCP client, at 
the same time).  It's usually best to approach technical trouble 
scientifically.  You want to perform a set of tests, change one variable, 
repeat the tests (in exactly the same manner), and see what changed in the 
test results.  Keep repeating that process until you isolate the problem.  If 
you change multiple things at once, or don't perform the tests the same way, 
you can end up overlooking something important.  I speak from painful 
experience.  :-)

   From what I can decipher of the output you posted, things appear to be 
configured consistently at the IP network level (layer 3).  In other words, 
your interfaces and routes all make sense in and of themselves.  That's one of 
the reasons I suggest starting with low-level tests like "ping"; maybe the 
problem is higher up in the system.

   I should also ask: Do you have other hosts on this local network that are 
working properly?  We should make sure it isn't something like a bad hub or an 
over-zealous firewall that's causing trouble.

   Hope this helps,

-- 
Ben <dragonhawk at iname.com>