static IP configuration problem
Benjamin Scott
dragonhawk at iname.com
Sat Sep 24 18:07:00 EDT 2005
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>
More information about the gnhlug-discuss
mailing list