See the packets. Then write the ticket.

A Tier 1–2 technician spends most of the day between a user who sees a symptom and a team that owns the fix: the network team, the server team, an application vendor. The quality of that hand-off decides how fast the ticket closes. “User can’t reach the portal” bounces around for days. “SYN packets to 10.20.8.15:443 get no reply from three different VLANs since 09:40 PT; the server is up and listening locally” lands on the right desk within the hour.

Wireshark records the packets that actually crossed a network interface and decodes them into something readable. Nmap asks a host, from wherever you are standing, which ports answer and how. One is a microphone, the other a knock on the door. They complement the usual first-line tools (ping, ipconfig, nslookup, Test-NetConnection), they do not replace them.

When each tool earns its place

A layered habit

Walk up the stack and stop at the first layer that fails: link (cable, Wi-Fi, ARP) → addressing (DHCP, IP, gateway) → name (DNS) → transport (TCP handshake, port reachable) → security (TLS) → application (HTTP status, login). Both tools map neatly onto this ladder, and the rest of this page follows it.

Install and first launch

• Windows: the installer bundles Npcap, the driver that lets Wireshark read packets. Without it you get an empty interface list. On managed laptops the install usually needs IT approval.
• macOS / Linux: capturing needs elevated rights. On Linux the usual approach is to add your user to the wireshark group so only the small dumpcap helper runs privileged, rather than running the whole GUI as root.
• No install allowed? Windows 10/11 ships pktmon, which can capture and convert its output to pcapng for Wireshark on another machine.

Choosing the interface

The start screen lists interfaces with a small live traffic sparkline. Pick the one that carries the traffic you care about: the Wi-Fi adapter or Ethernet adapter, not a virtual one. VPN clients often add their own adapter: traffic to the corporate app goes through it, so capturing on Wi-Fi only shows encrypted tunnel packets. Loopback is for traffic a machine sends to itself.

Where to capture matters more than how

• On the client: shows what the user’s machine sent and received. Easiest and least invasive.
• On the server (with approval): proves whether the client’s packets actually arrived.
• Both ends at once: the strongest evidence. A SYN that leaves the client but never reaches the server has been dropped somewhere in between, and you have the timestamps to show it.
• SPAN / mirror port or a network TAP: for devices you cannot install software on (printers, phones, appliances). That is network-team territory.

Promiscuous mode asks the network card to keep frames not addressed to it. On a modern switched network you still mostly see your own traffic plus broadcasts, which is why mirror ports exist. On Wi-Fi, capturing other clients needs monitor mode, which most Windows adapters do not support.

Capture filters vs display filters

They look similar and are not. A capture filter uses the BPF syntax shared with tcpdump and is applied before packets are saved; anything it rejects is gone. A display filter uses Wireshark’s own field-based language and only hides packets in a capture you already have. Use a capture filter to keep files small and private on busy links; use display filters for the actual analysis.

Settings worth changing once

• Time format: View → Time Display Format. “Seconds since previous displayed packet” makes gaps jump out; “UTC date and time” or local time of day makes it easy to match the user’s “it froze at 2:14”.
• Ring buffer for intermittent problems: capture to several fixed-size files that rotate, so you can leave it running until the fault reappears without filling the disk.
• Name resolution: resolving IP addresses to host names is off by default; leave it that way on large captures, because looking up every address slows the GUI and adds your own DNS queries to the traffic.
• Reproduce on purpose: start the capture, then have the user repeat the failing action, and write down the clock time. A short, focused capture beats an hour of noise.

Syntax in one minute

• Filters name a protocol or a field: dns, tcp.port, http.response.code.
• Compare with ==, !=, >, <, contains, matches (regular expression), and combine with &&, ||, ! and parentheses.
• ip.addr matches source or destination. To exclude a host, write !(ip.addr == 10.20.4.57). Older Wireshark versions read ip.addr != … as “either address differs”, which matched nearly everything; the !( … ) form means the same thing in every version.
• Click any field in the packet details pane and the status bar shows its filter name. Right-click → Apply as Filter or Prepare as Filter builds it for you.

The support short list

Habits that save time

• Narrow in steps: host → port → the protocol → the problem flag. Save useful ones as filter buttons (the “+” on the filter toolbar).
• Exclude your own noise: if you are remoted into the machine, add !(tcp.port == 3389) or the remote tool’s port, or your own session floods the capture.
• Coloring rules paint TCP problems black with red text by default. A wall of black rows is a hint before you have typed anything.
• Mark and note: Ctrl+M marks a packet; add a packet comment with the finding. Frame numbers make the ticket note precise (“frames 112–118”).

Every TCP connection starts with a three-way handshake: the client sends SYN, the server answers SYN/ACK, the client confirms with ACK. After that both sides number their bytes (sequence numbers) and acknowledge what they received. Each side also advertises a window, how much more data it can accept right now. Toggle the cases below and watch how each failure looks different on the wire.

What each shape usually means

Network time vs server time

The handshake gives you the network round trip for free: time from SYN to SYN/ACK as seen from the client. If that is 12 ms but the first byte of the response arrives 4 seconds after the request, the network is not the bottleneck; the server or application is. That one comparison prevents a lot of “the network is slow” tickets from bouncing to the wrong team.

A real handshake from the lab

Below is a plain HTTP request from curl to a small test web server on the same machine. Real loopback traffic, so the timings are microseconds rather than the milliseconds you would see across a network.

Read it as: handshake (1–3), request (4), server acknowledges and answers in about 1.8 ms (5–8), both sides close politely with FIN (10–12). A RST instead of FINs at the end would be worth a second look.

DNS: the answer, the error, or the silence

Filter on dns and look at pairs: a query and its response share a transaction ID, and Wireshark links them (“response in frame 214”). Three outcomes matter:

• Answer with records: DNS worked. If the app still fails, check that the returned IP is the right one (stale record, split DNS, hosts file, VPN vs office answer).
• Error code: NXDOMAIN (rcode 3, name does not exist: typo, missing record, wrong search suffix), SERVFAIL (rcode 2, the server could not resolve: often a broken forwarder or DNSSEC problem), REFUSED (rcode 5, that server will not answer this client).
• No response: the query left and nothing came back. The client retries and may switch to its secondary DNS server, adding seconds of delay. Firewall rules or an unreachable DNS server are the usual suspects.

Columns: frame, query name, response code (0 = no error, 3 = NXDOMAIN), response time in seconds. Rows without an rcode are the queries themselves.

DHCP: DORA

A client without an address broadcasts a Discover, servers reply with an Offer, the client broadcasts a Request for one offer and the chosen server confirms with an Acknowledge. Renewals later skip straight to Request/Ack, sent directly to the server. Capture on the client with the filter udp port 67 or udp port 68, then run ipconfig /release and ipconfig /renew (with the user’s consent: it drops their connection briefly).

• Discovers leave, no Offer: the broadcast never reaches a server. Check the switch-port VLAN, the DHCP relay (IP helper) on the router for that VLAN, and the server’s scope status.
• Offer arrives, client never Requests: rare; suspect the client (driver, security software) or a malformed offer.
• Offers from two different servers: a rogue DHCP server, often a home router plugged into an office port. Every client that takes its offer gets a wrong gateway.
• Scope exhausted: the server stays silent or logs “no free leases”. Common on guest Wi-Fi with long lease times.

ARP: who owns this IP?

To send a packet to a host on the same subnet (or to the default gateway), a machine broadcasts “who has 10.20.4.30?” and the owner replies with its MAC address. ARP problems are rare but nasty because everything above them breaks at once.

• Requests with no reply: the target is off, on another VLAN, or the IP is simply wrong.
• Two MACs answering for one IP: duplicate address, usually a device with a static IP inside the DHCP range. Symptoms come and go as caches update.
• The gateway’s MAC suddenly changes: could be a failover pair (normal) or ARP spoofing (not normal: involve security).
• Gratuitous ARP: a host announcing its own IP, normal at boot or failover. Many in a row from one host after a cable plug-in are expected.

On the client side, arp -a (Windows) or ip neigh (Linux) shows the cached MAC for an IP. Comparing that MAC with the label on the printer is a two-minute check that finds duplicate IPs.

TLS handshake failures

Filter with tls.handshake or tls.alert_message. The ClientHello is always readable: it shows the server name the client asked for (SNI), the TLS versions it offers and its cipher suites. If the connection dies right after it, the server’s reply (an alert, a reset, or silence) tells you which side objected.

Lab setup: a throwaway test server that accepts TLS 1.3 only, contacted once by a client limited to TLS 1.2 (rejected with alert 70) and once normally (succeeds). Columns trimmed; plain ACK rows omitted.

Usual support causes behind TLS errors

• Protocol version: an old client, embedded device or legacy app after a server was hardened (or the reverse).
• Unknown CA / bad certificate: missing intermediate on the server, an SSL-inspection proxy whose root certificate is not deployed on this device, or a self-signed certificate.
• Certificate expired or “not yet valid”: check the server certificate dates and the client clock. A laptop with a dead CMOS battery fails every HTTPS site.
• Name mismatch: the user typed an IP or short name that the certificate does not cover. Compare SNI with the certificate’s names.
• Reset right after ClientHello: often a security device or proxy blocking that destination by SNI.

A useful cross-check outside Wireshark: openssl s_client -connect host:443 -servername host prints the chain and the negotiated version, and browsers show the certificate in the padlock menu.

Follow TCP Stream

Right-click any packet → Follow → TCP Stream. Wireshark rebuilds the whole conversation as text, client in one color, server in another, and applies a tcp.stream == N filter. For plain HTTP, SMTP, FTP or a printer’s web page you can read the request and the error message directly. For TLS you see ciphertext, which still shows who stopped talking first. Mind the privacy rules: this is where passwords and personal data become readable.

Statistics menu: the 30-second overview

The same statistics are available from the command line, which is handy on servers without a GUI or for pasting into a ticket:

The Expert note on the scan capture is a nice detail: Nmap’s probes are hand-built minimal SYNs without the options a normal operating system adds, and Wireshark notices.

tshark and dumpcap basics

dumpcap is the small capture engine Wireshark itself uses; tshark is the full dissector on the command line. Use them on servers, over SSH, for long ring-buffer captures, or to pull specific fields into a CSV.

Command-line capture and analysis. Interface numbers differ per machine; check with tshark -D.

tshark -D                                   # list interfaces with numbers
tshark -i 2 -f "host 10.20.8.15" -a duration:120 -w case1234.pcapng
dumpcap -i 2 -f "tcp port 445" -b filesize:100000 -b files:10 -w smb.pcapng   # ring buffer: 10 x ~100 MB
tshark -r case1234.pcapng -Y "tcp.analysis.flags"          # read a file with a display filter
tshark -r case1234.pcapng -Y "dns.flags.rcode != 0" -T fields -e frame.time -e dns.qry.name -e dns.flags.rcode
tshark -r case1234.pcapng -q -z conv,tcp                   # conversations
tshark -r case1234.pcapng -q -z io,phs                     # protocol hierarchy
tshark -r case1234.pcapng -q -z expert                     # expert info summary

Related helpers ship in the same package: editcap trims or splits files (for example to send only the five relevant minutes), mergecap combines client and server captures, capinfos prints a file’s time range and packet count for the ticket.

Host discovery: -sn

nmap -sn 10.20.4.0/24 checks which addresses respond without scanning any ports (older docs call it a “ping scan”). On the local subnet with admin rights Nmap uses ARP, which firewalls cannot hide; across routers it combines ICMP echo, TCP probes to common ports and ICMP timestamp requests. A host that blocks all of these looks “down” even when it is not; -Pn skips discovery and scans anyway.

The port states

Scan types you will actually use

• -sS SYN scan (default with admin/root): sends SYN, reads the answer, never completes the handshake. Fast and quiet for the target application, still very visible to firewalls and IDS.
• -sT connect scan (default without privileges): uses the operating system’s normal connect call. Full handshake, so the application may log it.
• -sU UDP scan: needed for DNS (53), DHCP (67), SNMP (161), syslog (514), NTP (123). Slow, because silence is ambiguous and many systems rate-limit ICMP replies. Scan only the UDP ports you care about.

Choosing ports: -p

Without -p, Nmap scans the 1,000 most common ports for each protocol you select.

nmap -p 443 10.20.8.15                 # one port
nmap -p 80,443,8080-8090 10.20.8.15    # list and range
nmap -p U:53,T:53,443 -sU -sS 10.20.0.10   # UDP and TCP together (needs admin)
nmap -F 10.20.8.15                     # 100 most common ports
nmap --top-ports 20 10.20.8.15         # the 20 most common
nmap -p- 10.20.8.15                    # all 65,535 TCP ports (slow, only with a reason)

A real scan with all three states

For the lab, one port had a small web server, one had a TLS test server, one had nothing listening, and one was blocked by a local firewall rule that silently drops packets. --reason prints the evidence behind each verdict:

“unknown” in the SERVICE column just means these high lab ports are not in Nmap’s list of well-known ports; -sV (next section) actually asks the service.

Timing: -T0 to -T5

Templates trade speed for gentleness: -T3 is the default, -T4 is reasonable on a healthy LAN, -T2 or lower suits fragile devices and slow WAN links. -T5 can drop probes and report false “filtered” results, which is the opposite of what a troubleshooter wants. For finer control, --max-rate caps packets per second.

Service and version detection: -sV

-sV connects to open ports and compares the replies with Nmap’s database of service fingerprints. It answers “is that really a web server on 8080, and which one?” It takes longer, completes real connections (applications log them) and is not always right, so treat versions as a strong hint, not proof.

A quick test page served by Python’s built-in web server, correctly identified, plus two safe scripts reading the server header and page title. Against the TLS test port, -sV only reported ssl/unknown and printed a raw fingerprint: a good reminder that unusual services are not always named.

OS detection -O and the -A shortcut

• -O guesses the operating system from subtle TCP/IP behavior. It needs admin rights and works best when the target has at least one open and one closed port. Results are a ranked guess; firewalls and virtualization blur them.
• -A switches on OS detection, version detection, default scripts and traceroute together. Convenient in a lab, heavy and noisy on a production network: many probes, many connections, scripts that log in to services anonymously. In support work, prefer to ask for exactly what you need (-sV -p …).

Nmap Scripting Engine (NSE), safely

Scripts extend Nmap with protocol-specific checks. They are grouped into categories, and the category is your safety label:

Safe-category scripts useful for support checks. Run only against hosts in the ticket.

nmap -p 443 --script ssl-cert 10.20.8.15            # who issued the cert, valid dates, names it covers
nmap -p 443 --script ssl-enum-ciphers 10.20.8.15    # TLS versions/ciphers offered (helps with version alerts)
nmap -p 80,8080 --script http-title,http-headers 10.20.8.15
nmap -p 445 --script smb-protocols 10.20.8.30        # which SMB dialects the file server speaks
nmap --script-help ssl-cert                          # read what a script does before running it

Saving results: -oN, -oX, -oG, -oA

• -oN file.txt: normal human-readable output, ideal to attach to a ticket.
• -oX file.xml: XML for tools and for comparing scans over time (the ndiff utility highlights what changed between two XML results).
• -oG file.gnmap: “grepable”, one line per host, easy to filter with grep or findstr. Older format, still handy.
• -oA basename: all three at once. A good default habit: -oA ticket-48213-before.

Other flags that keep output useful: --open (show only open ports), -n (no reverse DNS, faster and avoids noise), -v (progress as it goes), and --packet-trace (print every probe, a great way to learn what a scan really sends).

Start a capture filtered to the target, run a small scan, stop the capture. Every verdict in the Nmap output now has packets behind it. The animation shows the general pattern; the lab capture underneath shows the exact packets behind the four-port scan from the previous sections.

What to notice

• Port order is shuffled on purpose (18443 before 18389 before 18080). Nmap randomizes it.
• One source port, tiny window (1024), minimal options: hand-crafted probes, unlike a normal OS SYN. Wireshark’s Expert Info even flags the missing SACK option.
• The filtered port gets a retry about a second later: Nmap does not trust a single silence.
• Filter to see only the probes: tcp.flags.syn == 1 && tcp.flags.ack == 0. Nmap’s probes typically advertise a very small window (1024 here), while normal operating-system SYNs offer tens of thousands, so adding && tcp.window_size <= 4096 often separates scan probes from ordinary connections.
• Statistics → Conversations after a wider scan shows one source talking to hundreds of ports with one or two packets each: the signature that intrusion detection systems alert on.

The two-ended test for “firewall or service?”

1. Start a capture on the server (approved, filtered to the client’s IP and the port).
2. From the client, run nmap -Pn -p 8443 --reason 10.20.8.15 or Test-NetConnection 10.20.8.15 -Port 8443.
3. SYN never shows up on the server → it was dropped before the host: network firewall, ACL, routing, or the wrong IP.
4. SYN arrives, server sends RST → nothing listening: service down or wrong port. Nmap said closed.
5. SYN arrives, nothing goes back → the host firewall on the server is dropping it. Nmap said filtered.
6. SYN/ACK goes back but the client never sees it → return path problem: asymmetric routing or a stateful device on the way back.

The scenarios all end the same way: a short note someone else can act on without calling you. Keep findings factual (what, where, when, which frames), keep the assessment separate and honest about confidence, and name the next owner. Times in the user’s time zone with a label.