laptop shows connection is excellent, but I can't get on the internet

I have a wireless connectin to my laptop. I am using a DLINK 614+
router, with a DLINK DWL 650+ air card in my laptop. My laptop is
running Windows XP.

I have been able to get on the internet for about 6 months, up until
last week.
Then all of a sudden, I cannot connect with my laptop.

I also have my desktop connected directly to my cable modem. The
internet connection works fine for my desktop. But I cannot get my
laptop to open up any web pages.

The connection to my laptop shows "Excellent Connection". But when I
try to open up Internet explorer, it does not open up any web pages.

My firewall is currently enabled. I even tried disabling the firewall,
but that didn't work.

Any ideas??
I am not a computer guru. So what is the simple way to fix this
problem?

 

(JamesB) wrote in

If IPconfig /all results in a 169 IP being returned, then the computer is
having trouble getting an IP from the router's DHCP server and it cannot
connect to the Internet. This may be due to some mis-config of the NIC or
XP's Wireless Zero Configuration Service could be causing problems and my
need to be disabled.

If the machine is getting the 169 IP and after doing a reboot or IPconfig
/release and Ipconfig /renew at the DOS Command Prompt and the 169 IP
doesn't release, then you may need to reset the TCP/IP Stack on XP to
release it.

http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q299357&

Duane

 

Thanks. I'll read the URL, but the XP laptop works fine when carried to
a location with public WiFi, and the laptop that is still at the
location is a w2k system, so AIAIK, doesn't have Zero Config.

Both machines are auto-configuring to a 169 IP.

 

Oh-oh. You can run your network using all 169.254.xxx.xxx IP
addresses, but you may get some suprises. The 169.254.xxx.xxx IP
address block is reserved by Microsloth for IP addresses the computah
defaults to when it cannot get an IP address from a DHCP server. The
xxx.xxx numbers are random. If you're running with 169.254.xxx.xxx
addresses, then it's highly likely that you only have 169.254.xxx.xxx
as an IP address for the computah, but 0.0.0.0 for the default gateway
and DNS servers. You can network like that between two computahs, but
you're not going to surf anywhere on the internet without a gateway
and DNS servers. You can see all the addresses with:
Start -> Run
cmd
ipconfig /all | more

Worse, your Windoze XP laptop is very persistant. If you go to a
coffee shop hot spot and connect successfully, you will get an IP
address of 192.168.1.xxx (or something similar) from a DHCP server.
When you get back home, XP will try to use this IP address until you
either disable/enable the card, or kick start a DHCP request with:
cmd
ipconfig /release
(wait a while)
ipconfig /renew

There are a few other suprises but they're minor and can be ignored.
However, methinks that running a network with 169.254.xxx.xxx
addresses is a bad idea.

So, the big question is why are you not getting an IP address from the
DHCP server in the router? DHCP might be turned off, misconfigured,
or just plain broken. Hard to tell from here. Another possibility is
that the encryption on your wireless link has changed. If this is
the case, you'll get a good signal indication, but you won't be able
to connect to the web server in the router. I have a bunch of other
guesses but mangled WEP/WPA are the usual culprits.

Start this exercise with a desktop (or laptop) plugged directly into
the DI-614+ router. No wireless involved. Make sure that the DHCP
server is working and that your desktop is getting a real IP address,
gateway, and DNS server, and *NOT* the 169.254.xxx.xxx default IP.

Once the router is working for a wired connection, troubleshoot the
wireless part. If the WEP/WPA encryption seems to be the issue,
disable encryption in both the DI-614+ router and client radios. Once
that's working, turn it back on and make sure everyone is using the
same WEP key or WPA shared key.

 

FWIW its not reserved by MS. Its reserved by international standard. Blame
MS for many things, but not this.

 

Oh, I think if you went and looked at the Services for Win 2K, you'll
find the Wireless Zero Configuration Service is on the Win 2K O/S and
it's disabled be default on Win 2K.

<snip>

If the machine is getting the 169 IP and after doing a reboot or IPconfig
/release and Ipconfig /renew at the DOS Command Prompt and the 169 IP
doesn't release, then you may need to reset the TCP/IP Stack on XP to
release it.

<snip>

If the 169 IP is present, then the machine cannot get an IP from a DHCP
server on the router due to some mis-configuration or something is
defective with equipment and the machine is timing out. That is a
reserved IANA IP that's being assigned to the NIC that indicates the
condition, along with the *auto-config* message. The IP will allow the
machine to access other machine on the LAN but the IP will not allow
access to the WAN.

Duane

 

RFC3330. See:
http://www.faqs.org/rfcs/rfc3330.html

169.254.0.0/16 - This is the "link local" block. It is allocated for
communication between hosts on a single link. Hosts obtain these
addresses by auto-configuration, such as when a DHCP server may not
be found.

Also known as Automatic Private IP Addressing (APIPA) by Microsoft.
To the best of my knowledge, Microsloth was the first to actually use
this "feature". I think I wasted a day dealing with a W2K server
routing problem until I found this:
http://support.microsoft.com/support/kb/articles/Q244/2/68.ASP
Someone had setup a company full of workstations plus a server on
169.254.xxx.xxx rather than bothering to get a DCHP server working
properly. That sorta worked until they needed to connect to the
internet, and there was no default route or DNS. I can't blame
Microsoft for inventing this abomination, but I certainly can blame
them for implimenting it.
http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/prjj_ipa_eiih.asp

 

Google for the two apps lspfix.exe and winsockxpfix.exe. Run both in
default mode.

Q

 

How are you going to blame MS for something someone implemented that
cause you some pain? ;-)

Duane

 

Win2K doesn't have any native builtin wireless support of the sort that WZC
offers. It may be in the APIs but not in the OS.

 

The fact that is there and it can be activated as a service on Win 2K means
one can do something with it. I never bothered doing it and do not use WZC
on XP either, because it's a PITA and nothing but trouble with my first
encounter with it. It was quickly disabled.

Duane

 

No problem can be solved without first assigning the blame.
Suffering always precedes enlightenment.

Actually, I offer thanks to Microsoft for such abominations that
support my decadent and lavish lifestyle. If Microsoft had done it
right, I would be out of business and back to repairing sewing
machines, chain saws, and radios. I might also be forced to get one
of those "job" things. As long as such features have unexpected side
effects, glitches, do weird things, and change themselves without
notice, my chosen career path is secure.

On my business card and stationary is the company motto:
"If this stuff worked, you wouldn't need me"

 

I gald you see that it's just a job and M$ generates revenue! Too many
people take the M$ thing to the deep-end. ;-)

Duane

 

YMMV, but its not MS's (or the RFC writer's) fault if you don't actually
know how DHCP works. IMHO its quite handy knowing that you have a DHCP
problem.

And frankly its hardly an abhomination, when something works as per the
standard. And there was someone earlier rabbiting on about nonstandard
software.

 

Someone else setup that dynamic IP network without a DHCP server. I
was the one that fixed it. Incidentally, that was in the days of NT4,
where one release of the MS DHCP server faithfully would give out the
servers IP address and corrupted its own database on a regular basis.
The backup DHCP server system never did work right until W2K. Things
have much improved since then.
http://www.microsoft.com/windows2000/techinfo/reskit/en-us/cnet/cncb_dhc_klom.asp

There is some truth to me not knowing how DHCP works. This was the
topic of discussion a few weeks ago, over how the cheap routers manage
to remain RFC2131 compliant without a saved database or cache that
will survive a power cycle. The static DHCP assignments are retained
in the non-volatile configuration memory, but the dynamic DHCP
assignments seem to be lost on power cycle. In my spare time, I've
been sniffing the traffic trying to determine how these really work
and how it verifies that an IP address has not been previously
supplied after a power cycle. I'm not ready to offer any revelations,
but I certainly have some odd behavior and creative implementations of
RFC2131.

RFC2131 states:
http://www.faqs.org/rfcs/rfc2131.html
that the DHCP server *MUST*:

- Retain DHCP client configuration across DHCP client reboot. A
DHCP client should, whenever possible, be assigned the same
configuration parameters (e.g., network address) in response
to each request,

- Retain DHCP client configuration across server reboots, and,
whenever possible, a DHCP client should be assigned the same
configuration parameters despite restarts of the DHCP mechanism,

This is obviously not being retained on cheap routers so some other
mechanism must be involved. Got any info or clues?

I believe I'm qualified to pass judgment on the value and
implementation of APIPA. I find it to be useless and generally
confusing to the user. In my never humble opinion, when DHCP fails,
methinks it should fail completely, and not offer a bogus IP address
and no default route. The default IP address should be 0.0.0.0. Do
you know of any useful functions that APIPA performs? I can think of
a few obscure and contrived situations where it might be useful, but
offhand, I can't think of anything it does but create confusion.