[PLUG] Browser Blues - Continued

Keith Lofstrom keithl at kl-ic.com
Sat Mar 18 16:28:03 UTC 2006


On Fri, Mar 17, 2006 at 06:09:45PM -0800, William A Morita wrote:
> 
> I have an Actiontec GT701-WT DSL Modem/Router with Qwest DSL service.
> I tried power cycling the DSL Modem/Router.  No Help.
> I tried plugging the network cable into the second network interface.  
> The idea being that a new MAC address would force the DHCP to generate
> a new IP.
> New IP address, but this did not change the problem, so it is likely
> not the DHCP.
> I am out of things to try,
> I am open to suggestions

Bill:

In general, you seem to be "trying things" and not "gathering data".
There are too many things that can be misconfigured, and chances are
you will be taking a random walk that diverges from a solution.  There
is not enough time in the universe to try all the different possible
combinations.

I do not use the later Fedora Cores - they are far too experimental
and much too unsupported to work with for people with my limited
experience and limited available time.  A better time investment
might be made in Ubuntu, or SUSE, or one of the many RHEL4 clones,
so that you are not dealing with a science project.  I won't go
into the differences between the three alternatives I suggest (and
there are many more good alternatives besides) but they are all
rather different but competent ways to approach the "Linux Problem",
and they are all much more finished products than Fedora Core.

That said, you are now trying to follow the "Fedora" path, and since
that shares some history with the Fedora Cores 1 and 2, Redhat 9,
and RHEL4 systems I am used to, so I will try to steer you from that
perspective.  

First, /var/log/messages is your friend.  Just about everything you
are doing will leave traces there.  You should be using "ifconfig"
to see what interfaces you are using, and what the net masks and
gateways are.  "route -n" will tell you other things about your
connection.  /etc/resolv will tell you what the "ifup" and dhcp
processes decided your name servers are.  iptables -L will tell
you about what is firewalled off.  You should be using something
like tcpdump or ethereal if the aforementioned tools don't tell
you enough, though debugging at the packet level is painful.

And of course the outputs of all of these diagnostics (and many
others) from *working* systems in similar circumstances, compared
to your outputs, will be instructive.

One good source of "working" would be a Knoppix or an Ubuntu Live
CD.  These are pretty good at connecting to a network, and they
can be started without a firewall because there is nothing for the
bad guys to rewrite.  You are not doing this as a "try something",
you are doing this to gather data about a working connection. 
Unfortunately, since both of those are Debian based, you will need
to do a lot more abstracting of data from a different set of
configuration files than the Redhat family, and since they are
live CDs not all the logging will be in place.  

The key to debugging a problem is to start with a working system and
change one thing and see what it does.  Once you understand all the
aspects of your change, you are ready to change another thing.  Changing
two or more things at once is a recipe for confusion and failure.  And
while it is working, write down important observations ( network 
configuration, DNS server addresses, a few numeric IP addresses of
test targets) so that you have something to work with when things
go wrong - and they will.

There are so many things that can go wrong with a network connection,
and with a bleeding-edge experimental distro, and with buttheaded
windoze-tunnel-vision service providers and hardware designs, that
you are very unlikely to land on top of an island of working solutions
if you dive randomly into the ocean.  You will have to do some 
navigation, and more importantly you will have to first prove to
yourself that an island actually exists.  That is what the rest of us,
and Google, can help you with;  duplicate the coordinates of somebody
elses dry land, and strike out from there.  That may involve a
different distro, cable modem, DSL provider, etc.  It may even involve
starting with a borrowed windoze system on your DSL line to see
whether that can connect properly.  At least you will be able to talk
to the windoze-addled service reps at your DSL service if the windoze
box doesn't work.

One last note about internet services;  I don't know how it works for
the various DSL providers, but Comcast wants to talk to a specific
MAC address on the other side of the cable modem.  In my case, they
talk to a particular PCMCIA ethernet card on my laptop router.  If 
I get the cards mixed up, Comcast won't talk to me any more.  The
same could be true for you.

Try bringing your box into the Linux Clinic at Free Geek tomorrow. 
If the network connection is running, we can see if your box works
with your ISP and your DSL modem out of the equation, and compare 
log files with a working RH-style system, such as my laptop.

Keith

-- 
Keith Lofstrom          keithl at keithl.com         Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs



More information about the PLUG mailing list