Network Troubleshooting with Wireshark

# CHAPTER 13

Network Troubleshooting with Wireshark #

1. Introduction #

When a user submits an IT ticket stating, "The application is slow," network engineers groan. "Slow" is an abstract, subjective complaint. Is the local Wi-Fi dropping packets? Is the ISP congested? Or is the database server simply taking 5 seconds to generate the webpage? Wireshark removes the guesswork, transforming abstract complaints into mathematical certainty. In this chapter, we will shift from observation to diagnosis. We will learn how to spot the visual indicators of network failure, focusing heavily on TCP Retransmissions, connection refusals (RST flags), and the critical delta time between packets to definitively prove *where* the delay is occurring.

2. Learning Objectives #

By the end of this chapter, you will be able to:

• Identify and interpret TCP Retransmissions and Duplicate ACKs.

• Diagnose packet loss and network congestion using Wireshark's color-coding.

• Differentiate between a Network Delay and an Application/Server Delay.

• Analyze connection failures utilizing TCP RST (Reset) packets.

• Utilize the "Delta Time" column to pinpoint latency bottlenecks.

3. Diagnosing Packet Loss (TCP Retransmissions) #

If a router in the middle of the internet is overwhelmed, it simply drops packets into the trash. Thanks to TCP (Chapter 7), your computer will notice the packet didn't arrive and will send it again. Wireshark makes this highly visible: Wireshark highlights these errors with a Black background and Red text. Look for the label [TCP Retransmission].

• *Normal:* Seeing one or two retransmissions in a massive file download is standard internet weather.

• *Failure:* If you see a wall of Black and Red [TCP Retransmission] and [TCP Dup ACK] packets, your local Wi-Fi is failing, or an ISP link is experiencing severe packet loss. The network is fundamentally broken.

4. Diagnosing Connection Failures (The RST Flag) #

User says: "I can't reach the server." You filter Wireshark: ip.addr == [Server_IP]. You see the Client send a [SYN] packet. Instantly, the Server replies with a [RST, ACK] (Reset) packet.

What does this mean? The network is perfectly healthy! The SYN packet successfully traveled through all the routers and reached the server. But the server actively rejected it. Why?

1. 1. The web application service (like Apache/Nginx) has crashed and is not listening on Port 80.

1. 2. A strict Host-based Firewall on the server blocked your specific IP address.

5. Network Delay vs. Server Delay (Delta Time) #

User says: "The webpage takes 10 seconds to load!" Is it a slow network, or a slow server? Add a custom column in Wireshark: Delta Time (Time since the *previous* displayed packet).

1. 1. The Request: Client sends HTTP GET /report (Delta time: 0.001s).

1. 2. The Network Acknowledgment: Server replies [ACK] confirming receipt of the GET request (Delta time: 0.050s).

• *Analysis:* The network is fast! The packet traveled to the server and back in 50 milliseconds.

1. 3. The Response: Server finally sends HTTP 200 OK containing the report data (Delta time: 9.500s).

• *Analysis:* The database is the problem! The server acknowledged the request instantly, but it spent 9.5 seconds "thinking" before it could actually generate the HTML response. You have mathematically proven the network is innocent.

6. Troubleshooting Scenarios & Flow #

*Scenario: "DNS is broken."*

• Filter: dns.

• Look for: A Standard query leaving the PC.

• Check: Does a Standard query response ever come back? If no, the DNS server is down. If yes, but it says Server failure (2), the DNS server is alive but malfunctioning.

*Scenario: "I'm on public Wi-Fi and everything is timing out."*

• Filter: tcp.flags.syn == 1 && tcp.flags.ack == 0.

• Look for: Your PC sends a SYN to Google. Then another SYN. Then a third SYN. No SYN-ACKs ever return.

• Diagnosis: The Captive Portal (the "Accept Terms" page for the coffee shop) is actively dropping all internet-bound routing until you log in.

7. Best Practices #

• Establish a Baseline: You cannot identify abnormal traffic if you do not know what normal traffic looks like. Professional engineers take baseline PCAP captures of critical servers when they are healthy and functioning perfectly. When a crisis occurs, they compare the broken capture to the healthy baseline.

8. Common Mistakes #

• Blaming the Network for Everything: It is a classic IT trope that "The Network is always to blame." Junior analysts open Wireshark, see a few black TCP Retransmissions, and declare the network faulty. Remember, TCP is designed to handle minor drops seamlessly. Always check the Delta Times (Server delay) before blaming the physical switches.

9. Mini Project: Add the Delta Time Column #

This is the single most important customization for troubleshooting.

1. 1. Open Wireshark.

1. 2. Go to the top menu: Edit -> Preferences -> Columns.

1. 3. Click the + button to add a new column.

1. 4. Title: Delta Time

1. 5. Type: Click the dropdown and select Delta time displayed.

1. 6. Click OK.

You now have a powerful column that tells you exactly how many seconds/milliseconds elapsed between the current packet and the packet directly above it.

10. Practice Exercises #

1. 1. Explain how a high volume of [TCP Retransmission] packets in Wireshark visually indicates physical network congestion or packet loss.

1. 2. If a client sends a TCP SYN packet and immediately receives a TCP RST packet in return, does this indicate a routing failure or an application-layer rejection?

11. MCQs with Answers #

12. Interview Questions #

• Q: A developer blames the corporate network for their application crashing. You review a Wireshark capture and observe the client sending a SYN, receiving a SYN-ACK, sending an ACK, and then immediately receiving a FIN packet from the server. Defend the network and diagnose the issue.

• Q: Explain the forensic workflow for configuring and utilizing the "Delta Time" column in Wireshark to isolate application latency.

• Q: What is a TCP Duplicate ACK, and under what specific network conditions does Wireshark generate this alert?

13. FAQs #

Q: Can Wireshark fix the network issue? A: No. Wireshark is a diagnostic thermometer, not a medicine. It will tell you with absolute precision that a router is dropping packets, but you still have to log into the physical router's command line to fix the bad cable or the misconfigured firewall causing the drops.

14. Summary #

In Chapter 13, we weaponized Wireshark for IT diagnostics. We learned to interpret Wireshark's automated Expert Info colors, identifying the severe black-and-red warnings of [TCP Retransmission] as undeniable proof of packet loss. We analyzed the TCP RST flag to identify connection refusals at the server level. Crucially, we customized our GUI to include the "Delta Time" column, allowing us to mathematically separate physical network transit latency from application-layer processing delays. Wireshark empowers you to definitively prove where the fault lies.

15. Next Chapter Recommendation #

You can troubleshoot wired networks. But what happens when the packets are flying invisibly through the air? Proceed to Chapter 14: Wireless Packet Analysis.