|
|
Most of the management packets mentioned previously were related to connecting (or disconnecting) from a wireless network. This section covers exactly what happens when a station is looking for a wireless network.
The 802.11 standard provides two different ways for stations to locate APs: beacons and probe request/responses. Beacons are packets that access points are required to transmit periodically to synchronize station clocks. Since the AP must transmit these packets many times a second, it makes sense to put network information in them. Figure 3-6 shows a Wireshark decoding of a beacon. Notice that beacon packets carry around a lot of information, including the rates supported and other network details. The most interesting field in a beacon is probably the Service Set ID (SSID), which is the human-readable name of the network. In Figure 3-6, the network is named "NETGEAR".
The other way for stations to locate networks is by using probe requests. Beacon packets are analogous to the AP saying "Hi, I'm Linksys" every 1/10 th of a second. Probe requests, on the other hand, let clients look for networks. Probe requests come in two flavors: directed and broadcast. A directed probe request is analogous to a station transmitting a packet that says "Hello, is a network named Linksys nearby?" A broadcast probe request is more analogous to a station asking "Are any networks out there?"
APs respond to directed probe requests only if they are in the same network that the station is looking for. All networks in the area are supposed to respond to broadcast probe requests. At least, that's the way it is supposed to work. In Chapter 4, you'll see that vendors have violated this protocol to let users hide their networks, while hackers have developed tools (the most notable being KARMA, covered in Chapter 6) that respond to all directed probe requests.
Assuming that a station has found a wireless network that it wants to connect to, what does it do? The first thing it does is send out an authentication request. This authentication request is merely a formality. The original 802.11 standard specified a shared-key authentication scheme (based on WEP) that was supposed to prevent people from connecting if they didn't know the key. Turns out (for reasons covered in Chapter 6) that this type of authentication is actually worse than no authentication at all. For this reason, almost all networks simply leave it turned off.
So, assuming the network is properly configured (and doesn't use the broken shared-key authentication), the AP replies with an authentication response indicating the station is authenticated. Once this is done, the client sends an association request.
The association request packet is interesting, in some sense, because it is required to have the Service Set ID (SSID), or network name, of the network it is associating to. Some networks try to keep this a secret, despite the fact that every client must transmit it in the clear when they connect.
Association requests carry some information useful to the AP. In particular, when a station is associating, it informs the AP what rates it supports, whether or not it can handle certain speed optimizations (such as short slot time), and so on.
Assuming the station successfully authenticated previously, the AP responds to the association request with an association response. The only really new information in an association response is the status code (assumedly successful), and the station's Association ID (AID). The AID is used to identify clients regarding power savings. The entire six-packet exchange is shown in Figure 3-7.
|
|
