Wireshark Lab — Deep Dive into UDP & TCP Behaviour

Session Context and Objectives

  • Practical workshop following Monday’s lecture on transport-layer protocols (UDP & TCP)

  • Using Wireshark inside a VM; interface chosen = Ethernet 0 (your host interface may differ)

  • Goals:

    • Capture and inspect live UDP packets (DNS, QUIC)

    • Analyse full UDP header, identify all 4 fields

    • Discover IP-layer “Protocol Number” mapping (UDP = 17, TCP = 6)

    • Practise Wireshark field-highlighting & hex correlation

    • Move to TCP analysis: capture an HTTP file download & attempted upload, then disable HTTP dissector to expose raw TCP

    • Visualise TCP behaviour (3-way handshake, sequence/ack numbers, sliding window, retransmissions) with graphs & flow-graphs

    • Compare behaviour on a “clean” trace vs one with induced loss/window exhaustion

  • Ancillary: reminders about Assessment 1 (online quiz), VM file copy, enabling/disabling protocol dissectors

Capturing UDP — Step-by-Step

  • Start Wireshark → press the shark icon on Ethernet 0 interface (watch for real-time traffic graph)

  • Generate UDP quickly via DNS:

    • Launch browser → visit any site (example: www.unisq.edu.au)

    • DNS queries (port 53) fire before HTTP; this yields small UDP packets

  • Stop capture to analyse

  • Apply display filter: udp (bar turns green ⇒ syntactically correct)

  • Typical UDP traffic observed:

    • DNS queries/responses (classic UDP)

    • QUIC (HTTP/3 built on UDP)

UDP Header Fields Recap

  • Header = only 4 fields, each 16 bits (== 2 bytes)

    1. Source Port

    2. Destination Port

    3. Length (header + data)

    4. Checksum

  • Total header length = 4 x 2 = 8 bytes

  • Example from capture:

    • Source Port: 54254 (ephemeral)

    • Destination Port: 53 (DNS server)

    • Packet Length: 56 B ⇒ Payload 56-8=48 B (Wireshark shows this)

    • Checksum often “unverified” (many stacks skip validation for speed; corrupted packet is simply dropped)

Relating to IP Layer

  • Expand IPv4 header → Protocol field shows numeric code 17 = UDP

  • Purpose: downstream devices (e.g.

    outers) may need protocol awareness for fragmentation, ICMP messaging, efficiency decisions

Matching Query & Response

  • In packet list, Wireshark draws paired arrows indicating request vs reply

  • Regardless of packet ID numbers, response recognised by:

    • Direction arrow flips

    • Same Transaction ID/name (e.g.

      accounts.google.com)

    • Ports reversed: server’s reply source 53 → dest 54254

DNS Application-Layer Details

  • Open DNS section → Flags show Standard Query

  • Query list:

    • Name: accounts.google.com

    • Type A (record mapping to IPv4) or Type AAAA (mapping to IPv6)

    • Class IN (Internet)

  • Response carries:

    • Original question echoed

    • Answer section with IP(s)

    • Additional records (e.g.

      OPT for EDNS, MX, CNAME etc.)

  • Typical sizes: approximately 50 bytes ⇒ ideal for UDP (fits into one datagram, no fragmentation)

Why Use UDP?

  • Minimal header, zero connection setup → low latency & CPU cost

  • Suited to:

    • Small request/response protocols (DNS, NTP)

    • Loss-tolerant streaming (VoIP, video, games, QUIC)

  • Reliability/encryption, if needed, pushed to application layer

Transition to TCP Analysis

Capture Scenario

  • Download text of Alice in Wonderland (alice.txt) via HTTP to generate many segments

  • Attempt PUT upload to upload.d0dji.net/upload.html (server later overloaded, useful for observing retries/timeouts)

  • Restart capture before upload; stop afterwards

Disabling HTTP Dissector

  • Menu: Analyze → Enabled Protocols → search HTTP → uncheck HTTP/1, HTTP/2, HTTP/3

    • Forces Wireshark to show raw TCP; existing http && ip.addr==X.X.X.X filter breaks

    • New filter: tcp &amp;&amp; ip.addr==<server-ip>

    • Reminder: re-enable HTTP at end of lab

TCP Fundamentals in the Trace

Three-Way Handshake

  • Identify first SYN from client port 54006 → server port 80

  • Right-click → Follow → TCP Stream (assigns stream index)

  • Handshake sequence (each flag in square brackets):

    1. SYN (seq=0, win=64240)

    2. SYN-ACK (seq=0, ack=1)

    3. ACK (seq=1, ack=1) → connection ESTABLISHED

Header Anatomy (open TCP subtree)

  • Source/Destination Ports (process-to-process comms)

  • Sequence Number (Wireshark shows relative; real ISN is random 32-bit value e.g.

    2638011052)

  • Acknowledgment Number

  • Data Offset & Flags (URG, ACK, PSH, RST, SYN, FIN)

  • Window Size (buffer space remaining)

  • Options (e.g.

    MSS, Window Scale, SACK-Permitted, Timestamps)

Bulk Data Transfer Observation

  • Multiple outgoing segments with PSH, ACK; sizes approximately 2950 B

  • Several outstanding packets in flight before first ACK arrives → illustrates pipelining

  • ACKs cumulative; each acknowledges highest contiguous seq received

  • Window field may shrink (receiver’s buffer filling) but rarely zero on good wired link

Handling Loss / Congestion (Second Trace with Tweaked Server)

  • Coloured indicators:

    • Black row: retransmission, duplicate ACK, window full

    • Red row: RST (connection reset)

  • Events seen:

    • Duplicate ACKs (receiver repeating same ack #)

    • TCP Window Full → sender must pause

    • Out-of-Order segment accepted & reordered by stack

    • Retransmission when ACK not received within RTT

    • Graceful teardown: FIN, ACK handshake (absent in keep-alive case)

    • Forced abort: RST flag (application or severe state confusion)

Visualisation Tools

  1. Statistics → TCP Stream Graph → Time-Sequence (Stevens)

    • Y-axis = seq #, X-axis = time

    • Slanted lines: steady data flow; vertical resets: fast re-send burst

    • Flat plateau indicates sender idle / waiting for ACK or window reopen

  2. Statistics → TCP Stream Graph → Sequence Trace (shows absolute vs relative)

  3. Statistics → Flow Graph (ladder diagram)

    • Columns = endpoints, rows = messages with direction arrows, ports, flags, windows

Practical Wireshark Tips & Shortcuts

  • Filter basics:

    • udp, tcp, ip.addr==192.0.2.1, tcp.stream eq 4

  • Colour coding (customisable): green = HTTP, purple = encrypted, red/black = problems

  • Click any field inside middle pane to highlight corresponding hex octets in bottom pane

  • Copying files between host ↔ VM: right-click → Copy/Paste; useful for assessment PCAPs

Assessment & Admin Reminders

  • Assessment 1 (quiz) covers Weeks 1–2; due Friday

    • 3 attempts allowed; highest mark kept

    • Self-service 3-day extension (no docs); longer extension requires evidence

    • If extension granted but StudyDesk date not updated → email lecturer/support

  • When using VM:

    • Always Shutdown VM from portal (avoid resource waste)

    • If lacking local Wireshark, download PCAP via VM browser or copy from host as shown

Looking Ahead

  • Next week: Topic 4 – Network Layer

    • IPv4/IPv6 addressing concepts, sub-netting, routers

    • First hands-on with GNS3 topology inside VM; combined with Wireshark captures

Key Concept Comparisons

Ethical & Practical Implications Discussed

  • Disabling checksum validation trades reliability for speed; acceptable for tiny, idempotent queries like DNS but not for critical finance data

  • Wireshark allows deep inspection of unencrypted UDP payload (privacy considerations); encrypted RTP/QUIC obscures content

  • Server overload demo highlights importance of capacity planning; TCP’s congestion control masks some issues but application-layer still fails (504 Gateway Timeout)

Formulas / Numerical Facts Highlighted

  • UDP header length: 4 fields x 2 bytes = 8 B

  • IP Protocol Numbers: UDP=17, TCP=6

  • Typical Ethernet MTU: 1500 B → DNS approximately 50 B fits comfortably

  • Window field shows free buffer space in bytes (e.g.

    65280)

  • Relative Seq/Ack numbers start at 0 but map to 32-bit ISN chosen uniformly at random