wireshark round trip time analysis

How to do TCP Retransmission Analysis using Wireshark

January 2, 2024

Introduction to TCP Retransmission

TCP is one of the reliable protocols working in the transport layer, in terms of Open System Interconnect (OSI) model.  The protocol offers packet delivery guarantees, even if some of the packets have been lost during the transmission. The lost packets are recovered by retransmissions and acknowledgments while sequence numbers are used to determine correct packet reordering in the receiving side.

Whenever a sender transmits a packet, it saves a copy of the packet int its buffer and it stays there until receiving side acknowledges that it has received the packet. After that, the copy gets deleted and resources are released for future use.

Packet loss may happen due to two main reasons which can fall into many sub categories. Packet loss is mostly caused by hardware issues, software bugs, network congestion, and some other factors. Before diving into retransmissions and examining the types of retransmissions, we need to explain two concepts.

How to get TCP Round-Trip Time (RTT)?

For sake of simplicity, lets first go with pinging. I am using Windows OS and when I ping 1.1.1.1 address, it displays an output that shows me how much time it takes to send an ICMP packet from my computer to the server and gets back an answer from the server to my computer. The total time is called RTT for ping.

My ping command displays the RTT for each packet sent and returned below.

The similar concept can be applied to TCP as well. RTT is how long it takes to receive an ACK for data that has been sent. Wireshark is capable of calculating and displaying TCP RTT in the header.  Let’s get our hands dirty and capture a TCP flow. We will measure RTT for the first packet (SYN) in the flow.

• Go to the TCP header and expand [SEQ/ACK Analysis] tree.
• You should see something like below.

As you see in the screenshot above, after SYN/ACK packet arrived, the RTT for the SYN packet has calculated as 0.229751 second.

Analysing TCP Retransmission Timeout (RTO)

When a packet is sent over a network, the sender starts a timer and expects the packet to be acknowledged before the timer expire. If the packet gets lost or the sender does not receive the acknowledgment in the time, the timer expires and the sender retransmits the packet again. This timer is called RTO which is doubled after each retransmission. When RTO is calculated, RTT parameter is taken into account. The number of retransmissions depends on what type of operating system (OS) you use or what kind of configuration they have. I will create 3 scenarios in which we will observe RTOs and retransmissions.

In this scenario, we will use a Windows 10 client and try to reach 8.8.8.8 (dns.google) through port 125, which we know it is filtered by a firewall. All our packets will be dropped. The screenshot is below.

As you see, 4 times retransmission happened before it gave up. Each time RTO doubled in the “Delta” column. RTO timer can be customized in Windows 10.

We will repeat the same test with Kali. It has turned out that Kali is more stubborn compared to Windows 10 in terms of retransmissions. It tried 13 times before it gave up. You can see how RTO increased in the figure below.

In this scenario, we will create the topology below in which two Cisco routers are connected to each other. The client will try to telnet to the server but it will fail due to our configuration.

We will configure the server so that it will drop all the telnet traffic coming from the client. I prepared a configuration that did the filtering. The configuration is below from my Cisco router.

Now, it is time to telnetting to the server from the client while we are capturing the packets between two parties.

It appears that our filtering is working and we will verify that with packet capture as well. The pcaps are below.

The Cisco router does not seem to try much. It retransmitted only once and then gave it up. All 3 scenarios have proved that different OS uses different implementation for retransmission. This information can be used in OS fingerprinting.

Analysing TCP Retransmission

TCP Retransmission happens when RTO timer expires. For better understanding, we will continue with more scenarios.

In this scenario, we will imitate packet loss with filtering only http responses coming from a site and examine the captures. Filtering will be made in a node between the client and the server. The captures are below.

Since only http packets coming from the server has been dropped, TCP 3-way handshaking is looking successful. Then the client creates a http GET request and RTO timer starts for that packet (in the row 4).

The packet arrives the server and the server responses back. When the packet reaches our filtering node between the client and the server, the node immediately drops the packet. The client is still waiting for the packet. A soon as the RTO expires, the client retransmits the packet number 5 but still gets no response from the server. It keeps retransmitting the packet until it gives up in the packet number 22 by which it resets the connection.

The RTO increase can be seen in the “ Time ” column.

We will imitate a low bandwidth, creating an artificial congestion then we will try to download a nice wallpaper and observer what happens in the packet level. I will create a Quality of Service (QoS) rule on node between the client and server, which limits the bandwidth at rate of 8kbps (kilo bit per second). The size of wallpaper is 888KB (Kilo Byte).

Since TCP 3-way handshaking consumes very low bandwidth, the artificial congestion does not seem to affect the first 7 packets. After that you can see the latency in the packet number 8. The latency increases dramatically. Although there are pretty much latency, we do not see any RTO in the first 23 packets. The reason is high RTT. Remember that RTT is taken into consideration when calculating RTO. Then RTOs and retransmissions happen so much that the connection gets terminated later without completing the download.

It reminded me the time when we used dial up connection for the internet ?

What is Fast Retransmission

When a TCP sender receives three duplicate acknowledgements with the same acknowledge number, the sender concludes that the packet has been sent is lost and it retransmits the packet without waiting the RTO for the packet. This method is used to avoid congestion and detect lost packet in the network faster than normal TCP retransmit.

How to filter TCP Retransmissions with Wireshark

Wireshark provides a useful feature called “ Expert Info ”. When Wireshark see some anomalies, it adds some description to packet header, especially for TCP. It analyses TCP flags and inserts a relevant description to the header for informing experts (administrators).  We can create a filter and make a “ display filter button ” for it. Steps are below.

Go to display filter and type analysis.flags && !tcp.analysis.window_update . My output before filtering is below.

Now I am applying the filter below.

After applying the display filter, go to top right and click on the “ plus ” button.

Fill all the relevant areas and click “OK” to save.

Now you have a button that points to your filter. You should see something like below.

Final Thoughts

TCP retransmissions happen when there is packet loss or congestion, which causes high latency and low speed. TCP implements many methods to recover connections when packet loss occurs. Retransmission and Fast Retransmission are both used for this purpose.

Nurten Dogan

He is proficient in System Administration, Python, Computer Network, Network Engineering, PHP, Web Testing, Penetration Testing, Wireshark, RADIUS, Cisco Router, TCP/IP, Kali Linux, OSPF, NPS, and Multiprotocol BGP. You can connect with him on his LinkedIn Profile.

Can't find what you're searching for? Let us assist you.

Enter your query below, and we'll provide instant results tailored to your needs.

If my articles on GoLinuxCloud has helped you, kindly consider buying me a coffee as a token of appreciation.

For any other feedbacks or questions you can send mail to [email protected]

Thank You for your support!!

3 thoughts on “How to do TCP Retransmission Analysis using Wireshark”

Very useful information, thanks a lot…

Very Good. Thank you

Thank you, particularly for the Wireshark filters.

Leave a Comment Cancel reply

Save my name and email in this browser for the next time I comment.

Notify me via e-mail if anyone answers my comment.

We try to offer easy-to-follow guides and tips on various topics such as Linux, Cloud Computing, Programming Languages, Ethical Hacking and much more.

Recent Comments

Popular posts, 7 tools to detect memory leaks with examples, 100+ linux commands cheat sheet & examples, tutorial: beginners guide on linux memory management, top 15 tools to monitor disk io performance with examples, overview on different disk types and disk interface types, 6 ssh authentication methods to secure connection (sshd_config), how to check security updates list & perform linux patch management rhel 6/7/8, 8 ways to prevent brute force ssh attacks in linux (centos/rhel 7).

Privacy Policy

HTML Sitemap

Funding for our platform is provided by our readers, and we may earn a commission when you make a purchase through the links on our site.

How to Analyze Response Times in Wireshark for Latency & Slow Applications

By James Cox / Last Updated: April 13, 2023

Wireshark is an industry standard in the field of networking and troubleshooting, and its use is normally the first point at which network engineers start their journey when embarking on a troubleshooting mission, including analyzing Packet Loss and Network Latency .

Wireshark works incredibly well, and it is able to dump huge amounts of data into its capture files (.cap extension), giving your support team more than enough data to chew on as they conduct their investigations and fault finding.

Sometimes we don’t need to look at every single send and receive bit from a data transmission, and instead we need to zero in on specific protocols or other metrics without having to manually sift through all of this data.

Response Time Viewer for Wireshark is able to simplify much of the filtering process by applying a set of template searches against the pcap files that are generated by Wireshark.

This makes the process of looking through captured data files that much easier, as you do not need to understand what packets belong to which service, it is all done for you.

There are over 1200 filters that come standard with the application, which means that all you need to do is feed your capture file into SolarWinds Response Time Viewer for Wireshark and let it start parsing all of the data for you.

There is also a built in search function that makes in-depth analysis and searching for exact application types much easier, which can save hours of trawling through pcap dumps with a fine tooth comb.

The file can then be exported back into Wireshark so that it can be further analyzed if necessary, or compared to other data samples that you might have gathered during the course of your investigation.

It is an especially handy tool when you are trying to analyze and pinpoint the cause of performance issues and strange network behavior such as increased traffic or network faults.

The tool is completely free to download and use, and can be found here:

https://www.solarwinds.com/free-tools/response-time-viewer-for-wireshark/registration

Response Time Viewer for Wireshark FAQs

What are some best practices for using wireshark to analyze response times.

Some best practices for using Wireshark to analyze response times include using display filters to focus on specific network traffic, sorting packets by timestamp to view the timing of each packet, and correlating response times with other metrics like server load and application performance. It's also important to ensure that the captured traffic does not violate any privacy or security policies.

What types of response time measurements can be obtained in Wireshark?

Wireshark can be used to obtain a variety of response time measurements, including round-trip time (RTT), server processing time, network transfer time, and application processing time.

How do I calculate response times in Wireshark?

Response times in Wireshark can be calculated by subtracting the timestamp of the request packet from the timestamp of the corresponding response packet. Wireshark can also automatically calculate some response time metrics, such as RTT.

What are some common causes of slow response times?

Slow response times can be caused by a variety of factors, including network congestion, high latency, packet loss, and server or application performance issues.

How do I filter packets in Wireshark to analyze response times?

To filter packets in Wireshark to analyze response times, use the Response Time Viewer for Wireshark. Or, you can use the "tcp.analysis" filter to display only packets related to TCP communication, and then sort the packets by timestamp to view the timing of each packet.

James Cox is the Editor at ITT Systems and has a Long History in the IT and Network Engineering Field. He Boasts a long list of Credentials ranging from CompTIA Certifications up to Cisco and VMWare points on his Resume.

• Virtualization
• Privacy Policy
• Terms of Use

Determining TCP Initial Round Trip Time

• TCP Analysis , Wireshark
• 18 Comments

I was sitting in the back in Landis TCP Reassembly talk at Sharkfest 2014 (working on my slides for my next talk) when at the end one of the attendees approached me and asked me to explain determining TCP initial RTT to him again. I asked him for a piece of paper and a pen, and coached him through the process. This is what I did.

What is the Round Trip Time?

The round trip time is an important factor when determining application performance if there are many request/reply pairs being sent one after another, because each time the packets have to travel back and forth, adding delay until results are final. This applies mostly to database and remote desktop applications, but not that much for file transfers.

What is Initial RTT, and why bother?

Initial RTT is the round trip time that is determined by looking at the TCP Three Way Handshake. It is good to know the base latency of the connection, and the packets of the handshake are very small. This means that they have a good chance of getting through at maximum speed, because larger packets are often buffered somewhere before being passed on to the next hop. Another point is that the handshake packets are handled by the TCP stack of the operating system, so there is no application interference/delay at all. As  a bonus, each TCP session starts with these packets, so they’re easy to find (if the capture was started early enough to catch it, of course).

Knowing Initial RTT is necessary to calculate the optimum TCP window size of a connection, in case it is performing poorly due to bad window sizes. It is also important to know when analyzing packet loss and out of order packets, because it helps to determine if the sender could even have known about packet loss. Otherwise a packet marked as retransmission could just be an out of order arrival.

Determining Initial RTT

The problem with capture device placement

One of the rules of creating good captures is that you should never capture on the client or the server . But if the capture is taken somewhere between client and server we have a problem: how do we determine Initial RTT? Take a look at the next diagram and the solution should be obvious:

Instead of just looking at SYN to SYN/ACK or SYN/ACK to ACK we always look at all three TCP handshake packets. The capture device only sees that SYN after it has already traveled the distance from the client to the capture spot. Same for the ACK from the server, and the colored lines tells us that by looking at all three packets we have full RTT if we add the timings.

Frequently asked questions

Question: can I also look at Ping packets (ICMP Echo Request/Reply)? Answer: no, unless you captured on the client sending the ping. Take a look at the dual colored graph again – if the capture device is in the middle you’re not going to be able to determine the full RTT from partial request and reply timings.

Discussions — 18 Responses

Good article. I’ll have to point a few friends here for reference.

Just wanted to mention that I’ve seen intermediate devices like load balancers or proxies that immediately respond to the connection request throw people off. Make sure you know what’s in your path and always double/triple check the clients..

Thanks, Ty. I agree, you have to know what’s in the path between client and server. Devices sitting in the middle accepting the client connection and open another connection towards the server will lead to partial results, so you have to be aware of them. Good point. They’re usually simple to spot though – if you have an outgoing connection where you know that the packets are leaving your LAN and you get Initial RTT of less than a millisecond it’s a strong hint for a proxy (or similar device).

I really liked your article. I have one question:

Lets say we have the below deployment:

Client ——> LoadBalancer ——> Proxy ——–> Internet/Server

In case we “terminate” the TCP connection on the Proxy and we establish a new TCP connection from the Proxy to the Server. Should we measure 2 RTTs one for each connection and the aggregation of them is the final RTT ? What should we measure in order to determine the speed in such deployments ?

Regards, Andreas

Proxies can be difficult, because there is often only one connection per client but many outgoing connections to various servers. It usually complicates analysis of performance issues because you have to find and match requests first.

Luckily, for TCP analysis you only need to care about the RTT of each connection, because packet loss and delays are only relevant to those.

Of course, if you’re interested in the total RTT you can can add the 2 partial RTTs to see where the time is spent.

Thanks a lot for your response 🙂

good article

Thanks for mentioning REF, which is great of heltp

so where we need to capture the tcp packet actually to know the RTT? for ex if its like :

server—-newyork—-chicago—-california—–washington—-server and if i need to know the RTT between server in newyork to washington Please let me know

You can capture anywhere between the two servers and read the RTT between them from SYN to ACK. By reading the time between the first and third handshake packet it doesn’t matter where you capture, which is the beauty of it. But keep in mind that the TCP connection needs to be end-to-end, so if anything is proxying the connection you have to capture at least twice, on each side of the proxying device.

How can find packet travelling time from client to server are on different system.

To determine the round trip time you always need packets that are exchanged between the two systems. So if I understand your question correctly and you don’t have access to packets of a communication between the client and the server you can’t determine iRTT.

Can u please tell how to solve these type of problems 2. If originally RTTs = 14 ms and a is set to 0.2, calculate the new RTT s after the following events (times are relative to event 1): 1. Event 1: 00 ms Segment 1 was sent. 2. Event 2: 06 ms Segment 2 was sent. 3. Event 3: 16 ms Segment 1 was timed-out and resent. 4. Event 4: 21 ms Segment 1 was acknowledged. 5. Event 5: 23 ms Segment 2 was acknowledged

I’m sorry, but I’m not exactly sure what this is supposed to be. What is it good for, and what is this a set to 0.2? The only thing that may make sense is measuring the time it took to ACK each segment (1 -> 21ms if measuring the time from the original segment, 5 otherwise, 2 -> 17ms), but I have no idea what to use “a” for 🙂

how to calculate RTT using NS-2(network simulator-2)?

I haven’t played with NS-2 yet, but if you can capture packets it should be the same procedure.

ok..thank you sir

Hi, Subject: iRTT Field Missing in Wireshark Capture

We have two Ethernet boards, one board perfectly accomplishes an FTP file transfer the second does not and it eventually times out early on, mishandling the SYN SYN:ACK phase. We analyzed the two Wireshark captures and noticed that the good capture has the iRTT time stamp field included in the dump while the bad one does not. What is the significance of not seeing that iRTT in the bad capture? Is that indicative to why it fails the xfer?

The iRTT field can only be present if the TCP handshake was complete, meaning you all three packets in the capture (SYN, SYN/ACK, ACK). If one is missing the iRTT can’t be calculated correctly, and the field won’t be present. So if the field is missing it means that the TCP connection wasn’t established, which also means that no data transfer was possible.

Cancel reply

CAPTCHA Code *

• Jasper’s Colorfilters
• Sharkfest 2017 Hands-On Files
• Sharkfest 2019 EU Packet Challenge
• Sharkfest 2019 US Packet Challenge
• The Network Packet Capture Playbook

Recent Comments

• SV on Analyzing a failed TLS connection
• Jasper on Wireshark Column Setup Deepdive
• Jasper on Wireless Capture on Windows
• Ram on Wireshark Column Setup Deepdive
• PacketSnooper on Wireless Capture on Windows

Recent Posts

• DDoS Tracefile for SharkFest Europe 2021
• Introducing DNS Hammer, Part 2: Auditing a Name Server’s Rate Limiting Configuration
• Introducing DNS Hammer, Part 1: DDoS Analysis – From DNS Reflection to Rate Limiting
• Analyzing a failed TLS connection
• Patch! Patch! Patch!
• Entries feed
• Comments feed
• WordPress.org

Rechtliches

• Erklärung zur Informationspflicht (Datenschutzerklärung)
• Impressum und ViSdP

Mastering Wireshark by Charit Mishra

Get full access to Mastering Wireshark and 60K+ other titles, with a free 10-day trial of O'Reilly.

There are also live events, courses curated by job role, and more.

TCP stream graphs

There are a couple of graphs that come in this section. Each of them depicts the network traffic in a graphical form differently. Let's start by taking a look at each one of them.

Round-trip time graphs

Round-trip time ( RTT ) is the duration in which the ACK for a packet that is sent is received, that is, for every packet sent from a host, there is an ACK received (TCP communication), which determines the successful delivery of the packet. The total time that is consumed from the transfer of the packet to the ACK for the same is called round trip time. Follow these steps to create one for yourself:

• Select any TCP packet in your packet list pane.
• Navigate to Statistics | TCP Stream Graph | Round Trip Time Graph .
• The x axis represents ...

Get Mastering Wireshark now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Don’t leave empty-handed

Get Mark Richards’s Software Architecture Patterns ebook to better understand how to design components—and how they should interact.

It’s yours, free.

Check it out now on O’Reilly

Dive in for free with a 10-day trial of the O’Reilly learning platform—then explore all the other resources our members count on to build skills and solve problems every day.

Daniel Schwartz

Site Reliability Engineer

5 Useful Tips For Analyzing Wireshark Packet Captures

Are you new to wireshark packet captures.

I was there – I’ve received my first packet captures and was asked to analyze it. Trust me! To have this skill – being able to tell where the problem is by reading a packet capture is a plus for you. Now and in the future! After some time you get a feeling about first steps to do with Wireshark and how to give a first feedback.

1. Use a custom Wireshark Profile

When I was new to Wireshark and never analyzed packet captures before, i was lost. I remember the time because packet analysis became an important role as “Site Reliability Engineer”.  And I wasn’t ready.

Wireshark opens your file with the “Default” profile which has the basic columns Packet Number, Time, Source, Destination, Protocol, Length, Info. Over the time I understood that having more columns available from the beginning it will save time and helps also in troubleshooting.

As you can see in the screenshot, I’ve added several columns. Some of them are very important:

• Delta Time => It shows the delta time to the previous captured packet
• Bytes in Flight => Data which has been sent but not yet acknowledged
• Sequence Number
• Acknowledged Number
• Next Sequence Number

Adding those columns helped me to save time in analyzing!

2. Get first Information from the 3-Way-Handshake

The 3-Way-Handshake is the most important step in TCP to establish a communication between client and server. Here a short recap of how the handshake looks like:

• The Client sends a SYN packet with its Initial Sequence Number to the Server
• The Server acknowledge (ACK) the SYN packet (from the Client) and send its own SYN packet with its Initial Sequence Number
• The Client acknowledge (ACK) the SYN packet (from the Server)
• Now the TCP communication is established and able to exchange data

During the 3-Way-Handshake there is a lot of useful information exchanged between Client and Server. Beside of Source IP, Destination IP, Source Port, Destination Port, Source MAC, Destination MAC you can also get:

• RTT = > Round Trip Time between Client and Server
• TTL => Time to live  – With that value you can calculate the number of hops between Client and Server
• Calculated Window Size => The size of data which can be received before it needs to get acknowledged

With just 3 packets you can get an overview about your TCP communication. Filter your packet captures to your destination address (for needed filters use my Introduction to Wireshark – Part 2 ) and start analyzing.

Starting from now I use as an example a TCP communication between my client in my private network and the tcpdump-it.com server (173.212.216.192).

3. Check how many packets have been lost

Since I am working on the infrastructure side my first goal is to understand if the network is behaving as it should be. When I am asked to analyze a network packet capture, it is a mandatory step to understand the percentage of packet loss (TCP Retransmissions).

To do that I am using the display filter “ip.addr==173.212.216.192 and tcp.analysis.retransmission”. It shows all the packets which were retransmitted. The next step is to open the “Capture File Properties” under the “Statistic” tab.

Under the Statistics section you can see the columns “Captured” and “Displayed”. The “Displayed” column is based on your display filter and shows the statistics compared to the “Captured” data.

I used this example to show you an extreme case. You can see there are 10,4% packets retransmitted.

It depends on many factors how many percent of packet loss is critical. There are different opinions. Probably no answer is correct, but when the packet loss is higher than 1% and is causing a high delay in the communication you should start checking better.

4. Open the Expert Information

Wiresharks Expert Information is very useful and give you some idea of what to check in the packet capture. In the Wireshark documentation you find following statement “Take expert infos as a hint what’s worth looking at, but not more”

This is exactly what you should do. When I first analyzed a packet capture, the Expert Information was very helpful and gave me hints in which direction to analyze.

Go to the “Expert” tab and select “Expert Information”. A new window will open:

In previous versions of Wireshark (v1) the overview about the “Warnings”, “Notes”, “Chats” were more clearer.

Get used to open the Expert Information. It will absolutely help you!

5. Open the Round Trip Time Graph

A short recap about what Round Trip Time means: RTT means the time between a packet is send and an answer comes back.

For our packet captures analysis it is important to understand if there are packets with a high RTT. That would mean that we suffer from a slow communication.

To open the Round Trip Time Graph go to “Statistics” >> “TCP Stream Graphs” >> “Round Trip Time” .

The graph shows on the Y-axis the RTT in ms while the X-axis show the time the packet capture was running in seconds.

This RTT graph in my screenshot is not significant but looks fine with a RTT of about 60 ms. Look for spikes in the Y-axis to identify slow packets!

I want to repeat my sentence I wrote at the beginning of the post: To have this skill – being able to tell where the problem is by reading a packet capture is a plus for you.

If you consider some parts of this post, you will be more successful in analyzing packet captures with Wireshark!

If you want to know more about it, join my Slack Workspace  or send me an email.

4 thoughts on “ 5 Useful Tips For Analyzing Wireshark Packet Captures ”

• Pingback: 2 Ways For Finding IP Top Talker » tcpdump-it.com

nice very good news ,thanks

I have been searching for months for a “beginners language” in analyzing wireshark packets! Thank you so much for taking the time to explain everything and what the process should look like using common English…lol. I am not a professional, just a curious beginner that is learning on her own so I really do appreciate the breakdown..Take care

Thank you for taking the time to provide some insight on this. every little bit helps newbies like myself!

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

Subscribe to my newsletter

Learn Wireshark – Computer Networking Tutorial

In this post, you will learn about the single most important and useful tool in Computer Networks – Wireshark.

This post relies on basic knowledge of computer networks. Be sure to check my previous post about the five layers model if you need a refresher.

What is Wireshark?

Wireshark is a sniffer, as well as a packet analyzer.

What does that mean?

You can think of a sniffer as a measuring device. We use it to examine what’s going on inside a network cable, or in the air if we are dealing with a wireless network. A sniffer shows us the data that passes through our network card.

But Wireshark does more than that. A sniffer could just display a stream of bits - ones and zeroes, that the network card sees. Wireshark is also a packer analyzer that displays lots of meaningful data about the frames that it sees.

Wireshark is an open-source and free tool, and is widely used to analyze network traffic.

Wireshark can be helpful in many cases. It might be helpful for debugging problems in your network, for instance – if you can’t connect from one computer to another, and want to understand what’s going on.

It can also help programmers. For example, imagine that you were implementing a chat program between two clients, and something was not working. In order to understand what exactly is being sent, you may use Wireshark to see the data transmitted over the wire.

So, let’s get to know Wireshark.

How to Download and Install Wireshark

Start by downloading Wireshark from its official website:

https://www.wireshark.org/#download

Follow the instructions on the installer and you should be good to go.

How to Sniff Traffic with Wireshark

Launch Wireshark, and start by sniffing some data. For that, you can hit Ctrl+K (PC) or Cmd+K (Mac)  to get the Capture Options window. Notice that you can reach this window in other ways. You can go to Capture->Options . Alternatively, you can click the Capture Options icon.

I encourage you to use keyboard shortcuts and get comfortable with them right from the start, as they'll allow you to save time and work more efficiently.

So, again, I’ve used Ctrl+K (or Cmd+K ) and got this screen:

Here we can see a list of interfaces, and I happen to have quite a few. Which one is relevant? If you’re not sure at this point, you can look at the Traffic column, and see which interfaces currently have traffic.

Here we can see that Wi-Fi 3 has got traffic going through it, as the line is high. Select the relevant network interface, and then hit Enter , or click the button Start .

Let Wireshark sniff the network for a bit, and then stop the sniff using Ctrl+E / Cmd+E . Again, this can be achieved in other ways – such as going to Capture->Stop or clicking the Stop icon.

Consider the different sections:

The section marked in red includes Wireshark’s menu, with all kinds of interesting options.

The main toolbar is marked in blue, providing quick access to some items from the menu.

Next, marked in green, is the display filter . We will get back to it shortly, as this is one of the most important features of Wireshark.

Then follows:

The Packet List Pane

The packet list pane is marked in orange. It displays a short summary of each packet captured.

(Note: the term Frame belongs to a sequence of bytes in the Data Link layer , while a Packet is a sequence of bytes from the Network layer . In this post I will use the terms interchangeably, though to be accurate, every packet is a frame, but not every frame is a packet, as there are frames that don't hold network layer data.)

As you can see in the image above, we have a few columns here:

NUMBER (No.) – The number of the packet in the capture file. This number won’t change, even if we use filters. This is just a sequential number – the first frame that you have sniffed gets the number 1, the second frame gets the number 2, and so on.

Time – The timestamp of the packet. It shows how much time has passed from the very first packet we have sniffed until we sniffed the packet in question. Therefore, the time for packet number 1 is always 0.

Source – The address where this packet is coming from. Don’t worry if you don’t understand the format of the addresses just yet, we will cover different addresses in future tutorials.

Destination – The address where this packet is going.

Protocol – The protocol name in a short version. This will be the top protocol – that is, the protocol of the highest layer.

Length – The length of each packet, in bytes.

Info – Additional information about the packet content. This changes according to the protocol.

By clicking on packets in this pane, you control what is displayed in the other two panes which I will now describe.

The Packet Details Pane

Click on one of the captured packets. In the example below I clicked on packet number 147:

Now, the packet details pane displays the packet selected in the packet list pane in more detail. You can see the layers here.

In the example above, we have Ethernet II as the second layer, IPv4 as the third layer, UDP as the fourth layer, and some data as a payload.

When we click on a specific layer, we actually see the header of that layer.

Notice that we don’t see the first layer on its own. As a reminder, the first layer is responsible for transmitting a single bit – 0 or 1 – over the network (if you need a refresher about the different layers, check out this post ).

Below the packet details pane, we have the packet bytes pane . It displays the data from the packet selected in the packet list pane. This is the actual data being sent over the wire. We can see the data in hexadecimal base, as well as ASCII form.

How to Use the Display Filter

Wireshark has many different functions, and today we will focus on one thing – the display filter.

As you can see, once you start sniffing data, you get a LOT of traffic. But you definitely don’t want to look at everything.

Recall the example from before – using Wireshark in order to debug a chat program that you’ve implemented. In that case, you would like to see the traffic related to the chat program only.

Let’s say I want to filter only messages sent by the source address of frame number 149 ( 192.168.1.3 ). I will cover IP addresses in future posts, but for now you can see that it consists four numbers, delimited by a dot:

Now, even if you don’t know how to filter only packets sent from this IP address, you can use Wireshark to show you how it’s done.

For that, go to the right field we would like to filter – in this case, the source IP address. Then right click -> and choose filter -> Apply as Filter .

After applying the filter, you only see packets that have been sent from this address. Also, you can look at the display filter line and see the command used. In this way, you can learn about the display filter syntax (in this example, it is ip.src for the IP source address field):

Now, try to filter only packets that have been sent from this address, and to the address 172.217.16.142 (as in Frame 130 in the image above). How would you do that?

Well, you could go to the relevant field – in this case, the IP destination address. Now, right click -> Apply as Filter -> and select ...and Selected :

If you look at the display filter line after applying this filter:

You can also learn that you can use the && operand in order to perform and . You could also write the word and , instead, and get the same result.

How to Use Wireshark to Research the Ping Utility

Ping is a useful utility to check for remote servers’ connectivity.

This page explains how to use ping in Windows, and this page explains how to do that in OSX.

Now, we can try to ping <address> using the command line. By default, ping sends 4 requests and waits for a pong answer. If we want it to send a single request, we could use -n 1 :

You can see that Google has responded. The time it took for the message to return was 92 milliseconds. We will learn about the meaning of TTL in future posts.

Ping is useful to determine whether a remote service is available, and how fast it is to reach that service. If it takes a very long time to reach a reliable server such as google.com, we might have a connectivity problem.

Try it yourself

Now, try to use Wireshark to answer the following questions:

1) What protocol does the ping utility use?

2) Using only Wireshark, compute the RTT (Round Trip Time) – how long it took since your ping request was sent and until the ping reply was received?

Next, run the following command:

ping -n 1 -l 342 www.google.com

3) What is the main difference between the packet sent by this command, and the packet sent by the previous command? Where in Wireshark can you see this difference, inspecting the packets? 4) What is the content (data) provided in the ping request packet? What is the content provided in the ping response packet?

Let's solve it together

So the first question is:

What protocol does the ping utility use?

To answer that question, start sniffing in Wireshark, and simply run the ping command. Stop the sniff, and consider the packets pane:

Wireshark marks the packets as Echo (ping) request and Echo (ping) reply .

Considering these packets, we can see they consist of Ethernet for the Data Link layer (though that may differ from one network to another), IPv4 as the Network layer, and then ICMP as the protocol for Ping itself. So the answer we found is: ICMP .

Next question:

Using only Wireshark, compute the Round Trip Time

Looking at the captured packets, we can see the Time column, and subtract the time of the Pong packet ( 7.888... ) from the time of the Ping packet ( 7.796... ).

So in this case the RTT was: 92 ms . Of course, the value can be different when you run the ping utility.

What is the main difference between the packet sent by this command, and the packet sent by the previous command?

For question number 3, we are asked to run the following command:

Looking at the first run of ping , we can see the length of the packets are 74 bytes:

Observing the packets sent after running ping with the -l 342 argument, we can see that the value is bigger:

So the main difference is the amount of bytes sent as the data.

Question number four:

What is the content (data) provided in the ping request packet?

What is the content provided in the ping response packet.

Click on the request packet to observe the data sent:

The answer for the ping request is a through w , over and over again.

Regarding the ping response – it is the same as the request.

Wireshark is a wonderful tool for anyone working with Computer Networks. It can help you understand how protocols work and also help you debug applications or network issues.

As you have seen, you can learn how things work by simply running Wireshark in the background while using them and then inspect the traffic. With this tool under your belt, the sky is the limit.

In future tutorials, we will also rely on our knowledge of Wireshark and use it to further understand various concepts in computer networks.

About the Author

Omer Rosenbaum is Swimm ’s Chief Technology Officer. He's the author of the Brief YouTube Channel . He's also a cyber training expert and founder of Checkpoint Security Academy. He's the author of Computer Networks (in Hebrew) . You can find him on Twitter .

Additional References

• Computer Networks Playlist - on my Brief channel .
• Wireshark's website .

Read more posts .

If you read this far, thank the author to show them you care. Say Thanks

Learn to code for free. freeCodeCamp's open source curriculum has helped more than 40,000 people get jobs as developers. Get started

Bug Summary

Annotated source code.

Press '?' to see keyboard shortcuts

Keyboard shortcuts:

• Use 'j/k' keys for keyboard navigation
• Use 'Shift+S' to show/hide relevant lines
• Use '?' to toggle this window

• Share full article

Advertisement

Supported by

Senate Approves Bill to Reauthorize F.A.A. and Improve Air Travel

The Senate also passed a short-term extension of the current F.A.A. law to give the House time to clear the longer-term package early next week.

By Kayla Guo

Reporting from the Capitol

The Senate on Thursday passed legislation to reauthorize federal aviation programs for the next five years and put in place new safety measures and consumer protections for passengers, at a moment of intense uncertainty and disruption in the air travel system.

The bill , which still must win final approval in the House before becoming law, would provide more than $105 billion to the Federal Aviation Administration and another $738 million to the National Transportation Safety Board for airport modernization, technology programs and safety. It would also bolster the hiring and training of air traffic controllers, codify airlines’ refund obligations to passengers, ensure fee-free family seating and strengthen protections for passengers with disabilities.

“Aviation safety has been front of mind for millions of Americans recently, and this F.A.A. bill is the best thing Congress can do to give Americans the peace of mind they deserve,” Senator Chuck Schumer of New York, the majority leader, said on the Senate floor on Thursday evening.

It passed in an overwhelming bipartisan vote of 88 to 4, just one day before the current law is scheduled to lapse. The Senate also unanimously approved a short-term extension to allow time for the House to take up and clear the longer-term package next week, a step that would send it to President Biden.

The legislation is a bipartisan compromise negotiated over months by the Senate and House committees with jurisdiction over the F.A.A., after Congress authorized several short-term extensions of the agency when lawmakers failed to meet earlier deadlines. The House passed its version of the bill almost a year ago in a lopsided vote of 351 to 69.

Senator Maria Cantwell of Washington, chairwoman of the Commerce Committee, celebrated the bill’s provisions on consumer protections, aviation safety, air traffic controllers, airport infrastructure and work force development on the floor after passage.

“This is a big moment for aviation,” Ms. Cantwell said. “We have had safety issues and concerns that we need to make a big investment. This legislation is that investment — in safety standards, in protecting consumers and advancing a work force and technology that will allow the United States to be the gold standard in aviation.”

Senator Ted Cruz of Texas, the top Republican on the Commerce Committee, said: “This legislation is a strong, bipartisan, bicameral bill that includes hundreds of priorities for senators and representatives, both Republican and Democrat. This bill gives the FAA the safety tools it needs at a critical time.”

As one of the few remaining bills considered a must-pass item this year, the F.A.A. package, which prompted several regional disputes, became a magnet for dozens of amendments and policy riders that threatened to delay it in the Senate.

With the legislation threatening to stall, the House on Wednesday approved a one-week extension for the F.A.A. before leaving Washington for the weekend. The Senate followed suit on Thursday, steering around lingering disputes that had threatened to scuttle the effort and cause a brief lapse for the F.A.A.

The debate came at a time of acute uncertainty about the aviation system, which has had a recent spate of concerning episodes such as dangerous near collisions on runways, plane malfunctions and thousands of flight delays and cancellations.

It was unclear for much of Thursday whether the Senate would be able to push through the legislation and the extension, as senators demanded votes on amendments or threatened to block speedy passage. No amendments were ultimately brought to a vote.

The most intense regional fight was over a provision in the bill that would add five round-trip long-haul flights out of Ronald Reagan National Airport outside Washington. Proponents, which include Delta Air Lines, have said they want to expand access to the nation’s capital and increase competition.

The proposal incensed lawmakers representing the area , who argued that the airport maintains the busiest runway in the country and cannot support additional flights. Senators Tim Kaine and Mark Warner of Virginia and Benjamin L. Cardin and Chris Van Hollen of Maryland, all Democrats, filed an amendment to strike the new flights.

Mr. Kaine and Mr. Warner threatened to hold the bill up if they did not receive a vote. But Mr. Cruz blocked an effort to bring up a compromise amendment that would have given the transportation secretary the final say on new flights after considering any effects they would have on delays and passenger safety.

“The Senate abdicated its responsibility to protect the safety of the 25 million people who fly through D.C.A. every year,” Mr. Kaine and Mr. Warner said in a statement. “Some of our colleagues were too afraid to let the experts make the call. They didn’t want to show the American people that they care more about a few lawmakers’ desire for direct flights than they care about the safety and convenience of the traveling public. That is shameful and an embarrassment.”

The senators from Virginia and Maryland were the only votes against the bill.

Another group of senators failed to secure a vote on a proposal to halt the Transportation Security Administration’s expansion of facial recognition technology at airports and restrict it where it is in use.

Senators had also proposed adding a number of unrelated bills, including one that would compensate people harmed by exposure to the nation’s nuclear weapons program , legislation to fully fund the replacement of the collapsed Francis Scott Key Bridge in Baltimore, and a credit card competition measure. Senators Marsha Blackburn, Republican of Tennessee, and Richard Blumenthal, Democrat of Connecticut, were pushing for a vote on their bill to protect minors online into Thursday. None of them made it into the final product.

An earlier version of this article misstated the name of the bridge in Baltimore that collapsed. It is the Francis Scott Key Bridge, not the Francis Key Scott Bridge.

How we handle corrections

Kayla Guo covers Congress for The New York Times as the 2023-24 reporting fellow based in Washington. More about Kayla Guo

Our Coverage of Congress

Here’s the latest news and analysis from capitol hill..

Democrats’ ‘Sword and Shield’ Strategy: Despite certain defeat, Senator Chuck Schumer, the majority leader, is pushing showdown votes on border security  and abortion rights  ahead of this year’s elections. Here’s why .

Trump’s Meeting With Oil Executives: Senate Democrats opened an investigation  into a fund-raising dinner where Donald Trump asked oil executives to donate $1 billion to his campaign and vowed to roll back climate rules .

Noncitizen Voting:  House Republicans are pushing legislation to crack down on voting by noncitizens , which happens rarely and is already illegal in federal elections, in an effort to sow doubts about the 2024 results if Trump loses .

A New Centrism Rises: The emergence of a new form of American centrism — call it neopopulism  — has made the last four years arguably the most productive period of bipartisanship in Washington in decades.

Hurling Insults: In an after-hours session of the House Oversight Committee, insults by Representative Marjorie Taylor Greene, a right-wing Republican, led to a raucous exchange with Democrats .

RTT Graph showing values higher than tcp.analysis.ack_rtt

One Answer: