Filtering Packet Duration in Tshark.

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.

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.

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.

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?

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