Packets and Protocols

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.

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 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.

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.

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.

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. 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.