0

I am trying to use Wireshark to determine the amount of time it takes to send a message from one device and receive it from another device.

I have Wireshark running for both, and I start Wireshark capture and then send a message through an Application (that talks with a server). But I get so many TCP packets that I don't know what is relevant to me actually sending the message because I still get packets sometimes even when I haven't sent a message yet. I can't find the message I sent either because it is all encrypted and so it's hard to pinpoint which packet is the one with the message being sent.

Any advice?

Lia
  • 1
  • TCP is not a message-based protocol; it is a streaming protocol. UDP is your message-based protocol. – Ron Maupin Aug 08 '23 at 16:11
  • If I'm not getting any UDP packets, does that mean I am not seeing a message being sent in Wireshark? – Lia Aug 08 '23 at 16:13

1 Answers1

0

You either need to apply a capture filter or a Wireshark display filter or both in order to narrow down the traffic to the TCP conversation of interest.

For example, a capture filter might be something like: ip and tcp and host 1.2.3.4 and host 4.3.2.1 and tcp port 443, assuming hosts 1.2.3.4 and 4.3.2.1 are the two devices communicating with each other, and port 443 is the presumed port at least one of them is using for communication. Since you mentioned that the traffic was encrypted, then for this example I just made the assumption that it's HTTPS traffic and 443 is the default port for that traffic.

In Wireshark though, you'd use a display filter to narrow down the packets, so something like: ip.addr eq 1.2.3.4 and ip.addr eq 4.3.2.1 and tcp.port eq 443, or more simply just find any packet part of the conversation and just right-click on the packet in the Wireshark packet list pane and then choose, Conversation Filter -> TCP or Follow -> TCP Stream.

Once you have the conversation narrowed down, then you can just look at the delta time between a request packet and a response packet. If you don't already have a delta time column, you can add it via Edit -> Preferences -> Columns -> [+] -> Type: Delta time displayed, Title: DeltaTime, or you can look at the "Time since previous frame in this TCP stream" value by expanding the TCP protocol in the Packet Details pane and then expanding the [Timestamps] information. You can also right-click on that field (tcp.time_delta) and choose Apply as Column if you want to see them all more easily.

Christopher Maynard
  • 5,702
  • 2
  • 17
  • 23
  • Thank you so so much, this is helpful. The traffic I get is mostly already TCP with the ip addresses I need. I think I'm confused how to identify which is a request and a response packet? I still get random TCP requests here and there when I'm not sending a message. – Lia Aug 08 '23 at 22:50
  • And also, would I do this on the receiver or the transmitter's end? How can I take both into consideration? – Lia Aug 08 '23 at 23:01
  • Those *random* TCP requests could just be TCP keepalives. If you're trying to measure round-trip times, then you only need to capture on the client side, i.e., the side sending the request and then measure the time between the request and the response. Note that that will include both the round-trip latency as well as the server processing time, so if you want to eliminate the server processing time, then you would have to simultaneously capture at the server and subtract the time between when the server sees the request and when it sends the response from the client's round-trip time. – Christopher Maynard Aug 09 '23 at 15:49