In your own words, it "sees the router and connects".
I think that means you saw the SSID of the router, and
that means a signal was picked up.
A typical PC is set for automatic connections. To do that,
it uses DHCP protocol. The router will have a DHCP server,
while the netbook is a DHCP client. If you selected manual
connection properties, in the netbook network control panel,
then DHCP would not be used. You could assign a static
address for the netbook, you could give it the IP address
of a DNS server, and then it could translate "
www.sun.com"
into "201.115.22.33" format, using the DNS server.
So when you use DHCP, it does the same kind of things, only
it gets the necessary info from the router automatically. Since
the "yellow wire" test passed, that means the router knows
where the DNS server is. The router "gave" the DNS address
to the netbook, over the yellow wire. The router also
"gave" the netbook, an IP address to use, for local usage
(i.e. netbook has an address like 192.168.1.2 or 10.0.0.2,
that sort of thing).
OK, so you can try some tests.
1) Try your Wifi thing.
2) Go to command prompt.
Do "ipconfig" as a command. (Don't enter the double quotes!)
See if you got an IP address, like 192.168.1.2 type.
That helps prove DHCP gave a local IP address to use.
3) While still in command prompt, try
"nslookup
www.sun.com"
If the Wifi DNS info is valid, it should return 156.151.59.35
The server field may or may not be valid, as reverse translation
of the gateway doesn't always work.
If (2) passes, you can go to your web browser and try
http://156.151.59.35
You should see a web page for Oracle company (which bought
Sun Microsystems). That basic test, proves the connection
from netbook to Internet is working.
The second browser test is
http://www.sun.com
For that URL to work, the browser needs to consult DNS,
and do a DNS translation, just like the nslookup command did.
So if (3) passes, then
http://www.sun.com should work, and
give the exact same Oracle web page. If (3) fails, then the
http://www.sun.com browser test will fail too.
The network connection consists of two parts. The ability to
route a packet and a response, between the two endpoints.
That relies on numeric IP addresses. The DNS capability,
is there so a user can enter "convenient"
sun.com type
symbolic addresses, and rely on DNS to translate them
into the numbers that really make it work. We need to
test both, to get some idea what parts are working.
For many people, when the DNS is broken (but the
transport of packets is still working), they say
the "connection is broken", when all that is broken
is the translation of
www.sun.com into 156.151.59.35.
Back when I had a particularly crappy ISP, DNS was broken
a lot on their end. I actually used to keep a piece of
paper, with
http://156.151.59.35 on it, so I could
visit
www.sun.com . That was the idea, of keeping some
DNS translations on paper. In addition, I even had
some alternate DNS server addresses I could type in
manually, and by doing that, I could bootstrap around
the mess at my ISP.
*******
In this article, some well-known DNS translation servers
are listed. If you were using a static setup, no DHCP,
then you could tell your Windows PC to use 8.8.8.8 as
the address to consult for DNS translations. The Google
server is not particularly an "official" server - it would
have about the same properties as the thirty or forty
servers at my ISP. The advantage in this case, is the
number is easy to remember, if you ever need it.
http://en.wikipedia.org/wiki/Google_Public_DNS
The 8.8.8.8 goes in a dialog like this. In one of the
bottom entries.
http://www.mediacollege.com/computer/network/images/winxp-tcpip.gif
*******
Now, if you're not even getting that far, then you need to
look at some other control panel. Like, whatever control
panel you used to make the connection.
Paul