Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

From the multicast howto:


Recall that you need to tell the kernel which multicast groups you are interested in. If no process is interested in a group, packets destined to it that arrive to the host are discarded.

If you don't do that, you won't see those packets with tcpdump.

  • Is it possible to subscribe to all multicast traffic so I can do a tcpdump for all existing traffic? I would think IGMP doesn't allow this, so probably not.. but maybe you can configure a switch to still send all multicast traffic. Is that possible?
  • Is it possible to do subscription (for a specific IP) with a command line tool? (note: I know how to do this in C.. but would prefer to use an existing tool and not compile a separate program for this)
share|improve this question

It depends on your multicast infrastructure: For instance, you could have many multicast routers, and various rules set on your switches (making subscriptions static, or dynamic, or even banned on certain ports/nodes).

But, if you want to subscribe to a multicast group... Just subscribe. Send an IGMP JOIN packet across some infrastructure, which obviously has IGMP snooping enabled. You can generate an IGMP packet with a variety of tools.

Taking a step to a higher level, use iperf to subscribe to any multicast group. If your network infrastructure isn't too complex, and if you are "allowed" to subscribe to any multicast group, then use the following:

iperf -s -u -B Where is your multicast group address.

tcpdump simultaneously to get a detailed report.

Note that I believe iperf only supports IGMP v1 and v2. If you want to craft an IGMP v3 JOIN packet, it shouldn't be too hard to write a program, as you stated. But there would be a lot more tools out there that would probably do the same.

share|improve this answer
"You can generate an IGMP packet with a variety of tools.". What are these tools? I obviously don't want to manually assemble a packet.. iperf looks nice. What else can you use? – Karoly Horvath Oct 28 '11 at 13:21
Also, as I said, if possible, I want to get all available multicast traffic. There are a lot of traffic and I don't know all the addresses. – Karoly Horvath Oct 28 '11 at 13:24
Other tools like the large count of packet generation tools, where you craft the packet with a nice front end for instance. iperf would serve much better, but doesn't support IGMP v3 (I don't think). You can't just "get all multicast traffic." That's the exact opposite purpose of multicast. What you're asking for now sounds like more of a job for port mirroring/spanning on a switch trunk port/point, where you know the multicast traffic traverses. Sniff at the target port, filtering for multicast packets, and you've got your answer. – mbrownnyc Oct 28 '11 at 13:32
And, by the way, you might be able to leverage the API your apps are using to send and receive multicast to compile a membership list in a centralized location that you could, in turn, subscribe to at the higher level (other than physical, layer 2 as the suggestion to mirror traffic). – mbrownnyc Oct 28 '11 at 13:53
.. so I set up the switch so it forwards all the multicast traffic.. now it arrives at my linux box, where the kernel will drop all those packets because apps haven't subscribed for the specific multicast addresses.. or have I misunderstood something? – Karoly Horvath Oct 28 '11 at 15:10

The linked-to page of the multicast HOWTO doesn't say anything about tcpdump.

Tcpdump uses libpcap to capture network packets and, on Ethernet, libpcap supports both:

  • promiscuous mode, in which the network adapter delivers to the host every packet it sees, regardless of the destination address, and the network stack delivers every packet passing the filter to the capture mechanism, and

  • non-promiscuous mode, in which the network adapter delivers to the host unicast packets, broadcast packets, and multicast packets it's configured to deliver, and the network stack delivers all of those packets that pass the capture filter to the capture mechanism.

Tcpdump default to requesting promiscuous mode; in that mode, you'll even see unicast packets not sent to your host (as long as you're not on a switched network or are on a switched network but are plugged into a "mirror" port that gets all traffic).

If you pass tcpdump the -p flag, it will request non-promiscuous mode, in which case you'll only see the packets that your machine "should" get; in that case, if no process has registered an interest in a particular multicast group, you won't see packets sent to that group's multicast address, but, in that case, that's not a bug, that's a feature, as your machine isn't doing anything with those packets.

So if you want to see all packets (unicast packets to all hosts, multicast packets to all multicast addresses, and broadcast packets), run tcpdump (or Wireshark or whatever) in promiscuous mode and, if you're on a switched network, run on a "mirror port" or "SPAN port" or whatever the switch vendor calls it (if it supports "mirror ports").

See the Wireshark Wiki page on Ethernet packet capture for a lot of details on promiscuous mode and switched networks; the information on that page applies to all packet sniffers, including tcpdump, not just to Wireshark.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.