The utilities from the previous lesson work on summaries: ping gives you times, curl gives you phases, traceroute gives you hops. But sometimes the summary is not enough. Why does that connection take 3 seconds to establish? What exactly is that machine asking the DNS? Are packets being lost inside the VPN with Bilbao? To answer, you have to stop inferring and see the actual packets, one by one, with the headers of every layer. That is traffic capture, and its two canonical tools are Wireshark (graphical) and tcpdump (terminal). This lesson is also the course's big payoff: everything you have studied in the abstract — module 2's encapsulation, the layers of modules 3 and 4, the three-way handshake — you are finally going to see in real packets on Meridiano's network.

⚠️ Legal and ethical warning — read it before capturing anything

Capturing traffic means reading the communications that cross a network. Intercepting third parties' communications without authorization is a crime (in Spain, defined as an offense in the Criminal Code, and contrary to the GDPR whenever personal data is involved; equivalents exist in practically every country). The rules of this course, and of your professional life, are:

• Capture only on networks you own or with explicit authorization from whoever is responsible for them. "It's the café's Wi-Fi and it was open" is not authorization.
• In a company, informal authorization is not enough: do it in accordance with internal policies (sign-off from the systems/security manager, a record of the action, a defined purpose).
• Captures contain personal data and credentials: store them encrypted, for no longer than strictly necessary, share them only with those who need to see them, and delete them when the incident is closed. A .pcap file forgotten on a shared desktop is a data breach.
• Everything we do here is diagnostics on Meridiano's own network, with authorization: that is the only legitimate context this course teaches.

1. When to capture: the limits of the basic utilities
2. Wireshark: installation and anatomy of the interface
3. The detail pane IS encapsulation
4. Capture filters vs display filters
5. Following a TCP conversation: the handshake, seen for real
6. tcpdump: capturing on a server with no graphical interface
7. Guided analysis (a): DNS + GET to the intranet, packet by packet
8. Guided analysis (b): the slow Valencia–Bilbao video call

Signs that it is time to open the capture tool:

• The symptom is about content, not connectivity: the connection establishes, but the application behaves oddly (truncated responses, unexpected headers, strange redirects).
• The symptom is about timing: "it takes ages to start", "it freezes now and then". The times between packets can only be seen by capturing.
• Two tools contradict each other: ping looks fine but the application is terrible → probably selective loss or retransmissions that the summary doesn't show.
• You need evidence: to escalate to the VPN provider or the ISP, "it's slow" won't do; a capture with timestamped retransmissions will.

Golden rule: capture is the last rung, not the first. It is the most powerful tool and the most expensive in analysis time; come to it with a hypothesis already shaped by the 06-01 utilities.

Wireshark is free and open source (wireshark.org), available for Windows, Linux and macOS. Two installation notes worth understanding conceptually:

• Capturing requires privileged access to the network card, which is put into listening mode. On Windows that is provided by the Npcap driver (installed along with Wireshark); on Linux, you either run with elevated permissions or (better) add your user to the wireshark group.
• On a modern switch you will only see your own traffic and broadcast (the switch forwards by MAC, module 2, and doesn't relay other people's conversations to you). To see another machine's traffic — always with authorization — you configure a mirror port (port mirroring/SPAN) on the switch, or you capture directly on the server involved, which is what we will do with tcpdump.

When you open Wireshark you pick an interface (the Ethernet or the Wi-Fi), press the capture button, and the window organizes itself into three stacked panes:

A tip for reading the list: the time column is by default relative to the start of the capture; big jumps between consecutive rows of the same conversation are your first indicator of "this is where it got stuck".

Pause on this, because it is the moment the course "closes the circle". Select any packet and the detail pane shows something like:

Each expandable line is one layer of encapsulation, exactly the "Russian doll" you studied in module 2 and formalized with OSI (module 3) and TCP/IP (module 4):

• Frame → the physical/link layer as the capture engine sees it (layer 1: how many bytes went over the wire).
• Ethernet II → layer 2: Marta's and the intranet server's MACs, module 2's frame.
• Internet Protocol → layer 3: IPs, TTL, fragmentation. Expand it and you will see the TTL field you have been using since module 2.
• TCP → layer 4: ports, sequence numbers, flags (SYN, ACK, FIN, RST...), window.
• TLS / HTTP / DNS... → the application layer.

Wireshark doesn't "draw" the layers for pedagogy's sake: it decodes the real packet in that order because that is how the packet is built. When we said in module 2 that HTTP travels inside TCP, inside IP, inside Ethernet, we were literally describing these four expandable lines. From now on, whenever you doubt which layer does what, open a capture: the answer is right in front of you.

An office interface generates hundreds of packets per second; without filtering, you drown. Wireshark has two filtering systems that beginners confuse constantly:

Recommended strategy when starting out: capture wide (at most a gentle capture filter, like host for the machine under investigation) and filter at display time, which is reversible. An overly aggressive capture filter can throw away exactly the packet that explained the problem (for example, you filter port 443 and miss the failed DNS query that was the real cause).

Essential display filters, using Meridiano's network:

They combine with && (and), || (or), ! (not). If the filter bar turns green, the syntax is valid; red, it is not (the classic: typing port 443 — capture syntax — where display syntax belongs).

In module 2 you studied the three-way handshake with a diagram. Now, Marta opens the intranet and we capture on her PC with the filter ip.addr == 192.168.10.10 && tcp:

Line by line:

• Packet 12 — SYN: Marta (ephemeral port 52814, module 2) calls the server's 443. Notice the advertised MSS=1460: it is the MSS we calculated from the MTU in module 4 (1500 − 40).
• Packet 13 — SYN, ACK: the server accepts. If instead of this you saw an RST, it would be 06-01's "connection refused": closed port. If you saw nothing (the SYN retransmitted several times), it would be the timeout: dead host or a firewall dropping packets.
• Packet 14 — ACK: connection established. Three packets, just as module 2's diagram promised — but now with timings: a 0.6 ms round trip, consistent with a LAN.
• Packets 15–16: on top of the now-open connection, TLS starts. The SNI (the server's name) travels in the clear inside the Client Hello: it is one of the few readable things in an encrypted connection.

Two Wireshark moves you must know:

• Right-click → Follow → TCP Stream: isolates that entire conversation and, if the traffic is unencrypted, shows the dialogue in readable form (you will see a whole HTTP exchange as text). With HTTPS you will see encrypted data — which is precisely module 2's TLS guarantee.
• Statistics → Conversations: a table of every conversation in the capture with bytes and duration; ideal for finding "who is eating the bandwidth".

The intranet server (192.168.10.10) is a Linux box with no desktop: there is no Wireshark there. The tool is tcpdump, which uses the same BPF syntax as capture filters and requires privileges (sudo):

Keys to reading and using it:

• -i eth0: the interface to listen on; -n: don't resolve names (faster, and it doesn't generate its own DNS traffic to pollute the capture).
• The filter port 443 and host 192.168.10.21 goes at the end, in BPF syntax.
• Flags come abbreviated: [S] = SYN, [S.] = SYN+ACK (the dot is ACK), [.] = ACK, [F] = FIN, [R] = RST. There is the complete handshake again, now in plain text.
• Other useful options: -c 100 (stop after 100 packets), -v (more detail, includes TTL), -A (show the payload in ASCII, useful with unencrypted HTTP).

The professional workflow combines both tools — capture where it happens, analyze where you are comfortable:

Remember the opening warning: that .pcap contains real communications. Treat it as the sensitive data it is.

Let's reproduce, with a capture, the complete flow you studied at the end of module 4: Marta opens https://intranet.grupomeridiano.example/api/proyectos with an empty DNS cache. Capture on her PC, display filter dns || (ip.addr == 192.168.10.10 && tcp):

Watch the script play out — you know it by heart already, but now it has numbers:

1. DNS (packets 1–2): the query goes to the configured DNS (the .10.1 router), which answers the A record in 1.8 ms. It rides over UDP port 53 — verify it by expanding packet 1's transport layer. If you repeat the test, these two packets disappear: the answer stayed in the cache (06-01's record TTL in action).
2. TCP (3–5): the handshake.
3. TLS (6–8): the cryptographic greeting. In packet 7 you can expand and examine the server's certificate.
4. HTTP (9–10): the GET and its response travel as "Application Data" — encrypted. You know GET /api/proyectos is inside because you triggered it yourself, but Wireshark cannot (and should not) read it.

Total time: under 20 ms. File this "healthy" capture away mentally: it is your reference pattern for the next analysis, where something goes wrong.

Symptom: video calls between Marta (Valencia) and Jon (Bilbao) have been freezing intermittently for a few days; browsing "seems" normal. A ping -t 192.168.20.7 from Valencia shows occasional loss (2 out of every ~30) and high jitter — a clue, not a diagnosis. With the systems manager's authorization, we capture on Marta's PC during a test call plus a simultaneous file transfer toward Bilbao, and apply the filter:

And in Statistics → TCP Stream Graphs (or simply counting with the filter): ~3% of the segments toward Bilbao are retransmissions, concentrated in bursts. The interpretation, leaning on what you know about TCP (module 2) and the VPN (module 4):

• A retransmission means TCP sent a segment and didn't receive its ACK in time: the segment (or its ACK) got lost along the way. The Dup ACKs are the receiver saying "I'm missing a piece, resend".
• Browsing "seems normal" because TCP repairs the loss by retransmitting — paying in latency, which on a web page is barely noticeable. The video call uses real-time UDP: what is lost is not resent (resending an old video frame would be pointless), so the very same loss TCP papers over shows up in the call as freezing. Two different symptoms, one single cause: packet loss on the Valencia–Bilbao path.
• Where? The capture on the Valencia LAN shows the segments leaving; a ping within the site loses nothing; the loss only appears toward the other site → the problem is in the VPN or the Internet line carrying it, not in the LANs. It is the same narrowing-down reasoning as 06-01's traceroute, now with quantified evidence.
• Case closed: with the capture as evidence (3% retransmissions in bursts, timestamps), Meridiano opens a ticket with its ISP, which detects saturation on the Valencia line at the times of the bursts. Without the capture, the conversation would have been "it's slow" / "it looks fine from our end".

• Capturing without authorization "just to learn". No. Practice on your own home network or in virtual machines. At the company, follow the procedure even if you have the technical permissions to skip it.
• Mixing up the two filter syntaxes. port 443 in the display bar errors out (red); tcp.port == 443 in a capture filter does too. Capture with BPF, display with Wireshark syntax.
• Filtering too hard at capture time. What gets discarded cannot be recovered. Capture wide, filter at display time.
• Expecting to read HTTPS. You will see the TLS handshake, the SNI and sizes/timings — which is already a great deal for diagnosis — but not the content. If you need the content of your own application, the way in is at the endpoints (server logs, curl -v), not breaking the encryption.
• Capturing in the wrong place. On a switch you won't see other machines' conversations. Capture at the endpoint involved (PC or server) or request a mirror port.
• Forgetting -n in tcpdump. Without it, every IP triggers a reverse DNS lookup: the output stutters along and your own capture fills up with your own DNS traffic.
• Treating any retransmission as a catastrophe. The odd isolated retransmission is normal life on the Internet. What matters are sustained percentages (≳1–3%) and bursts correlated with the symptom.
• Leaving .pcap files lying around. Encrypted while they live, deleted when the incident closes.

1. In a capture from Ana's PC you see, three times in a row and spaced ~1, 2 and 4 seconds apart, the same packet: 192.168.10.24 → 203.0.113.40 TCP [SYN] 51330 → 443. There is no SYN/ACK and no RST coming back. What is happening, how does it differ from receiving an RST, and which user-facing symptom does it correspond to?
2. You want to capture, on the intranet server (no graphical environment), all the DNS traffic the server itself generates or receives, save it to a file and analyze it later on your PC with Wireshark. Write the capture command and describe the two steps that follow. Which non-technical precondition must you satisfy before running anything?
3. During the video-call analysis, a colleague proposes: "let's filter the capture with tcp.analysis.retransmission from the start, as a capture filter, so the file is smaller". Explain the two errors in the proposal.

1. It is the pattern of an unanswered SYN with exponential retransmission: Ana's system retries the SYN doubling the wait (1 s, 2 s, 4 s...) because nobody answers. Either host 203.0.113.40 is down or — more commonly — a firewall is silently dropping the packet (a drop policy). The difference from an RST is crucial: the RST is an active reply ("host alive, port closed" → immediate connection refused error), whereas silence produces a long timeout: the user sees the application "hang" for 20-30 seconds before the error. It is module 3's "closed port vs dead host" pair, seen in packets.
2. Precondition: authorization in accordance with internal policies (it is the company's server, and DNS traffic reveals user activity). Command: sudo tcpdump -i eth0 -n port 53 -w /tmp/dns-intranet.pcap (DNS uses port 53; -w saves in pcap format; stop with Ctrl+C or by adding -c N). Next steps: (1) copy the file to the analysis PC (with scp, for example), (2) open it in Wireshark (File → Open) and analyze it with display filters (dns). When the incident closes, delete the .pcap.
3. First error, syntactic-conceptual: tcp.analysis.retransmission is a display filter; capture filters use BPF syntax and no such filter exists there — in fact it cannot exist, because detecting a retransmission requires comparing each packet with the previous ones in its flow, and the capture filter decides packet by packet, with no memory. Second error, methodological: even if it could be done, you would keep only the retransmissions and lose their context (the original packets, the Dup ACKs, the times between them), which is exactly what lets you compute the loss percentage and locate it. You capture wide and filter at display time.

You now know how to go down to the level where packets cannot lie: Wireshark with its three panes (and the revelation that the detail pane is the encapsulation of modules 2–4), the discipline of the two filter types, the three-way handshake finally contemplated in real packets from Marta to the intranet, tcpdump for capturing on servers and taking the .pcap away to analyze at leisure, and two complete analyses: the healthy DNS→TCP→TLS→HTTP flow as a reference pattern, and the slow video call solved by spotting retransmissions on the VPN. And wrapping it all, the framework that is not optional: only on your own or authorized networks, in accordance with company policy, treating captures as the sensitive data they are. You have the quick utilities (06-01) and the microscope (06-02); what is missing is what separates the professional from the amateur with tools: a method that decides what to check, in what order, and when to stop. That systematic method — layered approaches, the 7 steps, the decision tree and three Meridiano incidents solved start to finish — is the next and final lesson of the module.