I hope this clears up most of the confusion.
> Yes, I do use pppoeconf to connect to the internet when using a wire. I
> assume you are talking about the wired connection now, yes?
Yes, but I don't see how you need pppoe on the wired connection and not the
That is precisely what I thought. So, I tried to use pppoeconf with the ath0. It didn't work; there was no internet connection at all.
The thing is, I don't believe you need to...
Why would (or wouldn't) I need to fix these leases? Are they specific to the connection type and therefore should be different?
> Certainly I have an internet connection, which "works".
Then what's your problem? All along you've been telling us you couldn't
access the Internet. If you can, it's a simple matter of automating the
method you're using. In this case, probably just uncommenting the wlan0
lines in /etc/network/interfaces and changing wlan0 to ath0.
If you have been interpreting what I say to mean I have no connection at all, I appologise. I know that I have stated quite clearly that the problem is a page will load (if at all) only after a very long period of time (which also goes for synaptic: Once it connects to the debian repositories, it works at the normal speed. The problem is connecting to the repositories at all.)
> Here is my theory. I think that the problem is in the search
being on top when connecting with the wireless.
No, it has nothing to do with anything. All the search domain does (I
already explained this) is add ".no-domain-set.bellcanada" to the end of
any DNS query your system makes to an unqualified domain (
e.g., "foo" as
opposed to "foo.bar"). Which means that, in all the cases you showed, it
does nothing useful (queries to unqualified domains would time out in half
the time, though, if you didn't have it at all).
Hence my theory. Since, when looking at the resolv.conf file it has the search bit first, I believe that it is adding this no-domain-set.bellcanada to the end of all queries and only if that doesn't work will it remove it. The nameserver should be listed first in a working connection (well, with this laptop, at my college the nameserver is first. It works perfectly there so I suspect that that should be the way of things). I also believe that this
no-domain-set.ballcanada business is not real, but rather is telling me that there is no domain that has been set.
$ cat /etc/resolv.conf
search no-domain-set.bellcanada <--