Ever have the need to track down application latencies from multiple PCAPs? This is something that you can glean from the time stamps, but it is tedious. If you want to go a step further and find out service time latency, it’s an even more mind-numbing and time-consuming task.

This is where a handy tool like Transum comes in. Up until recently, it has been a standalone tool but with the latest versions of WireShark, it is included. I’ll briefly show how to enable and use the tool within WireShark in this paper.

Requirements:

Transum – what does it do?

Transum works with many protocols including: IPv4, IPv6, TCP, and UDP. It provides response time breakdown for HTTP, HTTPS, SMB2, Microsoft SQL, Oracle SQL, .NET Remoting, SOAP, DCE-RPC, Kerberos, FTP, Telnet, and DNS to name a few.

There are four response time statistics provided by Transum:

• APDU response time: the total time the user must wait for a completion of a request
• Service time: the time it takes for the service to process the request (i.e. the time between the last request packet and the first response packet). This indicates server latency or non-network related latencies.
• Request spread: the time needed to transmit the whole request from the client to the service
• Response spread: the time transmit the whole response from the service to the client

In order to get useful data for all of these response times, it may be necessary to gather packet captures from multiple points in the network and merge them into a single file. WireShark makes this task easy with a drop down menu option.

This graphic shows the different response times possible with Transum:

Here is a sample of what is included in the details of a single packet. The APDU (total time from the user’s perspective) in this case was 352 milliseconds. The bulk of that time was due to the service responding back to the client (211 ms).

Enabling Transum

Enable the Transum plug-in first by going to Preferences / Protocols. Look for Transum. And enable the options as shown in the graphic:

Depending on the direction of the capture, you can change the “Capture position” as needed. Note that you can add other TCP and UDP service ports. In this example, I added port 53 to both TCP and UDP as this was the main protocol I was interested in examining.

Next go to Analyze / Enabled Protocols and find Transum to enable the protocol.

You will now see the Transum data within the packet capture.

Using Transum on packet captures

To make the response times easier to read, you can add them as columns to your capture.

Right click on the data you wish to add as a column and apply.

All of the response time data is now easily visible and sortable. Since I am only showing DNS here, the request and response spreads are zero.

Notice in packets 435, 1084, and 3059, there were missing DNS packets. In this case, it was missing DNS responses.

Here, in packets 512 – 531, the APDU (entire session response time) is around 230ms. This can add consideral delay to applications when DNS takes this long to resolve.

Transum is nice plug-in addition to WireShark for dynamically calculating various response time latencies within sessions. By adding the Transum response time columns within WireShark, you can quickly pinpoint areas where excessive latencies occur.