This is a static archive of our old Q&A Site. Please post any new questions and answers at

Filtering Packet Duration in Tshark.


I need to filter out either option A or option A below of a pcap file:

A. The connection speed of a transmission (aka mbps), the number of bits for that packet transmission, and the starting time of the transmission; may need to be of a specific protocol
B. The duration (or life) of the packet transmission, and the starting time of the packet transmission.

Here is the code I currently have, which exports only the packet start time of ip transmissions:
"C:\Program Files\Wireshark\tshark.exe” -r "%~1" -P -Y "ip" -o "uat:user_dlts:\"User 8 (DLT=155)\",\"pxt\",\"0\",\"\",\"0\",\"\"" -o "gui.column.format:\"Time\", \"%t\"" > "%~1.txt”

  1. The "%~1" allows me to drag and drop the *.pcap file onto a batch file
  2. The "uat:..." converts the data so that it is readable due to the nature of the pcap file (otherwise the filter returns a blank output file for me). Most likely won't apply to how you use Wireshark/Tshark
  3. the "gui.format" exports the time of the transmission
  4. What we need to add is either A. or B. as listed above.
  5. I know I can use -o "gui.column.format:\"Length\", \"%L\"" to retrieve the length, but the more important part is the duration information.

The problem I am having is that I am not finding anything that allows me to export the specific information listed in either A. or B. Any help would be appreciated.

PS: I do know that "ip.len" can be used to find instances of specific lengths, but I want to find the lengths of specific instances (aka certain protocols or simply a transmission occurrence).

Need a response as soon as possible, if possible.

asked 16 Dec '15, 12:49

Midimistro's gravatar image

accept rate: 50%

edited 16 Dec '15, 13:01

One Answer:


If I get you right, you need to calculate an average transmission speed, calculated as (sum of lengths of all packets meeting the display filter) / (timestamp of the last packet - timestamp of the first packet). One way, which allows you to use your favourite scripting language, would be to let tshark display tuples (frame.time_relative,frame.len) and pipe its output to a post-process script which would calculate the result; another, "all Wireshark" way, would be to use a Lua listener to do the same thing. The point is that a display filter can work with real and forged fields of individual frames, but forged fields providing summary or delta values from several frames exist only in some dissectors (e.g., request-to-response time in SMB or SMB2). So one way or another, you need to summarize the time elapsed and bytes transferred "manually", i.e. on top of the normal dissector operation.

answered 16 Dec '15, 13:31

sindy's gravatar image

accept rate: 24%

edited 16 Dec '15, 13:37

Not really. I need to print out the life of the packet for that instance (aka how long the packet was present in the network) to a text file. If programmed right, I can do this by using the the length (aka # of bytes, converted to bits using MATLAB) multiplied by the connection speed (in say Mbps), and calculating the life in MATLAB. What I can't seem to find is the information regarding the connection speed. The other possible way would be if Wireshark provides the duration, or life of the packet straight up. Either method will do, but as stated, I'm looking for packet life, not gaps between each packet.

Alternatively, do you know what "DLT" means in the encapsulation preferences? That might help solve this problem if it is the download rate... If not, I need the speed.

(16 Dec '15, 13:43) Midimistro

In that case, you've bumped the wall. While the pcapng format specification foresees interface speed as a parameter (of an interface, not of each single frame captured at that interface), WinPcap does not fetch that information from the OS and store it to the file, and even if it would be present in the file, Wireshark does not make it accessible as a forged field associated to a frame anyway.

In generic case it is not a big information loss because what you would get would be nothing more and nothing less than the bit rate of the interface on which you took the capture, but the packet may have passed through slower connections, so what would be the value of the information about its duration on the last (nearest to the capture point) link out of the whole path? On the contrary, if you know that the sending side is sending as fast as the media to which it is directly connected permits, the difference of timestamps of two subsequent packets gives you a hint about the transmission speed of the slowest link in the path (provided that no other traffic shares the bandwidth of that link of course).

So should that approach suit you, you could use frame.len, frame.time_delta_displayed to feed your Matlab.

(16 Dec '15, 14:07) sindy

An afterthought - I take some things for obvious while they may not be for someone else. Already at early times of tcpdump, all network interface cards (NICs) had their local buffers or direct access to the common RAM, so the process of packet reception was their autonomous business and the CPU (or operating system, or kernel, however you prefer to think about it) has received a single signal "a packet has been received" when the autonomous reception process has been completed. I.e. the CPU was not involved in handling every single bit of the packet. On the other hand, the NIC hardware had got no notion of real time because for normal deployment there was no need to indicate the duration of the packet (or the time when the first and last bit have been received). Even the shortest timeouts of request/response protocol timeouts start several orders of magnitude above the bit duration because most routers and even switches in the network work on a store-and-forward basis, so each packet must first be completely received before being sent further.

Therefore, on a common NIC, the capturing software has no primary source of information about packet duration which it could pass on. Even worse, it even has no information about the moment of packet arrival, so it asks the kernel for current time at the moment it picks up the packet from the driver. This means that there is a difference between the moment of physical arrival of the packet and the contents of the timestamp and that it varies depending on the hardware and software architecture and the machine load.

(17 Dec '15, 01:28) sindy

I found this thread looking for frame duration. I guess Midimistro is looking for 802.11 durations (at least I am). In 802.11 different frames have different bit rates and some frames change bit rate mid frame making calculating the duration cumbersome. Fortunately someone has written the code and epan/dissectors/packet-ieee80211-radio.c provides hf_wlan_radio_duration.

My question is: How do I access this information?

(07 May '16, 15:12) petri

I've converted your post from an Answer to the original Question (which it was not) to a comment to an existing Answer, but I believe it should have been a separate Question. Please consider converting it that way yourself.

The answer to such Question would be:

Read epan/dissectors/packet-ieee80211-radio.c a little bit past the initial declarations, which yields the following piece of code:

... {&hf_wlan_radio_duration, {"Duration", "wlan_radio.duration", FT_UINT32, BASE_DEC, NULL, 0, "Total duration of the frame in microseconds, including any preamble or plcp header. " "Calculated from the frame length, modulation and other phy data.", HFILL }}, ...

The second item there (wlan_radio.duration) could be called the full name of protocol field (the official name is probably different) which can be used in a display filter expression (like e.g. -Y wlan_radio.duration > 50) as well as displayed in tshark output using -T fields -e wlan_radio.duration.

A temporary remark for others interested: to date, the key to use this protocol field is to run the bleeding edge version of Wireshark which you have to compile yourself or download from the automated builds area, because this feature of the ieee80211_radio is not yet part of the stable release (2.0.3 as of writing this).

(08 May '16, 01:15) sindy

Thanks sindy!

Yes, it was my first post around here and I am not yet familiar with the manners. Thanks for helping me out.

Yes, I had read the code to check how the duration was calculated (correctly!). I just couldn't access the field in the app. Now I know the reason is I am running older code. I hadn't checked the version history to learn this was a recent addition (to my surprise).

(08 May '16, 07:48) petri
showing 5 of 6 show 1 more comments