Ask Your Question
0

Wlan packet radio duration sometimes larger than inter-packet delay

asked 2017-10-30 04:46:37 +0000

mi gravatar image

updated 2017-11-01 13:21:03 +0000

In my .pcap file captured in WLAN, I am getting the duration of the current packet more than the difference between capture times of current and next packets.

How come is it possible? If such a thing happened, it will mean that the first packet was still being captured when the next packet arrived. For example, for two packets, capture times are T1=0.002124s, T2=0.003407s, so T2-T1=0.001283s, and the duration of the first packet (given by the wlan_radio.duration display filter), D=0.002112s, which makes D>T2-T1. So, which one is correct: the duration field displayed by the Wireshark, or the packet capture times?

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted
1

answered 2017-11-01 04:29:51 +0000

Jim Young gravatar image

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.

edit flag offensive delete link more

Comments

Can you please tell me where to disable preference, as I can see under the Edit->Preferences->.protocols a menu name IEEE802.11 and IEEERariotap, but I can't find the "TSF indicates the end of the PPDU" preference under these.

mi gravatar imagemi ( 2017-11-01 09:13:05 +0000 )edit

You'll find it at '802.11 Radio' protocol preferences.

Jaap gravatar imageJaap ( 2017-11-01 09:44:42 +0000 )edit

In the preferences under Edit menu, there is only 'IEEE Raditap' protocol preference, and that shows only two fields: 'Assume bit 14 means FCS in header' and 'Interpret High rates as MCS'. Is there any other path?

mi gravatar imagemi ( 2017-11-01 12:15:03 +0000 )edit

Wireshark version?

Jaap gravatar imageJaap ( 2017-11-01 13:26:52 +0000 )edit

Version 2.2.6, running on Ubuntu 16.06

mi gravatar imagemi ( 2017-11-01 13:38:21 +0000 )edit
0

answered 2017-11-03 03:09:58 +0000

Jim Young gravatar image

updated 2017-11-03 06:48:39 +0000

Jaap gravatar image

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.

edit flag offensive delete link more

Comments

Thank you. I will see it.

mi gravatar imagemi ( 2017-11-03 06:17:50 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

Stats

Asked: 2017-10-30 04:46:37 +0000

Seen: 161 times

Last updated: Nov 03