September 2004, Issue 170

Uncomplicated Wireless Networking

SNIFFING AROUND

OK. Now you’ve got a general idea of what the Wi-Fi application kit should be doing under the covers. Unfortunately, that’s about all I can tell you. In fact, it’s all anyone can tell you. The inner workings of PRISM are classified and can be obtained only with a nondisclosure agreement. If you’re the end user, that’s all fine and dandy because all you really want is to use the wireless device. For a developer, the minute details must be made available so that the desired functionality can be built into the wireless device. 

The Wi-Fi application kit is intended for wireless developers. To avoid legal problems with the PRISM operational embargo, Z-World has wrapped all of the secret PRISM stuff into a driver package. The provided API allows you, the developer, to turn knobs inside of the wireless CompactFlash card without exposing the operational details of the PRISM silicon. The Wi-Fi application kit comes with a wireless CompactFlash card and a set of wireless example programs that expound upon the Dynamic C PRISM API. Before I go on to the API, I want to show you how easy it is to get on the air with the Linksys wireless CompactFlash card and the Wi-Fi application kit.

The first thing to do is define the network environment in Dynamic C. The example I used in the Florida room is shown in Listing 1, which is an excerpt of my modifications to the Dynamic C TCP_CONFIG.LIB file. I’m simply giving the Wi-Fi application kit wireless CompactFlash card a static IP address and defining the network gateway, which is also the access point in this case. By doing this up front, all I had to do was include the #define TCPCONFIG 1 statement and I was covered as far as network addressing is concerned.

DHCP operation is also an option. To invoke it, all you have to do is include the #define TCPCONFIG 5 statement. Although using DHCP makes life easy, without the pleasure of having a wireless Sniffer it would require me to know the Linksys CompactFlash card’s MAC address. Furthermore, after the wireless CompactFlash card is authenticated and associated, I have to access the access point (AP) to cross reference the wireless CompactFlash card’s MAC address to the Wi-Fi application kit’s newly leased IP address. To keep wireless life as simple as possible, I use the static IP option. The wireless sniffer automatically associates the wireless CompactFlash card’s MAC and IP addresses during a sniff session.

Lots of stuff is going on behind the simple code in Listing 2. Instead of turning on the extensive debugging that is included in the Dynamic C wireless API , I decided to sniff the operation to see if I could determine what was transpiring. The first thing you see in Photo 2 is a probe request emanating from the Linksys wireless CompactFlash card. You can conclude that the Wi-Fi application kit’s wireless CompactFlash card is actively scanning because the Linksys card is talking instead of listening.

The AP in the Florida room, which is identified as “EDTP,” runs on channel 11. All APs that can hear the Linksys wireless CompactFlash card’s probe request must respond with a probe response message. The sniff of the AP’s probe response tells me that the Florida room AP emits a beacon every 100 time units (TUs), or every 102.4 ms. A TU is defined as a 1,024-µs slice of time. The AP’s probe response also tells the Linksys wireless CompactFlash card that the AP is capable of 11-Mbps operation. Other fields in the AP probe response message reveal the AP’s SSID (“EDTP”) as well as its basic service set identifier (BSSID), which is the AP’s MAC address. All of this information about the AP is also included in the beacon; however, because the Linksys wireless CompactFlash card is actively scanning, the beacon and its information are not used in this instance. 

The authentication of the wireless CompactFlash card is the next step. The wireless CompactFlash card initiates the authentication process with an authentication request message that is aimed at the EDTP AP it has just joined. The AP acknowledges the wireless CompactFlash card’s authentication request and authenticates it. Inside the AP’s authentication reply is a field denoting the type of authentication. In this sniff, the open-system authentication method was used. After the wireless CompactFlash card sees the status zero code in the AP’s authentication reply, which means authentication was successful, it moves on to initiate an association with the EDTP AP.

The results of the wireless CompactFlash card’s association request include the assignment of an association ID (AID) number and another zero status code, which tells the card that it is successfully associated with the EDTP AP. The least significant 14 bits of the AID assist a station in determining if the AP is holding buffered frames for the station. Communication speeds, MAC addresses, and BSSIDs are also part of the payload in both the association request and response messages. After the card associated with the AP, I could ping it from other wired hosts and wireless stations on the network.