TRANSUM is a Wireshark plugin that calculates response time information and delivers it through an additional branch in the dissector tree displayed in the Packet Detail pane.

User Guide

A TRANSUM User Guide can be found here.

Development Notes

The objective of the notes added here is to help developers maintain the code.

Request-Response Pair Detection

The simplest form of detection is referred to in TRANSUM as Generic TCP and Generic UDP. In these cases, TRANSUM just looks for turns i.e. if the last data packet on a stream (TCP or UDP) was going from service-to-client, and the current packet is going client-to-service, TRANSUM assumes a turn. A turn marks the start of a new RR Pair. When we refer to a data packet we mean a TCP or UDP payload of greater than zero bytes.

For example, imagine the following:

  1. c2s - Packet with 1460 bytes payload
  2. c2s - Packet with 248 bytes payload
  3. s2c - Packet with 1460 bytes payload
  4. s2c - Packet with 1460 bytes payload
  5. s2c - Packet with 1460 bytes payload
  6. s2c - Packet with 960 bytes payload
  7. c2s - Packet with 248 bytes payload
  8. s2c - Packet with 1280 bytes payload

In this case:

This pattern works for many protocols, in particular where a TCP connect supports a single application session. However, some protocols multiplex multiple application sessions onto a single TCP connection; SMB2 and DCE-RPC are two such protocols. In these cases, TRANSUM takes into account session ID and message ID information. Both these protocols can also overlap requests and responses, and so you see patterns like this:

Another protocol that produces similar patterns is DNS, and for this protocol TRANSUM uses the DNS Transaction ID as the message ID.


Wireshark scans the packets in a PCAP / PCAP-NG file at least twice. During the first scan, TRANSUM extracts information from the packets to build a chained list of Request-Response Pairs. These pairs are added to a list called the rrpd_list (request response descriptor list). The list is in the chronological order of the APDU Request.

The list is searched in reverse order. The performance of TRANSUM is strongly linked to the number of rrpd_list entries searched, and so there are some measures in the function find_latest_rrpd(...) that attempt to minimize the searching. The basic strategy is to stop searching and return from this function as quickly as possible.

TRANSUM (last edited 2017-11-15 18:24:27 by PaulOfford)