Intel 2200BG Wifi / doesn't auto connect on powering on the machine / HP Laptop

Michel S. hath wroth:

Any particular model HP laptop?

That would be XP SP2. When someone says "all patches applied" I usually take that to mean all "critical updates" applied and none of the optional ones that are NOT automatically installed under cover of darkness. Try:

and select "Custom". When you're done, then tell me that you've applied all the patches.

The latest? Any clue what version? There were problems similar to what you describe with the various Proset 9.x mutations. Instead of using whatever HP offers, try the Intel version at:

The current version is 11.1.1.11 with a driver version of 9.0.4.36.

Both Wireless Zero Config and Proset have some kind of setting for each connection profile that declares it to be a "connect automatically". What happens if you have more than one of these set is that when the client scans for available access points, it will select the one that is nearest the top of the list of connection profiles. It can easily be the wrong one. If it's set to connect manually, it will not connect to anything until you manually select it from the list of available networks.

If you only have one system in the connection list, and presumably it's set to connect automatically, it should work. What I've noticed on the latest Proset versions (11.1 and up) is that it takes perhaps

5-7 minutes for the client to establish a wireless connection on bootup. It was quicker on earlier versions. Are you waiting long enough?

Thanks for you reply Jeff, see my comments below..

Jeff Liebermann avait écrit le 2007-06-09 :

Pavilion dv4200 (precisely model dv4270ca)

You are right : I mean all "critical updates" PLUS Hotfix KB893357 (which takes care of WPA2 and is not considered critical) applied. I used the expression because WMP11, IE7 and .NET framework are not "patches" IMHO.

The HP updated drivers weren't used at all.

Instead, the latest availiable on Intel's site at that time (3-4 weeks ago) were used. (11.1.0.0_XP32, with driver version 9.0.4.33)

(BTW, I just checked and found that we are BOTH right : Intel's french download site list the latest to be V11.1.1.0 with drivers 9.0.4.33 for

2200BG while the english version list the ones you specified.)

Unfortunately, the "Release Notes" doesn't list the issues corrected by the newer version.

In the case of WZC, it will not even find the right one if the SSID broadcast is disabled. To make sure it was not the case with Intel's software, we tried with both SSID broadcast enabled and disabled.

(Even if many say that disabling SSID broadcast gives no additional security, I think that hiding it from the "average neighbour" will keep them away from any temptation to use or tamper with the AP).

This is the only connexion configured in the profiles list and it is set to automatically reconnect.

Interesting !

Knowing my friend's patience, I'm sure he doesn't wait more than 45 seconds before giving up.. ;-)

Any idea why it is like this at bootup but not when coming out of sleep mode (which takes only about 7-10 seconds to reconnect) ?

I'll check this with him over the week end and post back on this.

In the meantime :

a) do you think the 9.0.4.36 driver would make any difference over the current 9.0.4.33 ?

b) if the longest bootup connect time was noticed only since the ProSet

11.1 - would it be a "good" idea to try installing the pre-11.1 software but leave the "latest" (current) drivers ?

Thanks again !!

Have you tried installing kb917021 and then using the "Connect even if the network is not broadcasting" option ?

Thanks for pointing me there Kev..

After a glance at the article, I have 2 additional questions:

1) How exactly did you find the existence of this patch ? It's not listed on "Custom" pathes availiable under windows update (at least, not the French version) even after the KB893357 update is installed..

(And I found about KB893357 after Googling a couple of hours, not by WU !)

2) Do I correctly understand that this patch applies only if WZC is used to connect to the WiFi lan ?

Thanks again !

kev avait soumis l'idée :

One of the family was doing some "homework" on ad-hoc networks and it came up while he was doing some research.

Yes

Michel S. hath wroth:

I usually install literally everything. It sometime gets me into trouble, especially when it offers a new device driver, but usually works better than when an update is missing.

Incidentally, I also see far too many failed updates, where the update is downloaded, but didn't install correctly. This usually requires manual corrective action (hacking and cursing) and is not corrected by Windoze update. I use Belarc Advisor (free) at:

which lists updated downloaded, installed, and missing. I've fixed quite a few W2K and XP problems by simply re-downloading and re-installing the update.

Good, because they're usually a month or two behind the development curve. With the newly re-written wireless stack in Vista, many previously un-addressed wireless driver and connection manager related issues seem to be appearing. In an effort to keep XP and Vista synchronized, many driver writers are using this as an opertunity to update their XP drivers at the same time as their Vista driver.

Old bugs seem to return. Both WZC, Proset, and probably a bunch of others will not detect access points that don't broadcast their SSID. Incidentally, some of Netgear client managers will detect non-broadcasting AP's. Last time I checked, both WZC and Proset will connect to AP's that don't broacast, if you supply the correct SSID. However, there were bugs in the past with this feature. I vaguely recall that one of them is that the client would connect to a non-broadcasting AP, but it would not roam or re-connect.

They will accidentally land on your RF channel because they can't "see" your system.

Good. Also, in Proset, there's a setting somewhere for how aggressively the client should try to reconnect. It think it's under roaming settings. It has a side effect of causing constant connect/reconnect cycles if too aggressive in finding a better access point, and seems to have an affect on connecting coming out of hibernation. Sorry, I don't have a machine with Proset handy.

It was weird. Unfortunately, I never bothered to time how long or investigate the cause. On boot, the laptop would boot normally in about 90 seconds. All the multitude of programs that want to check for updates would lurk silently in the background, waiting for the internet connection. It was very obvious when it would finally connect as the machine came to almost a halt as all these programs would almost simultaneously either announce their intentions or beg for comfirmation. What was suprising was how long it would take. My guess is 5-7 minutes. I sometimes got impatient and would use WZC to "view available networks" and connect manually. As I recall, that would only take a few seconds (although the scan for networks was slow when faced with a large number of access points).

No, but I have a bad guess. Coming out of sleep mode, it probably asks for a DHCP renewal. If it's less than 24 hours since the lease was originally issued, it will probably get the lease the first time, every time. However, when it requests a new lease, which may be a problem if the AP thinks it previously had issued one. My guess is that it's probing the network, looking for other devices that may represent a duplicated IP, and only after some timeout, elects to issue a new lease.

However, you seem to be having problems with the initial association on boot, not the subsequent authentication or DHCP. Proset has some diagnostic logging built in. Try using the logs and see where the delays are buried.

Also, WZC has debugging and logging. See:

You may not be able to decode what's going on in the driver or WZC, but you can see by the date/time stamps, where the delays are buried.

I don't know. Without a bug list, it's difficult to determine. I always like the latest drivers. New bugs are far more entertaining than old bugs.

No, stay with the latest and save the stuff that will make a mess of the registry for last. Most driver and application writers do not test for downward revisions. Methinks you're asking for problems.

In addition to what others have suggested, try a TCP/IP repair:

Or a WinSock repair: (2 tools) These have worked for me more times than I can remember...