i'm keen to solve this problem, regardless of whether I reinstall..

my skills at network admin on a Mac are pretty limited too, so not sure
how to check on IP and DNS stuff. If I look under TCP/IP settings under
system preferences>network it is just select to 'Using DHCP' and doesn't
show any DNS settings.

yep, i can successfully ftp to ftp.nz.debian.org as anonymous. How would I
determine whether there is a proxying setting for gnome/kde that needs
changing?

just tried using apt-get and this hangs too..

cheers
Matt

> That's really interesting.  I think that there's something really odd
> happening here.  I am not so sure that a reinstall will fix this.  It's
> possible that there's some other subsystem getting in the way, but I'm
> bothered if I can think of what it might be.
>
> The address 10.1.1.1 seems to be a valid DNS server so I can't
> understand why it's not working for you.  I really recommend having a
> look at what your Mac thinks it's doing (IP and DNS wise) and go from
> there.
>
> Do you want to proceed debugging this or are you going to just
> reinstall?  If you can ping www.google.co.nz that makes me think that it
> should be working now.  Can you use a non web browser, like FTP to try
> out that?  If you can FTP to ftp.nz.debian.org as anonymous then the
> problem isn't so much in your DNS / IP setup and with your browser(s).
> Is it possible that there is a gnome / KDE environment setting on your
> box to do with proxying?
>
> Cheers,
> Michael.
>
> Matthew Whiting wrote:
>> but firefox and thunderbird still hang while trying to connect :(
>>
>>
>>> yep, the DNS Server is now set back to 10.1.1.1 despite me having
>>> previously set it to 192.168.1.1
>>>
>>> i can ping 10.1.1.1 and www.google.co.nz successfully.
>>>
>>> nslookup www.google.co.nz 10.1.1.1 gives:
>>>
>>> Server:  10.1.1.1
>>> Address: 10.1.1.1#53
>>>
>>> Non-authoritative answer:
>>> Name:  www.google.co.nz
>>> Address: 72.14.253.103
>>>
>>>
>>> Thanks
>>> Matt
>>>
>>>
>>>
>>>
>>>> On Wed, May 09, 2007 at 06:15:14PM +1200, Matthew Whiting wrote:
>>>>
>>>>> Results of ifconfig eth0:
>>>>>
>>>>> eth0  Link encap:Ethernet HWaddr 00:13:20:62:47:D4
>>>>> inet addr:192.168.1.102 Bcast:192.168.1.255  Mask:255.255.255.0
>>>>> inet6 addr: fe80::213:20ff:fe62:47d4/64 Scope:Link
>>>>> UP BROADCAST RUNNING MULTICAST  MTU:1500 Metric:1
>>>>> RX packets:38 errors:0 dropped:0 overruns:0 frame:0
>>>>> TX packets:70 errors:0 dropped:0 overruns:0 carrier:0
>>>>> collisions:0 txqueuelen:1000
>>>>> RX bytes:5320 (5.1KiB)  TX bytes:6399 (6.2 KiB)
>>>>>
>>>> The IP address 192.168.1.102 is completely acceptable since it is part
>>>> of
>>>> the
>>>> network range of the LAN you appear to be in.
>>>>
>>>>
>>>>> and route gives:
>>>>> Kernel IP routing table
>>>>> Destination   Gateway     Genmask       Flags   Metric   Ref   Use
>>>>> Iface
>>>>> 192.168.1.0   *           255.255.255.0 U       0        0     0
>>>>> eth0
>>>>> default       192.168.1.1 0.0.0.0       UG      0        0     0
>>>>> eth0
>>>>>
>>>> This is OK too.  It just says that you have one network on ethernet 0
>>>> and
>>>> it
>>>> is the default path for all network traffic.
>>>>
>>>>
>>>>> cat /etc/resolv.conf:
>>>>> nameserver 10.1.1.1
>>>>>
>>>> Back to this again?  Had you manually changed this to 192.168.1.1?  If
>>>> so,
>>>> then when you went "ifup eth0" I suspect that the DHCP server issued
>>>> you
>>>> with this nameserver and dhcpcd overwrote your old /etc/resolv.conf
>>>>
>>>> Can you ping 10.1.1.1?
>>>>
>>>>
>>>>> traceroute:
>>>>> bash: traceroute: command not found
>>>>>
>>>> Gah!  You need the package "traceroute" (can you believe it).
>>>>
>>>> Try this and post the results:
>>>>
>>>> nslookup www.google.co.nz 10.1.1.1
>>>>
>>>> If nslookup isn't installed then try this:
>>>>
>>>> dig @10.1.1.1 www.google.co.nz
>>>>
>>>> Basically, either one of those commands will tell you whether 10.1.1.1
>>>> is
>>>> really a nameserver that you can reach.  If you don't get an IP for
>>>> www.google.co.nz, then try the same commands but with 192.168.1.1
>>>>
>>>> If 192.168.1.1 is able to resolve www.google.co.nz then you need to
>>>> console to your Linksys and try to work out why it is issuing the DNS
>>>> server 10.1.1.1 instead of
>>>> 192.168.1.1
>>>>
>>>> Please post the outputs anyway.
>>>>
>>>> I wonder whether you have two DHCP servers on the LAN since I think
>>>> you
>>>> mentioned connecting a Linksys to another ADSL router.  I might be
>>>> mistaken,
>>>> but that could lead to some real confusion.  Anyway, if one host is
>>>> working
>>>> reliably and the other is not then it's harder to blame the network
>>>> itself
>>>> (but not an impossible scenario given the variability of OSs.
>>>>
>>>> Good luck!
>>>> Michael.
>>>>
>>>>
>>>>> cheers
>>>>> Matt
>>>>>
>>>>>
>>>>>> I stand by the config I posted earlier.
>>>>>>
>>>>>> Also, the manner of the problem you have reported could still be
>>>>>>
>>>>> explained
>>>>>
>>>>>> by misconfiguration in Firefox.  Is is possible that Firefox is
>>>>>>
>>>>> attempting
>>>>>
>>>>>> to contact a Proxy server?
>>>>>>
>>>>>> If you follow the instructions in my previous email then we can at
>>>>>>
>>>>> least
>>>>>
>>>>>> eliminate or prove some simple network problems.
>>>>>>
>>>>>> Regards,
>>>>>> Michael.
>>>>>>
>>>>>> On Wed, May 09, 2007 at 05:35:17PM +1200, Matthew Whiting wrote:
>>>>>>
>>>>>>> Before applying any of your suggestions after trying a few things
>>>>>>> my
>>>>>>> /etc/network/interfaces file now contains the following. How should
>>>>>>>
>>>>> I
>>>>>
>>>>>>> proceed to edit this?
>>>>>>> -------------------
>>>>>>> auto lo
>>>>>>> iface lo inet loopback
>>>>>>>
>>>>>>> mapping hotplug
>>>>>>> script grep
>>>>>>> map eth0
>>>>>>>
>>>>>>> iface dsl-provider inet ppp
>>>>>>> provider dsl-provider
>>>>>>>
>>>>>>> iface eth0 inet dhcp
>>>>>>>
>>>>>>> auto eth0
>>>>>>> -------------------
>>>>>>>
>>>>>>>
>>>>>>>> On Wed, May 09, 2007 at 12:47:07PM +1200, Nick Rout wrote:
>>>>>>>>
>>>>>>>>> On Wed, May 9, 2007 12:38 pm, Matthew Whiting wrote:
>>>>>>>>>
>>>>>>>>>>>> connecting fine using this apple iBook. No such luck with my
>>>>>>>>>>>>
>>>>>>> desktop
>>>>>>>
>>>>>>>>>>>> pc..
>>>>>>>>>>>> Its an xtra broadband connection and my machine is connected
>>>>>>>>>>>>
>>>>>>>>> physically
>>>>>>>>>
>>>>>>>>>>>> to
>>>>>>>>>>>> a port on a linksys wireless router which is connected to a
>>>>>>>>>>>>
>>>>>>> d-link
>>>>>>>
>>>>>>>>> adsl
>>>>>>>>>
>>>>>>>>>>>> router. What would be appropriate diagnostic tools to use to
>>>>>>>>>>>>
>>>>> suss
>>>>>
>>>>>>>>> out
>>>>>>>>>
>>>>>>>>>>>> what
>>>>>>>>>>>> is happening? Firefox tries to connect and times out. I'm not
>>>>>>>>>>>>
>>>>>>>>> familiar
>>>>>>>>>
>>>>>>>>>>>> enough with linux network admin tools to better determine the
>>>>>>>>>>>>
>>>>>>>>> problem..
>>>>>>>>>
>>>>>>>>>>> What is the output of
>>>>>>>>>>> ifconfig  -a
>>>>>>>>>>> route -n
>>>>>>>>>>> cat /etc/resolv.conf
>>>>>>>>>>>
>>>>>>>>>> ifconfig gives a bunch of details for eth0, lo and sit0. not
>>>>>>>>>>
>>>>> sure
>>>>>
>>>>>>> what
>>>>>>>
>>>>>>>>> to
>>>>>>>>>
>>>>>>>>>> look for here?
>>>>>>>>>>
>>>>>>>>> I was looking for the output in relation to eth0, which is the
>>>>>>>>>
>>>>> forst
>>>>>
>>>>>>>>> ethernet device. Posting the output of the command would have
>>>>>>>>>
>>>>> been
>>>>>
>>>>>>> fine.
>>>>>>>
>>>>>>>>>> route -n gives:
>>>>>>>>>> Destination  Gateway      Genmask        Flags  Metric  Ref
>>>>>>>>>>
>>>>> Use
>>>>>
>>>>>>>>> Iface
>>>>>>>>>
>>>>>>>>>> 192.168.1.0  0.0.0.0      255.255.255.0  U      0       0    0
>>>>>>>>>>
>>>>>>> eth0
>>>>>>>
>>>>>>>>>> 0.0.0.0      192.168.1.1  0.0.0.0        UG     0       0    0
>>>>>>>>>>
>>>>>>> eth0
>>>>>>>
>>>>>>>>> Weirdly there is no 127. route, but otherwise looks fine.
>>>>>>>>>
>>>>>>>> Can't remember ever seeing 127.0.0.1 in a "route -n".  Maybe
>>>>>>>>
>>>>> you're
>>>>>
>>>>>>>> thinking of "route -nC" Nick.
>>>>>>>>
>>>>>>>> Anyway, the absence of 127.0.0.0 is not important here.
>>>>>>>>
>>>>>>>>
>>>>>>>>>> cat /etc/resolve.conf gives:
>>>>>>>>>> nameserver 10.1.1.1
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> clearly wrong, your dns server won't be 10.1.1.1.
>>>>>>>>>
>>>>>>>> Not *clearly* wrong since the Linksys maybe issuing another one of
>>>>>>>>
>>>>> its
>>>>>
>>>>>>>> private IP interfaces as the DNS server address.  But yes,
>>>>>>>>
>>>>> 192.168.1.1
>>>>>
>>>>>>> is
>>>>>>>
>>>>>>>> likely to be a better bet. The PC can get to it because it's only
>>>>>>>>
>>>>> got
>>>>>
>>>>>>> one
>>>>>>>
>>>>>>>> default route - via 192.168.1.1 as it happens!
>>>>>>>>
>>>>>>>>
>>>>>>>>> Try changing this to 192.168.1.1 (if the router provides dns
>>>>>>>>>
>>>>>>> services)
>>>>>>>
>>>>>>>>> or
>>>>>>>>> the ip address of your isp's dns server if it doesn't.
>>>>>>>>>
>>>>>>>> If that doesn't work, try changing /etc/network/interfaces as
>>>>>>>>
>>>>> such:
>>>>>
>>>>>>>> --- Snip here
>>>>>>>> auto lo eth0
>>>>>>>> iface lo inet loopback
>>>>>>>>
>>>>>>>> iface eth0 inet dhcp
>>>>>>>>
>>>>>>>> mapping hotplug
>>>>>>>>        script grep
>>>>>>>>        map eth0
>>>>>>>>
>>>>>>>> iface dsl-provider inet ppp
>>>>>>>>        provider dsl-provider
>>>>>>>>
>>>>>>>> iface ppp0 inet ppp
>>>>>>>>        provider ppp0
>>>>>>>> --- Cut here
>>>>>>>>
>>>>>>>> Then do "ifdown eth0" and then "ifup eth0".
>>>>>>>>
>>>>>>>> Then do:
>>>>>>>>
>>>>>>>> host www.google.co.nz
>>>>>>>> arp -a
>>>>>>>> ifconfig eth0
>>>>>>>> route
>>>>>>>>
>>>>>>>> By the way, do you have a link light on your network card and on
>>>>>>>>
>>>>> your
>>>>>
>>>>>>>> Linksys?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Michael.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>>
>>
>>
>>
>
>



Reply via email to