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: