Weird Problem with Dropping internet connection

I have an hp pavillion dv5000 with the broadcom 802.11 b/g wireless adapter onboard. I am using a zxyel 330 router connecting to comcast via a US Robotics cable modem.

If the system sits for awhile, or hibernates, I lose all internet connection unless I reboot. I have tried disabling/re-enabling the onboard adapter, tried the repair function, stopped and started wzc, turned off wzc and tried the broadcom wireless config utility, have disabled the power saving and minimal power consumption options for the adapter - the problem still occurs. This morning I discovered that if I disconnect from my router and grab a neighbors open router signal, it immediately works without having to reboot. As well, if I then disconnect from the neighbors signal and reconnect to my wireless connection on the zyxel router, my connection is then alive again. What could possibly be causing this and is there a better fix than hopping around the neighborhood for a "jump start."

Shawn

Reply to
SJ
Loading thread data ...

On Fri, 03 Nov 2006 14:48:57 -0500, SJ wrote in :

Try turning off all wireless adapter power management.

Otherwise, the next time this happens, run the script at , and post the exact output here.

Reply to
John Navas

I had the same problem, and Jeff gave me the fix. He said:

Disable the DNS cache.

formatting link
worst part is that it will also cache failed DNS lookups for 15 minutes and valid (but out of date) DNS lookups for a full day.

Reply to
Dave Rudisill

On Sat, 04 Nov 2006 07:59:42 -0500, Dave Rudisill wrote in :

Then there's something else wrong, because DNS caching does work. You may want to investigate further, because it contributes significantly to performance. Turning it off to solve the problem is like not driving your car because the rear view mirror is fogged up. ;)

My Cable-DLS Guide has long had advice on how to disable negative DNS caching, which does make sense -- see link below.

There really is no such animal -- something is wrong.

Reply to
John Navas

Since implementing Jeff's suggestion in January, the problem, which was occurring daily, has not occurred once.

I have noticed no degradation in performance, but that's merely a subjective observation from somebody who attaches to networks with wildly varying performance almost daily.

Jeff, as usual, was right.

Reply to
Dave Rudisill

On Sun, 05 Nov 2006 09:43:10 -0500, Dave Rudisill wrote in :

About what? DNS caching definitely does work, and (as I wrote) turning it off to solve the problem is like not driving your car because the rear view mirror is fogged up.

Reply to
John Navas

Dave Rudisill hath wroth:

I'd be interested to see if this solves the problem, but I don't think it will help. This is a different problem. As I vaguely recall, your problem had to with either "anycast" DNS servers or an ISP with a broken DNS based load balancing scheme.

I have a similar Hp ze2000 series notebook with a similar Broadcom card, that does not have this problem with my wireless routers. However, I have gone to customers, where I let the laptop go into hibernate, and end up with a useless connection when it recovers. I don't know the exact failure mechanism, but my guess(tm) is that it's something the Zyxel 330 is doing (or isn't doing). Some things to try:

  1. Take your laptop to a local hot spot or other wireless router and connect. Force it into hibernate mode. Wait at least 2 minutes for the router to recognize that the connection is gone. Hit the key to wake up the laptop. Duz it work? Do the same with your Zyxel. I'm trying to determine if it's router dependent.
  2. When your laptop comes up comatose, try: Start -> Run -> cmd ipconfig (scribble down your IP address) ipconfig /release wait about 10 seconds ipconfig /renew Then run: ipconfig and see if you still have a valid IP address or if it has changed. If it changed and is now working, then what's happening is that the router is expiring your IP address, or the hibernate function is not forcing the DHCP client to renew the IP when it wakes up. I've been told that this is a problem if you have AOL 9 installed, which replaces the DHCP client. Treat this as rumor as I could find no substantiation.
  3. Also try the above test without the: ipconfig /release Just run the: ipconfig /renew and see if you can force the renewal in case the hibernate function forgets. It might work. Dunno.

Actually, it's probably best to try these in the reverse order in which I posted them, but I'm too lazy to edit my own posting.

Reply to
Jeff Liebermann

Jeff:

Here's what I posted back in January, with your reply (only disabling the DNS cache fixed the problem):

Yes, two:

1, Run: IPCONFIG /FLUSHDNS to clear the cache.

  1. Disable the DNS cache.
    formatting link
    worst part is that it will also cache failed DNS lookups for 15 minutes and valid (but out of date) DNS lookups for a full day.

Reply to
Dave Rudisill

Dave Rudisill hath wroth:

So much for my photographic memory. That wasn't the problem I thought I recalled.

It's still a totally different problem. Your problem revolved around switching locations and wireless routers, not a hibernation recovery problem. Your IP address was getting updated properly, but your Windoze DNS cache still had stale entries left over from the previous connection. Flushing the cache or simply disabling the feature was sufficient to fix that.

I've been running Ethereal on my desktop for the last hour of tinkering (mixed bag of eBay, usenet, web surfing, and email). I temporarily disabled the DNS cache. Most of the DNS lookups came from web surfing. Based on number of packets, DNS lookups for the last hour of surfing worked out to 0.68% of the packets. With the cache re-enabled, and just clicking through my history list for todays browsing, I get 0.15% of my packets are DNS lookups. Not very scientific or repeatable, but good enough for ballpark estimate. Caching certainly reduces the number of lookups, but the actual amount of traffic it saves is trivial.

Reply to
Jeff Liebermann

Jeff Liebermann hath wroth:

I was wondering if I could aggravate the problem. I fired up Skype, which uses clients as a distributed server, and generates large numbers of hits on port 27727. I also fired up various simple netstat monitors that run reverse DNS lookups on anything that hits the computer. I also switched from Ethereal to WireShark. Running for 15 minutes and doing nothing but scanning for incoming junk, 80% of the packets sniffed were DNS lookups with the rest being ARP requests and miscellaneous junk. So if you're doing network tinkering, cacheing the DNS lookups might be a good idea.

Reply to
Jeff Liebermann

Actually, I said "When I reconnect with the same network from the same location later..." I should also have added that there was almost always a hibernation between connections, since that's what I have my laptop do when I hit the power button. You couldn't have known that, since I failed to mention it. (Flushing the cache did not fix the problem.)

In any case disabling the DNS cache has resulted in the complete disappearance of a problem that was occurring daily.

Thanks.

Reply to
Dave Rudisill

On Sun, 05 Nov 2006 14:04:02 -0800, Jeff Liebermann wrote in :

The issue isn't traffic, it's time to do DNS lookups. DNS lookup from cache is very fast (near instantaneous), whereas DNS lookup through a resolver (server) can be a number of seconds. At best it makes Internet access sluggish. On web pages with different hosts (e.g., for pictures or ads), it can add up to considerable delay. In addition, lack of caching puts quite a bit more load on DNS resolvers, and so isn't considered "neighborly".

Reply to
John Navas

I have my laptop button set to do a shutdown. Closing the lid does the hibernate thing.

It's still a different problem. You're going into hibernate but you were also switching wireless routers while in hibernation. Apparently, you also recover gracefully from hibernation. Meanwhile, the OP has only one wireless router and is not recovering gracefully from hibernation.

Reply to
Jeff Liebermann

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.