The duration/id field is a very interesting field. It's a field that has two purposes, Duration or Association ID. Depending on the frame type in a transmission it could yield two entirely different pieces of information.
802.11 standard - 126.96.36.199 Duration/ID field
Assume for a moment a client observes a beacon and in that beacon the TIM field has a clients association ID listed. This alerts the client there is traffic buffered at the access point. The client retrieves this buffered traffic by sending a PS-POLL frame. Inside this PS-POLL frame it includes its association ID in the Duration/ID field. While PS-POLL is legacy and was replaced with UAPSD, its still seen in the wild.
Assume for a moment an access point triggers a data frame on the wireless channel. Inside that data frame the duration ID has a value in microseconds. This value is the amount of airtime the sending radio is reserving for the pending acknowledgment frame. Radios on channel in ear shot of this transmission who can demodulate this frame will use this value in their NAV calculation. In this example you will see an ACK frame with the duration ID of zero. This is because the previous data frame reserved the medium long enough for the pending ACK.
Example of how the field is used for either Association ID (left) or Duration (right).
802.11 standard - Table 8.3 Duration/ID field encoding
The possible values this field can contain
Real World Example:
RTS Frame - Duration 1160 Microseconds
The RTS frame is a Request to Send. A radio is asking for permission to reserve airtime to transmit a pending transmission. The receive radio can allow or deny this request. More on RTS/CTS in a bit. But note the larger duration time.
Beacon Frame - Duration 0 Microseconds
The duration field of a beacon is zero. This is because there is no pending ACK for this frame type. You might be wondering how did the radios on channel know this frame was in transit. What you don't see in layer 2 frames is the layer 1 preamble and PHY header transmission. This information is a series of bits 0's and 1's. Radios on channel will read the length of the pending frame from the PHY header, in this case the pending beacon transmission and calculate how much time they need to be busy (listen) for to allow this frame to transmit. In other words, radios on channel hear the preamble and PHY header and prime themselves for the pending frame you read in your Layer 2 Analyzers.
CWAP: “ The transmitting station will precede that data portion of the frame with a preamble. This preamble contains a string of 0s and 1s that the receiving station can identify and synchronize with, essentially alerting the receiving station to the transmission. The preamble also includes a Start Frame Delimiter field, which the receiving station uses to identify the beginning of the frame. After the preamble, the length field in the frame header tells the receiving station how long the frame is.”
RTS/CTS Frames - 352 / 245 Microseconds
The duration timer in RTS/CTS frames are interesting. The RTS frame in this example reserves airtime in the amount of 352 microseconds which includes the next pending frames RTS and DATA. The CTS (Clear to Send) responds with a lower duration timer, again reserving airtime keeping radios on channel at bay so not to talk over the pending tranmission.
CWAP: “ The Duration value of the RTS frame includes the time needed for the subsequent frames in the transmit operation to be transmitted. This value is in microseconds. All listening stations will set their NAV timers to this value and cannot contend for the medium or transmit data until their NAV counts down to 0. After the RTS frame is transmitted, the receiving station responds by sending a 14-octet CTS control frame (Figure 5-4). The Duration value of the CTS frame includes the time needed for the subsequent frames in the transmit operation to be transmitted.”
CRC frames can display some crazy data. Check out this duration value! Of course this value is bogus and the a radio who fails to calculate this frame (CRC) will do an EIFS.
Check out Andrew von Nagy's post on "Understanding 802.11 Medium Contention"
What fields in 802.11 frame interest you the most ?