Wireshark Multicast Traffic: Decode Group Packets (2026)

Multicast traffic isn’t actually "sent" to a specific IP address; it’s sent to a group address that any number of devices can opt into listening to.

Let’s see this in action. Imagine a network where a server is sending out stock price updates to a multicast group 239.1.1.1 on port 5000. A client application on another machine wants these updates.

First, the client needs to join the multicast group. This is typically done by the operating system’s network stack, often triggered by the application using socket options like IP_ADD_MEMBERSHIP. This signals to the local network interface card (NIC) to start listening for packets destined for 239.1.1.1.

Here’s a simplified view of what happens on the wire when the server sends a packet:

Frame 1:
    Ethernet II, Src: 00:0c:29:c8:1a:0a, Dst: 01:00:5e:01:01:01
    Internet Protocol Version 4, Src: 192.168.1.100, Dst: 239.1.1.1
    User Datagram Protocol, Src Port: 5000, Dst Port: 5000
    ... (application data)

Notice the destination MAC address: 01:00:5e:01:01:01. This is the standard multicast MAC address format. The first three bytes (01:00:5e) are a prefix indicating a multicast MAC. The next three bytes are derived from the IP multicast group address (239.1.1.1). Specifically, the IP address’s lower 23 bits are mapped to the lower 23 bits of the MAC address. For 239.1.1.1:

• 239 in binary is 11101111. The first bit (the 1) is ignored for multicast MAC conversion, so we use 1101111.
• 1 in binary is 00000001.
• 1 in binary is 00000001.
• 1 in binary is 00000001.

Concatenating these gives us 1101111.00000001.00000001.00000001, which is 0x6F 0x01 0x01 0x01. Prepending the multicast prefix 01:00:5e results in 01:00:5e:6f:01:01.

Wait, the example MAC was 01:00:5e:01:01:01. Let’s re-evaluate the IP-to-MAC mapping: The IP multicast address 239.1.1.1 has the binary representation: 11101111.00000001.00000001.00000001

The rule is:

1. Take the IP multicast address.
2. Discard the first bit of the first octet if it’s 1 (which it is for 224.0.0.0 to 239.255.255.255). So, 11101111 becomes 1101111.
3. Take the remaining 23 bits of the IP address.
4. Prepend the MAC address prefix 01:00:5E.
5. The last 24 bits of the MAC address are derived from the last 24 bits of the IP address.

So for 239.1.1.1: IP: 11101111.00000001.00000001.00000001 Discard first bit of first octet: 1101111.00000001.00000001.00000001 Take last 23 bits: 101111.00000001.00000001.00000001 (This is incorrect, it should be the lower 23 bits of the entire IP address after the first bit of the first octet is removed).

Let’s correct the IP to MAC mapping for 239.1.1.1: IP Address: 239.1.1.1 Binary: 11101111.00000001.00000001.00000001

The multicast MAC address is formed by taking the MAC prefix 01:00:5E and appending the lower 24 bits of the IP multicast address. The lower 24 bits of 239.1.1.1 are 00000001.00000001.00000001. So the MAC address is 01:00:5E:01:01:01. This matches the example.

In Wireshark, when you capture this traffic, you’ll see the standard Ethernet and IP headers. The key is understanding that the destination IP 239.1.1.1 is a group address, not a single host. To see the payload of multicast packets in Wireshark, you don’t need to do anything special if the packet is already being captured on a machine that has joined the group. Wireshark simply displays what it sees on the network interface.

However, if you want to filter to see only multicast traffic destined for a specific group, you can use display filters. For example, to see all traffic for the 239.1.1.1 group:

ip.dst == 239.1.1.1

Or, if you want to see traffic sent to any multicast group (which starts from 224.0.0.0 to 239.255.255.255):

ip.dst >= 224.0.0.0 and ip.dst <= 239.255.255.255

Or, using the mcast display filter keyword:

mcast

This filter will show all IP packets where the destination IP address is in the multicast range.

The system’s behavior is driven by IGMP (Internet Group Management Protocol). When a host wants to join a multicast group, it sends an IGMP "Membership Query" message to the local router. The router then knows to forward multicast traffic for that group to the subnet containing the host. If no hosts on a subnet are members of a particular multicast group, the router will stop forwarding traffic for that group to that subnet.

A common pitfall is assuming multicast traffic is like unicast where you can just sniff it from any point on the network if you capture it. While Wireshark will capture the packet if it hits your interface, whether that packet reaches your interface depends on your machine’s IGMP membership and the network’s multicast routing configuration. If your machine hasn’t joined the group, or if the network infrastructure (routers, switches) isn’t configured for multicast and IGMP snooping, you simply won’t see the packets on your interface, even if they are being sent.

The most surprising thing about multicast is how much of the "joining" and "leaving" process is managed by the operating system’s network stack and IGMP, rather than explicit application requests being broadcasted for every single packet. The application tells the OS once, and the OS handles the ongoing signaling with the network.

Consider the IGMP snooping feature on managed switches. Instead of flooding all multicast traffic to every port, a switch with IGMP snooping enabled will listen to IGMP messages. It builds a table mapping multicast groups to specific switch ports where interested receivers are connected. This dramatically reduces unnecessary traffic on the network, preventing a single multicast stream from overwhelming devices that don’t care about it. Without IGMP snooping, a multicast stream would be sent to all ports on a VLAN, regardless of whether any hosts on those ports have joined the group.

Understanding the multicast TTL (Time To Live) is crucial for controlling the scope of multicast packets. When a sender sends a multicast packet, it assigns a TTL value. This TTL is decremented by each router it passes through. If the TTL reaches zero before the packet reaches its destination, the packet is dropped. This mechanism prevents multicast traffic from endlessly looping on the network. Common TTL values are:

• 1: Restricted to the local subnet.
• 16: Restricted to the site or organization.
• 32: Restricted to the region.
• 64: Restricted to the continent.
• 255: Unrestricted, can traverse the internet (though most ISPs filter this).

If you’re trying to send multicast traffic across routers and it’s not arriving, checking the TTL set by the sender and the hop count to the destination is a primary diagnostic step.

The next concept you’ll likely encounter is how to reliably send data over multicast, which leads to protocols like PGM (Pragmatic General Multicast) or application-level acknowledgments, as UDP (the typical transport for multicast) offers no delivery guarantees.