Wireshark can’t actually decode UDP datagrams in the way you might think; it displays the raw bytes and any protocol dissectors it finds, but the UDP header itself is just a simple structure.
Let’s see UDP in action. Imagine a simple DNS query. A client on your local network (say, IP 192.168.1.100, port 54321) wants to know the IP address for example.com. It sends a UDP datagram to the DNS server (often 8.8.8.8, port 53).
192.168.1.100:54321 -> 8.8.8.8:53 UDP Length: 74
In Wireshark, you’d see this. The "Length: 74" means the UDP header (8 bytes) plus the DNS payload (66 bytes) make up the total 74 bytes of the UDP segment.
This UDP datagram is then encapsulated within an IP packet. The IP packet header will contain the source and destination IP addresses (192.168.1.100 and 8.8.8.8), and the protocol field will be set to 17 (UDP).
IP 192.168.1.100 -> 8.8.8.8 Protocol: UDP (17)
The UDP header itself is remarkably simple:
- Source Port (16 bits):
54321(which Wireshark displays as54321) - Destination Port (16 bits):
53(which Wireshark displays asdomain) - Length (16 bits):
74(the UDP header + payload) - Checksum (16 bits): A value used for error checking.
The surprising thing about UDP is how little it guarantees. It’s a "fire and forget" protocol. There’s no connection setup, no acknowledgment of receipt, no guarantee of order, and no built-in retransmission. It’s just raw data pushed across the network. This makes it incredibly fast but also unreliable.
To capture UDP traffic in Wireshark, you’ll typically use a capture filter. If you want to see DNS traffic to Google’s servers, you might use:
udp port 53 and host 8.8.8.8
This tells Wireshark to only capture packets that are UDP, destined for port 53, and coming from or going to the IP address 8.8.8.8.
Once captured, Wireshark’s display filter can be used to narrow down what you see. If you’ve captured all UDP traffic on your network interface, you can then apply a display filter like:
dns
Wireshark has a DNS dissector that understands the DNS packet structure after the UDP header. It automatically recognizes UDP traffic on port 53 as DNS and parses the payload accordingly, showing you the query details, response, etc. For other UDP-based protocols, Wireshark has dissectors for protocols like SNMP (snmp), TFTP (tftp), or even custom applications if you know their port and have a dissector for them.
The "Length" field in the UDP header is crucial for the IP layer to know how many bytes belong to the UDP segment. When an IP packet with protocol 17 arrives, the IP layer reads the UDP header, checks the length, and then passes that many bytes (header + payload) to the UDP layer. The UDP layer then uses the destination port to figure out which application on the host should receive the payload.
If you were to manually craft a UDP packet, you’d set the source and destination ports, calculate the length (including the 8-byte UDP header), and compute the checksum. The checksum calculation is a bit involved; it involves a pseudo-header and the UDP data, and if it’s zero, it means no checksum was computed (which is allowed in IPv4, though often discouraged).
The UDP header is fixed at 8 bytes. The "Length" field specifies the total size of the UDP datagram, including the header itself. So, if the payload is 66 bytes, the UDP length will be 66 + 8 = 74 bytes.
The real power of Wireshark is its ability to dissect the payload after it has identified the UDP protocol based on the IP header’s protocol field and the UDP header’s port numbers. It doesn’t "decode" UDP itself so much as it uses UDP’s simplicity to pass other, more complex protocols along.
The next step after understanding UDP is to look at TCP, which provides the reliability that UDP lacks.