How to test wireless problem?

First, if all else fails, RTFM (read the instructions) on configuring WAP/router and clients to connect to it. You likely will want to do this via tp- connection.

Then, just do it, and check progress via router's logs, client's connection manager (you could have told us the os version, you know!) status, IP config.

Just the basics. (You wanted more for free?)

J

"harlen" hath wroth:

By using ping. Start at the end closest to you and work your way towards the internet. Initially, use IP addresses, not DNS lookups, to eliminate that potential source of problems. Start with:

1. Ping 127.0.0.1
2. Ping Your_R51_IP_address.
3. Ping Your_router_LAN_IP_address.
4. Ping Your_router_WAN_IP_address.
5. Ping Your_ISP_Gateway_IP_address.
6. Ping Your_ISP_Mail_Server_IP_Address.

If any of these fail, that's where your connection is having a problem. You need to get the numbers BEFORE things screwup. Also note that some of these might change.

1. 127.0.0.1 is localhost. If that fails, you have your network stack all screwed up on your PC.
2. To get your own IP address (as assigned by your unspecified model router), run: start -> run -> cmd ipconfig
3. Your router LAN IP Address is the "gateway" IP address from the ipconfig command.

4,5. Your router WAN and ISP Gateway IP addresses can be extracted from the "status" page in your unspecified model router. These may change regularly so get the numbers before using ping to test.

1. Your mail server IP address can be obtain by simply pinging it by name and writing down the returned IP address. ping mail.your_ISP.com or something like that. Many ISP's post this information on the web pile.

If all of these work, but you still can't reliably connect, it might be a DNS server problem. First, flush the DNS cache with: start -> run -> cmd ipconfig /flushdns Then try pinging various sites by name and see if anything comes back. ping

Try to pick something that is NOT likely to have been previously accessed. If it fails, your ISP's DNS server, your router's DNS cache, or your PC's DNS resolver are screwed.

I'll bet you've got a Linksys WRT54G

Nope. I have a D-Link DI 624 Rev C.

Why should that be so obvious?

Can you describe a bit about the environment of installation? What's between the router and your Thinkpad (when placed where connection dropouts occur)?

--

Because I have an R51 and a WRT54G and since I've had it I've had the same sort of "drop off" issue that the OP described. Just a SWAG on my part.

I'm having the same problems with a Thinkpad R40 and a "MyEssentials" wireless router. I previously had a DLink I gave to a relative when I moved. Never had a problem with DLink, not once.

Not only do I get dropped from service when I use a cordless telephone with this new router, I just posted on this group about two perfectly fine wireless RCA headphones that have gone dead at the same physical (geographical) address where this router is installed. I want to know if it's coincidence or not that all the wireless systems in use at this physical geographical address are screwed up since buying the new router. The router/modem are installed in a room with gypsumboard walls and frame wood construction. The busted headphones are in one adjacent room. The Thinkpad is used in a third room (also adjacent to where the router/modem are installed).

I did everything JLiebermann said. There's no problem *except* during any kind of VOIP transaction (use of a cordless phone). I DO NOT HAVE A VOIP PHONE SERVICE. But, for example, I contact Customer Service at Amazon.com, click on a tab that automatically rings your phone and connects you to them. At that point, my internet service always is interrupted/dropped.

Wow, would I ever appreciate some feedback before going out and buying two new headphones and returning this router.

According to my wireless indicator, my signal quality is very good. My problem, which can occur at any time, happens when I come out of hibernation. Rebooting the laptop helps some of the time. Power recycling the DSL modem and router doesn't help.

The next time I loose the wireless connection to email or internet, I'll start pinging around as one poster suggested.

Thanks -

My

I've read other posters have problems coming out of hibernation. Zone Alarm was a problem.

OK. Good lead. I have the hog, Norton.

Yes, ZoneAlarm and other security programs are a good place to check. They're capable of doing unfriendly things like disabling DHCP client (so you are left in the cold without an IP) etc.

If the problem persists inspite of ZoneAlarm deactivation, I'd look for a driver update for the WLAN card on R51.

BTW - if things were working ok in the past and suddenly gave in, the weekly Windows Update might be one thing to suspect. I don't know if M $ documents somewhere what they are doing to your laptop each week, but reading up WiFi related stuff in such documentation might be worth- while.

"confero24.com/wlan-antenna" hath wroth:

Assumption, the mother of all screwups. There have been screwups caused by MS Updates. However, there are plenty of other programs that do automagic updates and cause problems. On my machine, I have various Google products, Mozilla Firefox and Thunderbird, assorted auntie-virus and auntie-spyware products, assorted VoIP products, assorted Apple products (Quicktime, Itunes), Winamp, HP Update, and others that I'm too lazy to dig out. When I start my Windoze XP box, it's update hell for the first 2 to 15 minutes before I'm allowed to continue. Some updates don't install until I reboot anyway, so it's difficult to tell when there are half a dozen updates all trying to simultaneously mangle the registry on boot. While it's easy (and fun) to blame MS for everything, there are plenty of other culprits available.

Incidentally, I had to live with shutdown problems for about a month without a clue as to which of the multitude of updates caused the problem. Eventually, I found that a Skype update had broken the shutdown (extras manager install problem).

OK. I am having a similar problem with my R-51 after shut-down. Just to see if it's the same, next time you have this problem, try this:

Start>Run>services.msc.

Now, scroll to the bottom and look for Windows zero configuration service. If it is not started, start it now. If it is, stop and restart.

Now see if you connect.

Just a quick check. May not be the problem at all.

Steve

seaweedsteve hath wroth:

I think it was originally a hibernate problem, not a shutdown problem. However, there is a fix for shutdown issues which has fixed more than just a slow shutdown. Mine went from about 5 minutes to shut down, to about 10 seconds. See the Microsoft User Profile Hive Cleanup at:

It installs as a service and essentially does some cleanup work that MS forgot to include on shutdown. I have no idea if it will fix the wireless problems, but it's worth a try.

Thanks Jeff. I'm looking into your link. I so rarely shut down (usually hibernate) that I have not bothered to fix my own problem.

And yes, I saw that the OP had a hibernate, not shutdown problem. Just one of those shots in the dark. Easy to check.

Goes back to the same thing I'm seeing on various pcs; The battle between the custom management utility and Windows Zero over who is supposed to be handling it and what state it's supposed to be in now. I keep seeing this in various forms on various pcs with various adapters. Maybe I change adapters around too much, testing and all that.

Not to derail the topic, but I wonder if I'm the only one who sees this?

Steve

seaweedsteve hath wroth:

Well, I think you have the right idea, but I have a different analysis. What I see is the usual "assumption, mother of all screwups". In this case, it's the assumptions made by the wireless access point and the wireless client driver. Neither of these expects the client to just disappear when it goes into hibernate. There's no magic message such as: Hey access point. I'm going away for a while. Save my setup so I can easily reconnect. Instead, what the access point sees is a client that just disappears. It has no idea what happened. It doesn't know anything about the clients desire to hibernate, standby, power save, or crash and hang. So, it waits for a while, hangs on to the DHCP cache data for 24 hours, but eventually times out the connection.

Eventually, the client comes out of hibernate, standby, reboot, or whatever and demands that everything be exactly the same before it went comatose. It tries to continue the previous connection at all layers from the applications layer (HTTP), to the IP layer (sequence number), to the MAC layer (connection info). With all 7 layers trying to continue as before, at least one of them is going to fail. Some layers will continue pounding on the web server, gateway, access point, etc. Some, not all, are going to fail.

How the client recovers from these multiple failures is what determines how well it's going to recover. If the client declares a disconnect and restarts the connection sequence, then there will be several seconds delay while it goes through the connection setup. In theory, that should be all that's necessary to reconnect, but again we run into assumptions. What if some web service (web server, ftp server, etc) doesn't quite time out, recognizes the client, and tries to continue where it left off? The IP stack gets the same IP and authentication info, but the packet sequence numbers are off. Same with end to end SSH or VPN encryption packets, and a number of other possible places for things to screw up. Instead of a new session, you get a hang or an error message. Bummer.

What's roughly happening is that there's no common signal for a disconnect between layers at both ends. There is usually a signal going up the 7 layer stack. For example, if the MAC layer detects a loss of carrier, it will inform the upwards adjacent IP layer that there has been a disconnect and it will drop the connection. Upwards and onwards to the application layer which will also get a disconnect signal. In some cases, there are also signals going in the downward direction. However, there is no universal disconnect message, that propagates to all layers, and initiates a disconnect-reconnect sequence, on power save, hibernate, or standby, on either the access point or client. How the system handles such events is in the hands of multiple vendors, on multiple layers, with multiple and different assumptions.

Many protocols that were scribbled after the original 802.11 specs include state tables to handle disconnects gracefully. They're not simple and are designed to accommodate all known shutdown and restart states. 802.11g has such a state table but only includes intentional disconnects and reconnects. There's nothing there for a client or AP just disappearing and coming back a day later after everything times out. That leaves it up to the firmware writers and client driver writers to implement. The compatibility mess with WDS and repeaters, which are also badly specified, should give you some clue as to their chances of success. To their credit, I would not have expected the

802.11 authors to have predicted the features required 10 years in advance.

I hope this helps.

Very helpful to understanding in general. Not what I was talking about though. I'll drop the issue for now to avoid completly derailing the topic.

Cheers, Steve

Be sure and do that. Even better if you can also post a copy of ipconfig/all results.

Steve