This section provides both an explanation of how Omnipeek works and an introduction to the basic concepts and vocabulary of WLAN networking. It also provides a brief overview of the 802.11 WLAN protocol as well as a detailed breakdown of 802.11 WLAN packet headers and 802.2 LLC headers, and the information they contain.

Omnipeek, packets and protocols

This first section explains how Omnipeek works, and offers a brief introduction to the concepts of packets and protocols. For a list of recommended readings on networking topics, please visit

How Omnipeek monitors and captures network traffic

Omnipeek takes advantage of a fundamental characteristic of 802.11 WLAN networks. On an 802.11 WLAN, one computer does not send a packet exclusively to another computer. Instead, it puts the address of the desired destination or receiving station in the header of the packet, and puts the packet out onto the airwaves. Each network node within range listens to the transmission and uses the first address in the 802.11 WLAN MAC header to determine if that node should process it. If the packet was intended for a particular computer, that machine captures it, puts it in memory, and then passes it to the next layer of the protocol stack for processing. If the message was received intact, the receiving node typically sends an ACK to acknowledge this.

For example, device A in Figure C.1 transmits a packet addressed to device C. All devices within range receive a packet that contains device C’s address, but devices B, D, and E ignore the packet when they find an address not their own in the first address field of the packet’s MAC header. Only device C, finding its own address in that first field, processes the packet further.

When Omnipeek runs on a workstation, it puts the 802.11 WLAN hardware in Promiscuous Mode. In Promiscuous Mode, the workstation running Omnipeek accepts every packet, whether or not it is addressed to that workstation. Omnipeek installs itself parallel to any other stacks on the workstation, telling the driver it wants to see every packet of every description that it finds on the networkp

Figure C.1 Packets are received by all devices on the network

For example, if Omnipeek is running on device D in Figure C.2 and device A sends a packet addressed only to device C, both device C and device D accept and process the packet.

Device C acknowledges the receipt and processes the packet normally, passing it to the next layer of the protocol software. Device D also captures the transmission and passes the packet to Omnipeek. The machine on which Omnipeek is running will not send any acknowledgement, because Promiscuous Mode is strictly a listening mode. Radio transceivers cannot listen and send at the same time on the same frequencies because their own transmission would drown out any incoming traffic.

Figure C.2 Omnipeek accepts all packets (Promiscuous Mode) without acknowledgement

Important!   Under certain network or program configurations, Omnipeek can enable the user to monitor information that might be considered confidential. For example, some passwords may be view able from Omnipeek if WEP is not implemented on your network, or if you configure Omnipeek to monitor the network as a peer WEP host. Because of this, you may want to prevent unauthorized access to the program. Consider limiting access to Omnipeek by not installing it on public machines and servers.

What is a packet?

Each piece of information transmitted on a network following any of the IEEE 802 series standards is sent in something called a packet. A packet is simply a chunk of data enclosed in one or more wrappers that help to identify the chunk of data and route it to the correct destination. Destination in this sense means a particular application or process running on a particular machine. These wrappers consist of headers, or sometimes headers and trailers. Headers are simply bits of data added to the beginning of a packet. Trailers are added to the end of a packet.

Figure C.3 Constructing a network data packet (here, a piece of a web page)

Packets are created at the machine sending the information. The application generating the data on the sending machine passes the data to a protocol stack running on that machine. The protocol stack breaks the data down into chunks and wraps each chunk in one or more wrappers that will allow the packets to be reassembled in the correct order at the destination. The protocol stack on the sending machine then passes the packets to the network hardware: the NIC (Network Interface Card). The network hardware adds its own wrapper to each packet (the header and trailer appropriate to the particular IEEE 802 standard) to direct it to the correct destination on the local network.

If the packet’s ultimate destination is somewhere off the local network, the header added by the sending machine will point to a router or switch as its destination address. The router will open the packet, strip off the original wrapper, read far enough to find the ultimate destination address, then re-wrap the packet, giving it a new header that will send it on the next hop of its journey.

At the receiving end, the process is reversed. The packet is read by the NIC at the receiving machine which strips off the network header and passes the packet up to the appropriate protocol stack. The protocol stack reads and strips off its headers and passes the remaining packet contents on up to the application or process to which it was addressed, reassembling the chunked data in the correct order as it arrives.

Figure C.4 Omnipeek decode of an HTTP packet (collapsed view)

The packet diagrammed in Figure C.3 above is shown again in a Packet Decode window in Figure C.4. The Decode view shows multiple fields calculated by Omnipeek at the top of the window, then shows each of the layers of the packet. In this view, the “+” signs in the margin indicate that the details for each part of the packet are hidden under their headings. Omnipeek displays the packet contents in the same order in which it appears in the packet: 802.11 WLAN header, IP header, then the TCP and the HTTP payload.

What is a protocol?

A protocol is a set of rules governing communications.

Networking protocols specify what types of data can be sent, how each type of message will be identified, what actions can or must be taken by participants in the conversation, precisely where in the packet header or trailer each type of required information will be placed, and more.

Omnipeek understands protocols by examining the contents of the packets those protocols create. Each protocol has a variety of forms of headers and sometimes trailers that it uses, either to transmit data for other applications, or to transmit control and information messages that support its own functionality. The exact form of these wrappers or headers tends to be unique, not only among functions within a given protocol, but also across protocols.

Omnipeek tells the network adapter that it wants to see all traffic from all of the various protocol stacks: AppleTalk, TCP/IP, DECnet, NetWare or others. Omnipeek decodes the packets in order to identify as precisely as possible what function each packet serves within its protocol. Savvius’ ProtoSpecs technology refers to these various functions as sub-protocols. In other, more formal views of networking, TCP and UDP may be seen as protocols in their own right, HTTP may be seen as an application running under TCP/IP, and so on. ProtoSpecs side-steps all these largely formal naming conventions and simply treats all of them-UDP, TCP, and HTTP-as sub-protocols of IP. ProtoSpecs does preserve the correct functional relationships among the various sub-protocols, however. HTTP, for instance, is shown as a sub-protocol of TCP which is itself a sub-protocol of IP.

802.11 WLAN overview

This section presents a detailed overview of the 802.11 WLAN standards. The information is presented under general functional headings. A detailed breakdown of 802.11 WLAN packet headers and of 802.2 LLC headers is presented after the overview.

Development of the IEEE 802.11 WLAN standards

In 1997, IEEE approved 802.11, the first internationally sanctioned wireless LAN standard. This first standard proposed any of three (mutually incompatible) implementations for the physical layer: infrared (IR) pulse position modulation, or radio frequency (RF) signalling in the 2.4 GHz band using either frequency hopping spread spectrum (FHSS) or direct sequence spread spectrum (DSSS). The IR method was never commercially implemented. The RF versions suffered from low transmission speeds (2 Mbps). In an effort to increase throughput, IEEE established two working groups (A and B) to explore alternate implementations of 802.11. A third group, Working Group G, was set up after these two.

Figure C.5 802.11 and the 0SI Model

Working Group A explored the 5.0 GHz band, using orthogonal frequency division multiplexing (OFDM) to achieve throughputs in the range of 54 Mbps. The challenges, both to produce low cost equipment operating at such high frequencies and to reconcile competing international uses of this spectrum, kept their 802.11a WLAN standard from reaching the market before mid-2002.

European regulators require 802.11a WLAN devices to support the added functions of dynamic frequency selection (DFS) and transmit power control (TPC). These help to avoid or mitigate interference between 802.11a WLANs and existing 5.0 GHz band uses.

Working Group B explored more sophisticated DSSS techniques in the original 2.4 GHz band. Their 802.11b WLAN standard, published in September 1999, can deliver raw data rates of up to 11 Mbps. The majority of WLAN systems in the market today follow the 802.11b WLAN standard.

The IEEE Working Group G began by exploring a variety of methods to further improve throughput in the 2.4 GHz spectrum used by the 802.11b standard. In May 2001, the FCC removed its ban on the use of OFDM technology in the 2.4GHz band. In November of 2001, Working Group G tabled a draft standard adopting OFDM, the same signalling method used in the 802.11a WLAN standard. The 802.11g WLAN standard is not absolutely finalized at this writing, but the main outlines are clear. One significant aspect of 802.11g is the degree to which it supports backward compatibility with the older 802.11b standard, which uses the same spectrum. When 802.11b nodes are present, 802.11g nodes use the RTS/CTS as a prelude to each packet transmission. Although the maximum raw data rates for 802.11g WLANs are as high as those of 802.11a WLANs, the actual data throughput for 802.11g drops significantly when 802.11b nodes are present. Mixed 802.11b/g networks are possible, but the maximum performance will be much higher in a pure 802.11g WLAN.

The 802.11 WLAN protocols specify the lowest layer of the OSI network model (physical) and a part of the next higher layer (data link). A stated goal of the initial IEEE effort was to create a set of standards which could use different approaches to the physical layer (different frequencies, encoding methods, and so forth), and yet share the same higher layers. They have succeeded, and the Media Access Control (MAC) layers of the 802.11a, b, and g protocols are substantially identical. At the next higher layer still, all 802.11 WLAN protocols specify the use of the 802.2 protocol for the logical link control (LLC) portion of the data link layer. In the OSI model of network stack functionality (see Figure C.5), such protocols as TCP/IP, IPX, NetBEUI, and AppleTalk exist at still higher layers, and utilize the services of the layers underneath.

Radio frequencies and channels

The most striking differences between WLANs and wired networks such as Ethernet are those imposed by the difference in the transmission medium. Where Ethernet sends electrical signals through wires, WLANs send radio frequency (RF) energy through the air. Wireless devices are equipped with a special network interface card (NIC) with one or more antennae, a radio transceiver set, and circuitry to convert between the analog radio signals and the digital pulses used by computers.

Radio waves broadcast on a given frequency can be picked up by any receiver within range tuned to that same frequency. Effective or usable range depends on a number of factors. In general, higher power and lower frequency increase the range at which a signal can be detected. Distance from the signal source and interference from intervening objects or other signals all tend to degrade reception. Filtering, accurate synchronous timing, and a variety of error correcting approaches can help distinguish the true signal from reflections and interference.

Information is carried by modulating the radio waves. In spread spectrum technologies, additional information is packed into a relatively small range of frequencies (a section of bandwidth called a channel) by having both sender and receiver use the same set of codes, such that each small modulation of the set of radio waves carries the greatest possible information. Direct sequence spread spectrum (DSSS) is one particular approach to packing more data into a given piece of RF spectrum. OFDM is another.

The FCC in the United States and other bodies internationally control the use of RF spectrum and limit the output power of devices. The 802.11 WLAN standards attempt to deliver maximum performance within the limits set by these bodies, current radio technology and the laws of physics.

Low output power, for example, limits 802.11 WLAN transmissions to fairly short effective ranges measured in hundreds of feet. Signal quality, and hence network throughput, diminishes with distance and interference. The higher data rates rely on more complex spectrum spreading techniques. These in turn require an ability to distinguish very subtle modulations in the RF signals.

Signal and noise measurement

The electrical energy in radio waves and other electrical signals is often measured in the unit of power Watts or, in the case of 802.11 WLANs, milliWatts (mW). For example, a typical 802.11b WLAN card might have a transmit power of 32 mW. The energy detected at the receiving antenna would be several orders of magnitude smaller than this. The wide range of values encountered in radio engineering could be expressed with exponential notation, but radio engineers came up with a simpler solution. They measure signal strength with a unit called the decibel-milliWatt, or dBm.

A decibel is simply a unit of relationship between two power measurements. It is, in fact, one tenth of the exponent of ten. That is, 10 decibels denotes an increase by a factor of 10, 20 decibels an increase by a factor of 100, and 30 decibels an increase by a factor of 1,000. These correspond to 10 raised to the power of (10/10), 10 raised to the power of (20/10), and 10 raised to the power of (30/10), respectively.

Decibels are dimensionless. By associating decibels with a particular unit, it is possible to write and compare a wide range of power values easily. By the definition of the decibel milliwatt, 0 dBm = 1 mW. Power values larger than 1 mW are positive numbers. Power values smaller than 1 mW are expressed as negative numbers. Remember, this is an exponent. For example, the power output of 32mW mentioned above could be written as 15 dBm. A typical lower limit of antenna sensitivity for an 802.11b WLAN card might be expressed as -83 dBm. A more practical lower limit might be -50 dBm, or 0.00001 mW.

Not all 802.11 WLAN cards report signal strength in dBm. The 802.11 WLAN standard itself calls for makers to implement their own scale of received signal strength, and report that within the protocol as a value called Received Signal Strength Indicator (RSSI). While one manufacturer might use a scale of 0-31, another might use 0-63. Omnipeek regularizes these values to a percentage and reports them as signal strength.

Noise is also a form of electrical energy, and is reported in the same way, either as a percentage or in dBm. The signal to noise ratio is simply the difference between signal and noise.

Transmission rates and channels

To overcome signal degradation problems, 802.11 WLANs can gracefully step down to a slower but more robust transmission method when conditions are poor, then step back up again when conditions improve.

The full set of data rates for all three standards is shown in Table C.1. For 802.11a WLANs, the 6, 12, and 24 Mbps data rates are mandatory, all others are optional. The 802.11g WLANs will support all the same data rates as 802.11a WLANs when communicating with other 802.11g WLAN nodes, but can also use the same rates as the 802.11b WLAN when communicating with nodes using that older standard. In addition, 802.11g WLANs may support rates in the range of 22 Mbps using optional encoding methods such as PBCC.


Table C.1 Supported data rates by WLAN standard




1 Mbps

1 Mbps

2 Mbps

2 Mbps

5.5 Mbps

5.5 Mbps

6 Mbps

6 Mbps

9 Mbps

9 Mbps

11 Mbps

11 Mbps

12 Mbps

12 Mbps

22 Mbps

24 Mbps

24 Mbps

36 Mbps

36 Mbps

48 Mbps

48 Mbps

The 802.11b WLAN standard uses DSSS in the 2.4 GHz band. Taking 2412 MHz as the center frequency of the first channel, the standard described 14 channels, 5 MHz apart, numbered 1 to 14. In the United States, the FCC allocated bandwidth to support the first 11 channels. Regulatory bodies in other jurisdictions made different allocations from within this same band.

The 802.11g WLAN standard uses the same spectrum and channels as 802.11b WLANs, but uses the OFDM encoding and transmission methods of the 802.11a WLAN standard when communicating with other 802.11g WLAN nodes.

The 802.11a WLAN standard uses OFDM in the 5.0 GHz band. The standard defines channels 1-199, starting at 5.005 GHz, with their center frequencies spaced 5 MHz apart. The FCC in the United States has allocated bandwidth in three parts of the spectrum, as shown in Table C.2. The ETSI and ERM in Europe, MKK in Japan, and other regulatory agencies in other jurisdictions have made their own allocations within this band.

Table C.2 FCC Channels for 802.11a WLANs


Center frequency

Channel number

Maximum power
U-NII low band (5150 MHz to 5250 MHz)

5180 MHz

40 mW
5200 MHz

40 mW
5220 MHz

40 mW
5240 MHz

40 mW
U-NII medium band (5250 MHz to 5350 MHz)

5260 MHz

200 mW
5280 MHz

200 mW
5300 MHz

200 mW
5320 MHz

200 mW
U-NII high band (for outdoor use) (5725 MHz to 5825 MHz)

5745 MHz

800 mW
5765 MHz

800 mW
5785 MHz

800 mW
5805 MHz

800 mW

Notice that the channel numbers for 802.11a WLANs appear in a gapped sequence, with 20 MHz separating the center frequency of one allocated channel from the next. This is a recognition of the fact that the spectrum spreading approaches used in all 802.11 WLAN standards actually take up far more spectrum than 5 MHz. In fact an active channel fills more than 16 MHz.

Note:   802.11a WLAN cards based on the Atheros chip set may support a proprietary mode called Turbo Mode (specific card vendors may use other names). Turbo Mode doubles the standard data rates and uses twice the RF spectrum specified for a normal channel in the 802.11a WLAN standard. For more information, please visit the support pages of our website, at:

Collision avoidance and media access

One of the most significant differences between Ethernet and 802.11 WLANs is the way in which they control access to the medium, determining who may talk and when. Ethernet uses CSMA/CD (carrier sense multiple access with collision detection). This is possible because an Ethernet device can send and listen to the wire at the same time, detecting the pattern that shows a collision is taking place. When a radio attempts to transmit and listen on the same channel at the same time, its own transmission drowns out all other signals. Collision detection is impossible.

The carrier sense capability of Ethernet and WLANs is also different. On an Ethernet segment, all stations are within range of one another at all times, by definition. When the medium seems clear, it is clear. Only a simultaneous start of transmissions results in a collision. As shown in Figure C.6, nodes on a WLAN cannot always tell by listening alone whether or not the medium is in fact clear.

Figure C.6 Basic Service Set (BSS), showing the hidden node problem.

In a wireless network, a device can be in range of two others, neither of which can hear the other, but both of which can hear the first device. The access point in Figure C.6 can hear both node A and node B, but neither A nor B can hear each other. This creates a situation in which the access point could be receiving a transmission from node B without node A sensing that node B is transmitting. Node A, sensing no activity on the channel, might then begin transmitting, jamming the access point’s reception of node B’s transmission already under way. This is known as the “hidden node” problem.

To solve the hidden node problem and overcome the impossibility of collision detection, 802.11 WLANs use CSMA/CA (carrier sense multiple access with collision avoidance). Under CSMA/CA, devices use a four-way handshake (Figure C.7) to gain access to the airwaves to ensure collision avoidance. To send a direct transmission to another node, the source node puts a short Request To Send (RTS) packet on the air, addressed to the intended destination. If that destination hears the transmission and is able to receive, it replies with a short Clear to Send (CTS) packet. The initiating node then sends the data, and the recipient acknowledges all transmitted packets by returning a short ACK (Acknowledgement) packet for every transmitted packet received.

The 802.11g WLAN standard uses this RTS/CTS method only when it detects nodes using 802.11b transmissions. Because the RTS/CTS in these mixed b/g networks must be sent in a form compatible with the older and slower 802.11b WLAN standards, this reduces the overall throughput of 802.11g WLANs, particularly near the top end of their performance, by something on the order or 20-50%.

Figure C.7 A Four-Way Handshake ensures collision avoidance in 802.11 networks.

Timing is critical to mediating access to the airwaves in WLANs. To ensure synchronization, access points or their functional equivalents periodically send beacons and timing information.

Wireless LAN topologies

Wireless LANs behave slightly differently depending on their topology, or make-up of member nodes. The simplest arrangement is an ad hoc group of independent wireless nodes communicating on a peer-to-peer basis, as shown in Figure C.8. The standard refers to this topology as an Independent Basic Service Set (IBSS) and provides for some measure of coordination by electing one node from the group to act as the proxy for the missing access point or base station found in more complex topologies. Ad hoc networks allow for flexible and cost-effective arrangements in a variety of work environments, including hard-to-wire locations and temporary setups such as a group of laptops in a conference room.

Figure C.8 An IBSS or “Ad Hoc” Network.

The more complex topologies, referred to as infrastructure topologies, include at least one access point or base station. Access points provide synchronization and coordination, forwarding of broadcast packets and, perhaps most significantly, a bridge to the wired network.

The standard refers to a topology with a single access point as a Basic Service Set (BSS) as shown in Figure C.6. A single access point can manage and bridge wireless communications for all the devices within range and operating on the same channel.

To cover a larger area, multiple access points are deployed. This arrangement (shown in Figure C.9) is called an Extended Service Set (ESS). It is defined as two or more Basic Service Sets connecting to the same wired network. Each access point is assigned a different channel wherever possible to minimize interference. If a channel must be reused, it is best to assign the reused channel to the access points that are the least likely to interfere with one another.

Figure C.9 Extended Service Set (ESS) supports roaming from one cell to another.

When users roam between cells or BSSs, their mobile device will find and attempt to connect with the access point with the clearest signal and the least amount of network traffic. This way, a roaming unit can transition seamlessly from one access point in the system to another, without losing network connectivity.

An ESS introduces the possibility of forwarding traffic from one radio cell (the range covered by a single access point) to another over the wired network. This combination of access points and the wired network connecting them is referred to as the Distribution System (DS). Messages sent from a wireless device in one BSS to a device in a different BSS by way of the wired network are said to be sent by way of the distribution system or DS.

Note:   To meet the needs of mobile radio communications, 802.11 WLAN standards must be tolerant of connections being dropped and reestablished. The standards attempt to ensure minimum disruption to data delivery, and provide some features for caching and forwarding messages between BSSs. Particular implementations of some higher layer protocols such as TCP/IP may be less tolerant. For example, in a network where DHCP is used to assign IP addresses, a roaming node may lose its connection when it moves across cell boundaries and have to reestablish it when it enters the next BSS or cell. Software solutions are available to address this particular problem. In addition, IEEE may revise the standards in ways that mitigate this problem in future versions.

Whether they have one base station or many, most corporate WLANs will operate in infrastructure mode to access servers, printers, Internet connections and other resources already established on wired networks. Even users seeking an “all wireless” solution may find that an access point does a better job of mediating communications with an Internet connection, for example, and is worth the additional expense.

Authentication and privacy

Authentication restricts the ability to send and receive on the network. Privacy ensures that eavesdroppers cannot read network traffic.

Authentication can be open or based on knowledge of a shared token. In either case, authentication is the first step for a device attempting to connect to an 802.11 WLAN. The function is handled by an exchange of management packets. If authentication is open, then any standards-compliant device will be authenticated. If authentication is based on a shared token, then a device must prove it knows this shared token in order to be authenticated.

WEP (Wired Equivalent Privacy) is a data encryption technique supported as an option in the 802.11 WLAN protocols. The technique uses shared keys and a pseudo random number (PRN) as an initial vector (IV) to encrypt the data portion of network packets. The 802.11 WLAN network headers themselves are not encrypted.

The designers’ purpose in supporting this feature was to give a wireless network, with its inherent vulnerability to eavesdropping, a level of security similar to that enjoyed by a wired network operating without encryption. Eavesdropping on a wired network, they reasoned, requires a physical network tap or a suite of sophisticated radio listening devices. Eavesdropping on a radio network requires only a device capable of listening on the same channel or frequency. Since all 802.11 WLAN network adapters are capable of listening on any of the usable channels, eavesdropping is almost a certainty, given a large enough number of devices in circulation.

The original WEP specification called for 64 bit key length encryption. In part, this was an explicit effort to make commercial implementations of the protocol exportable from the U.S. in an era when only the very weakest encryption technologies were granted export licenses. The standard’s support for such a weak encryption method also underlines the design function of encryption in this protocol. It is intended to stop casual eavesdropping, not to stop a concerted attack. Several vendors now support 64-bit, 128-bit, or larger key lengths. This significantly increases the barriers to attack, but even at 128-bit key lengths, WEP is still the door to an office, not a bank vault. Any of these levels of encryption serves the primary purpose of WEP quite well.

Because WEP encrypts all the data above the 802.11 WLAN layers, it can prevent Omnipeek from decoding higher level network protocols, and so prevent accurate troubleshooting of problems with TCP/IP, IPX, NetBEUI and so forth. To overcome this limitation, Omnipeek allows users to specify the WEP shared key set for their network. This allows Omnipeek to decode the network data contained in 802.11 WLAN packets in the same way that every other station on the user’s network does.

Note:   Although it is possible to implement WEP with open authentication, this is strongly discouraged as it leaves the door open for intruders to collect enough information to compromise the security of WEP.

Toward improved security

The authentication and encryption methods supported in the original 802.11 WLAN standards provide only a minimal level of security. IEEE is currently working on a new specification for authentication and privacy, 802.11i, which is expected to be finalized by the end of 2003. In the interim, the WiFi Alliance has published a set of guidelines for implementing enhanced security measures called WPA (WiFi Protected Access). The equipment vendor Cisco Systems also provides its own proprietary implementations of earlier drafts of the 802.11i standard in some of its products.

Omnipeek can decode the most commonly used forms of authentication from among these interim offerings. This allows you to identify the methods in use on your network. All of the new authentication methods are based on the Extensible Authentication Protocol (EAP). The methods decoded by Omnipeek are: EAPTLS (EAP using Transport Level Security), PEAP (Protected EAP), and Cisco’s LEAP (Lightweight EAP). Note that while Omnipeek can decode these protocols, some implementations encrypt the authentication traffic in such a way as to make the packets unreadable by any outside observer, including Omnipeek.

The primary weakness of the original implementation of WEP was the small number of keys and their frequent reuse. Even larger key lengths cannot defend against attacks aimed at this weakness. To overcome this weakness, early drafts of 802.11i called for better key management. The WiFi Alliance offered an interim solution adopting TKIP (Temporal Key Integrity Protocol). Cisco deployed its proprietary CKIP (Cisco Key Integrity Protocol) in some of its products. Omnipeek can identify the method in use for either type of system. Both TKIP and CKIP improve the security of encryption methods by dramatically reducing the reuse of keys. Keys are generated dynamically and replaced very frequently. This eliminates the primary weakness of the original WEP implementations with their user-entered keys and infrequent re-keying.

Packet structure and packet types

Like the rest of the 802 family of LAN protocols, 802.11 WLAN sends all network traffic in packets. There are three basic types: data packets, network management packets and control packets. The first section describes the basic structure of 802.11 WLAN data packets and the information they provide for network analysis. The second section describes the management and control packets, their functions and the role they play in network analysis.

Packet structure

All the functionality of the protocol is reflected in the packet headers. RF technology and station mobility impose some complex requirements on 802.11 WLAN networks. This added complexity is reflected in the long physical layer convergence protocol (PLCP) headers as well as the data-rich MAC header.

Figure C.10 802.11 WLAN data packet structure

Because 802.11 WLANs must be able to form and re-form their membership constantly, and because radio transmission conditions themselves can change, coordination becomes a large issue in WLANs. Management and control packets are dedicated to these coordination functions. In addition, the headers of ordinary data packets contain a great deal more information about network conditions and topology than, for example, the headers of Ethernet data packets would contain.

Figure C.11 Comparison of MAC headers: 802.11 WLAN to 802.3 Ethernet

A complete breakout of all the fields in the packet headers and the values they may take is found in the next section. For this overview, Table C.3 below presents a list of the types of information 802.11 WLAN data packet headers convey. The table also shows the types of information carried in management and control packets.

Table C.3 Protocol functions in 802.11 WLANs

Authentication / Privacy
The first step for a device in joining a BSS or IBSS is authentication. This can be an open or a shared key system. If WEP encryption of packet data is enabled, shared key authentication should be used. Authentication is handled by a request/response exchange of management packets.
authentication ID This is the name under which the current station authenticated itself on joining the network.
WEP enabled If this field is true, then the payload of the packet (but not the WLAN headers) will be encrypted using Wired Equivalent Privacy.

Network membership / Topology
The second step for a device joining a BSS or IBSS is to associate itself with the group, or with the access point. When roaming, a unit also needs to disassociate and reassociate. These functions are handled by an exchange of management packets. The current status is shown in packet headers.
association Packets can show the current association of the sender. Association and Reassociation are handled by request/response management packets. Disassociation is a simple declaration from either an access point or a device.
IBSSID or ESSID The ID of the group or its access point. A device can only be associated with one access point (shown by the ESSID) or IBSS at a time.
probe Probes are supported by request/response management packets used by roaming devices in search of a particular BSS or access point. They support a roaming unit’s ability to move between cells while remaining connected.

Network conditions / Transmission
The 802.11 WLAN protocol supports rapid adjustment to changing conditions, always seeking the best throughput.
channel The channel or radio frequency used for the transmission
data rate The data rate used to transmit the packet. 802.11 WLAN nodes can rapidly adjust their transmission data rate to match conditions.
fragmentation 802.11 WLANs impose their own fragmentation on packets, completely independent of any fragmentation imposed by higher level protocols such as TCP/IP. A series of short transmissions is less vulnerable to interference in noisy environments. This fragmentation is dynamically set by the protocol in an effort to reduce the number, or at least the cost, of retransmissions.
synchronization Several kinds of synchronization are important in WLANs. Network management packets called “beacon” packets keep members of a BSS synchronized. In addition, devices report the state of their own internal synchronization. Finally, all transmissions contain a timestamp.
power save Laptops in particular need to conserve power. To facilitate this, the protocol uses a number of fields in data packets plus the PS-Poll (power save-poll) control packet to let devices remain connected to the network while in power save mode.

Transmission control
While the protocol as a whole actually controls the transmission of data, certain header fields and control packets have this as their particular job:
RTS, CTS, ACK Request to send, clear to send, and acknowledgement, respectively, these control packets are used in the four way handshake in support of collision avoidance.
version The version of the 802.11 protocol used in constructing the packet.
type and sub-type The type of packet (data, management, or control), with a sub-type specifying its exact function.
duration In support of synchronization and orderly access to the airwaves, packets contain a precise value for the time that should be allotted for the remainder of the transaction of which this packet is a part.
length Packet length
retransmission Retransmissions are common. It is important to declare which packets are retransmissions.
sequence Sequence information in packets helps reduce retransmissions and other potential errors.
order Some data, such as voice communications, must be handled in strict order at the receiving end.

Again, many fields are related to routing traffic, but the following are most directly related:
addresses There are four address fields in 802.11 WLAN data packets, instead of the two found in Ethernet or IP headers. This is to accommodate the possibility of forwarding to, from, or through the distribution system (DS). In addition to the normal Destination and Source addresses, these fields may show the Transmitter, the Receiver, or the BSSID. The type of address shown in each address field depends on whether (and how) the packet is routed by way of the DS. Control and management packets need only three address fields because they can never be routed both to and from (that is, through) the DS.
to/from DS In an ESS, traffic can be routed from a device using one access point to a device using a different access point somewhere along the wired network. These fields describe routing through the distribution system (DS) and tell the receiving device how to interpret the address fields.
more data Access points can cache data for other devices. This serves both roaming across BSS or cell boundaries and the power save features. When a device receives a message from an access point, it may be told the access point has more data waiting for it as well.

Management and control packets

Control packets are short transmissions which directly mediate or control communications. Control packets include the RTS, CTS and ACK packets used in the four way handshake (see Figure C.7), as well as power save polling packets and short packets to show (or show and acknowledge) the end of contention-free periods within a particular BSS or IBSS.

Management packets are used to support authentication, association, and synchronization. Their formats are similar to those of data packets, but with fewer fields in the MAC header. In addition, management packets may have data fields of fixed or variable length, as defined by their particular sub-type. The types of information included in management and control packets are shown in Table C.3, along with the related information found in data packet headers.

For a complete list of control and management packets and their functions, please see Appendix E, “802.11 WLAN Packet Types”.

802.11 WLAN frames and packet headers

This section describes the various layers of 802.11 WLAN packet headers and the clues they contain to the protocols found in the network data which they frame. The typical 802.11 packet frames the network data inside a physical layer header, followed by a MAC layer header with a FCS trailer for error control. All versions of 802.11 support use of the 802.2 standard for Logical Link Control or LLC.

Figure C.12 802.11 packet structure

As Figure C.12 above shows, the hardware preamble, packet start delimiter and end delimiter bytes are not captured by Omnipeek. The PLCP header is used by network hardware to control the transmission and maintain the physical (in this case, radio wave) link between stations. Higher layers in the packet, beginning with the MAC header, are captured by OmniPeek and presented both as raw data and as decoded data.


802.11 WLAN protocols permit negotiation of transmission rates for each session. They also permit changes in packet fragmentation to improve overall throughput under changing conditions. To support these functions, they use a physical layer header called the PLCP (Physical Layer Convergence Protocol), consisting of a PLCP preamble and the PLCP header.

The physical layers of the 802.11a WLAN and the 802.11b WLAN are different, and so the PLCP is distinct for each. Even so, they have important similarities. In both standards, the PLCP header is transmitted immediately after an initial synchronization or training sequence, and immediately before the MAC header. In both standards, the PLCP header contains information on the rate and length of the rest of the packet.

Whether the packet length is expressed in bytes or as a unit of time, receiving stations can use the PLCP header to determine how much time should be allowed for transmission of this packet. Even if a receiver does not support the data rate requested in the packet, it knows how long to wait before the channel will again be clear. PLCP header also contains error correction and information on the encoding scheme (related to data rate) used in the remainder of the packet.

The PLCP portion of the transmission is always sent at the lowest commonly supported data rate, to insure maximum reliability and compatibility with other stations.

802.11 MAC header

The particular format of the 802.11 MAC header depends on the type of packet: data packets, network management packets or control packets. The description which follows (based on Figure C.13) is for an 802.11 WLAN data packet. Management and control packets have only the first three of the four address fields. They may also contain information in the frame body in fields of fixed or variable length which are specific to that particular type and subtype of packet.

Figure C.13 802.11 MAC header

The Frame Control field is 2 bytes long. Its contents are broken out in detail at the bottom of Figure C.13 and are described below. The Duration ID field is 2 bytes long and contains the duration value for each of the fields. For control packets this field also carries the association identity (AID) of the transmitting station. There are four address fields rather than the expected two (as in Ethernet or IP) to accommodate the possibility of message relay. Which address appears in what field depends on whether the packet is being forwarded through the Distribution System (DS). The values of the To DS and From DS bits in the Frame Control field determine the content of the address fields, as shown in Table C.4. The Sequence Control field is 2 bytes and is used to filter out duplicate messages, such as a message sent again because an earlier one was not acknowledged.

Table C.4 Address Fields in 802.11 MAC header


From DS

Address 1

Address 2

Address 3

Address 4

























The bit-wise breakdown of the Frame Control field is as follows: The first two bits are the Protocol Version and tell which version of 802.11 is to follow. The Type field (2 bits) and the Sub Type field (4 bits) work together to describe the type of frame and its function. The To DS and From DS fields are one bit each and are set to 1 for true and 0 for false, indicating whether the packet was sent to or from the Distribution System. For messages within a single BSS (Basic Service Set), both of these fields would be set to 0. The More Fragments bit would be set to 1 if there were more fragments of the current packet.

Note:   The fragmentation noted in the MAC header is that imposed by the 802.11 node to accommodate changing transmission conditions. Large packets are more susceptible to corruption by radio interference than smaller ones, so a node may increase fragmentation to reduce retransmissions in conditions of heavy interference.

The Retry bit is set to 1 if the current packet is a retransmission of a previous attempt. The Power Management bit is set to 1 if the node will enter power save mode after the current transmission or 0 if the node will be active. The More Data bit is set to 1 if packets have been buffered and are waiting to be delivered to the destination node. The WEP (Wired Equivalent Privacy) bit is set to 1 if the content (payload) of the packet has been encrypted using the WEP algorithm. The Order bit is set to 1 if the packets must be strictly ordered, as with voice over IP, for example.

Note:   The MAC (Media Access Control) address is the physical address of a particular Network Interface Card (NIC) or other physical layer network device. For more information on addressing, please see Appendix D, “802.11 WLAN Addresses and Names”.

802.2 headers

Like all LAN protocols in the IEEE 802 family, 802.11 permits the use of the 802.2 protocol for Logical Link Control (LLC). The 802.2 header, usually called the LLC, contains information about the protocol type of the packet. These 802.2 headers are either 3 bytes or 8 bytes long. The first section of the LLC header is 3 bytes long and contains two LSAP values and one LSAP command. These LSAP values can either contain information about the protocol of the packet, or they can point to the optional 5 byte SNAP section that follows. If they point to the SNAP section of the header then the protocol is described by this 5 byte Protocol Discriminator or SNAP ID.

The LSAP Values and the SNAP IDs are described in the next two sections.

802.2 LSAP values

In OmniPeek, the 1-byte protocol type specifications found in the first 3 byte section of the 802.2 LLC header are referred to as 802.2 LSAP values.

The first three bytes of an 802.2 LLC header are as follows:

    • The first byte is the Destination Service Access Point (DSAP), which designates a destination protocol.


    • The second byte is the Source Service Access Point (SSAP), which designates a source protocol, most often set to the same value as the DSAP.
  • The third byte is a control byte that indicates the data format in the packet. This byte is ignored by most protocols (except SNA).

Figure C.14 802.2 LSAP values in the 802.2 LLC Header

The DSAP and SSAP fields are referred to collectively as the LSAP (Link layer Service Access Point).

Note:   The 1-byte hexadecimal number in these fields can be used to identify the specific 802.2 LSAP protocol in a filter. For example, XNS uses this LSAP value: 0x80.

802.2 SNAP IDs

When both the DSAP and SSAP are set to 0xAA, the type is interpreted as a protocol not defined by IEEE and the LSAP is referred to as SubNetwork Access Protocol (SNAP).

In SNAP, the 5 bytes that follow the DSAP, SSAP, and control byte are called the Protocol Discriminator.

In Omnipeek, protocol type specifications found in this optional 5-byte SNAP section of the 802.2 header are referred to as 802.2 SNAP IDs. The following figure shows an example of an 802.2 header with a SNAP ID.


Figure C.15 802.2 Header with SNAP ID

Error packets

Omnipeek recognizes only one error type, CRC, shown in the table below:

Table C.5 Error Types

Error Type

CRC Error At the end of the packet, four bytes are transmitted which force the checksum to a known constant. If the receiving end does not compute the same constant after receiving the four bytes, the packet must have been corrupted. A CRC error occurs when the CRC (Cyclic-Redundancy Check) fails. These bytes are referred to as a Frame Check Sequence or FCS.

The data in an error packet, including the source and destination physical addresses, should be viewed with caution since it may have little correspondence to what was originally transmitted. Packets flagged as errors are processed by Network, Summary, Size, and History statistics. In Network Statistics, error packets contribute only to overall packet and byte counts, not to broadcast or multicast counts. Node, Protocol, and Conversation statistics do not process error packets, nor do the standard Analysis Modules that ship with Omnipeek.