Wlan packet radio duration sometimes larger than inter-packet delay

savecancel

You might need to disable the 802.11 radio information preference "TSF indicates the end of the PPDU". This preference is enabled by default. The fly-over comment associated with this option states "Some generators timestamp the end of the PPDU rather then the start of the (A)MPDU." In this context "generators" meaning the the device that created the wlan packet capture. I need to disable this preference for captures generated by my MacBook to avoid the same issue you appear to be having.

Your T1 and T2 values are the timestamps of the packets as recorded by the OS. Packet timestamps are not necessarily the instant that the start of the packets were seen by the WLAN interface. CPU scheduling and processing overhead can delay when the packets are timestamped causing the reported delay between two packets to be shorter or longer than was actually seen at the NIC. In the case of the WLAN packets, depending on the hardware and software, there's the opportunity of recording and reporting of the NIC's TSF value. The Radiotap header tree may include the TSF value as the MAC timestamp (radiotap.mactime) and the 802.11 radio information tree may include this value as the TSF timestamp (wlanradio.timestamp). The WLAN Duration field (wlanradio.duration) is a best effort calculated field based on the TSF. Recent enhancements to the 802.11 dissector have improved the calculation of the Duration field and includes some extra fields to help confirm the math.