If geeks love it, we’re on it

Solve Wireless Lag and Disconnects on XP

Solve Wireless Lag and Disconnects on XP

The dream of a wireless-enabled new millennium was a WiFi-blanketed world that enabled seamless roaming for new generations of phones, MIDs and UMPCs. Microsoft felt strongly about this dream, and promised unprecedented support for wireless devices in Windows XP. They delivered in the form of the Wireless Zero Configuration (WZC) service, and it was designed to eliminate the irritations of vendor-specific WiFi utilities. Any wireless card could interface with WZC, and the subsequent addition of WPA support kept the utility up to speed with the progress of WiFi. In theory, the goal of WZC is an admirable one, but its execution leaves quite a bit to be desired. The seamless wireless roaming that WZC was supposed to cultivate has made it an unacceptable solution for single-WAP environments. As users around the globe connect to their lone wireless router with the service, they suffer lost connections, lost packets and high pings. Today we’re going to cover the whys and hows of the issue to ameliorate one of XP’s biggest nuisances.

From a mile high vantage, establishing a connection between wireless devices is relatively simple. An access point continuously transmits a “beacon frame,” whose job is to advertise the existence of the router to wireless-enabled devices, and to communicate the basic configuration of that network. Upon receipt of the beacon frame, Windows or your wireless utility alerts you to the presence of a wireless network. Should you or your wireless client programmatically opt to connect, a sequence of association and (in the case of secured networks) authentication frames are exchanged. When all that hand-shaking is complete, a wireless link is established.

In the United States, wireless connections can be maintained on eleven channels from 2412 to 2462MHz; this permits one WiFi network to operate relatively free of interference from the next. However, on occasion it may be necessary (especially in roaming environments) to obtain a list of available WiFi networks. In such a situation the wireless client must send a “probe request frame,” transmitted on all wireless channels, to solicit a response from the WAP that’s similar in design to the beacon frame.

The root of the problem begins with the burdensome task of the probe request process. Broadcasting on all available channels is a taxing process, and the wireless client must await a response from each responding WAP. During this period, traditional traffic is reduced in priority or discarded until the response frames are received. When user-initiated traffic is reprioritized in such a fashion, latencies increase remarkably, packets are dropped, and the user experience takes a turn for the worse.

To provide an example, our test machine was configured a Linksys WMP54G v4.1 and the Linksys WiFi utility. Pressing “Refresh” under the site survey tab attempts to find all responding networks in radio range, and kicks off the probe response process. The image below clearly demonstrates the catastrophic results of that process:

A low-latency ping to Google balloons to 1192ms when a probe request is initiated

Graciously, the Linksys client is such that the probe request is only committed when initiated by the user. The results are statically stored in the list until another update is user-requested; this design decision emphasizes the user experience by ensuring consistent pings.

In order for Microsoft to deliver their seamless roaming experience, WZC must actively maintain a list of networks within radio range. It accomplishes this by programmatically polling for available networks every sixty seconds with the probe request sequence. In situations — such as the home or office — where roaming is not required, the user has no need of an updated network listing. Nevertheless, the end-user is guaranteed a period of high latency and packet loss every sixty seconds. While such a design philosophy does little to interrupt the experience of browsing, downloading or email-retrieval, it is obvious and debilitating for more latency-sensitive applications such as gaming.

At 5:58:58 PM, a WiFi connection is established with Microsoft’s WZC and a continuous ping is started.

Exactly sixty seconds later at 5:59:58, a period of high latency occurs to indicate the probe request.

Further evidence indicates that there is significant cause to believe that a station can be disassociated from its access point entirely at random by a probe request sequence initiated from the WZC client.

While the issue has persisted with considerable evidence to warrant a closer look, Microsoft maddeningly denies any issue. As early as 2004, Microsoft’s lead product manager in Microsoft’s Windows division remarked that “[They] don’t have data that suggests Windows XP drops wireless connections more than any other system.” He goes on to say that “Wi-Fi configuration in Windows XP is much different and easier than in previous versions.” In the interim, hundreds of hotfixes and numerous service packs have left the presented issues unresolved.

Without official promises or sign of aid, users experiencing bouts of the symptoms we’ve covered can seek solace in two solutions:

  • Once your wireless connection has been established with WZC, disable the service by typing “net stop wzcsvc” at the run prompt in the Start Menu. The caveat to this solution is that the computer will be unable to recover from a legitimate lapse in connectivity until the service is restarted via “net start wzcsvc,” and a reassociation is requested by the user.
  • While often clumsy and resource-hungry, manufacturer-provided wireless clients are tuned for environments where roaming is unnecessary. The utility will not stray far from the pasture, leaving you sanely and stably connected to the base station.

Vista users are similarly burdened by the WLAN AutoConfig service, which functions identically to its XP counterpart. These users have a third and superior recourse for their troubles in the form of the WLAN Optimizer .NET utility. The utility eliminates the sixty second polling interval and — in addition to other enhancements — provides the smooth WLAN experience a manufacturer utility would provide.

With Service Pack 3′s recent release, and the impending end of Windows XP’s support lifecycle, there is little cause to believe that the issue will ever be officially fixed. Even something so simple as a toggle to optimize the client for roaming or throughput would put an end to one of XP’s most bedeviling and long-lived issues. For now, confused and frustrated end users must fend for themselves in fixing the unfortunate side-effect of the seamless roaming dream.


Howdy, ! Got something to say?