2

From the multicast howto:

IP_ADD_MEMBERSHIP.

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)
legoscia
  • 298
  • 1
  • 3
  • 14
Karoly Horvath
  • 334
  • 1
  • 4
  • 14

2 Answers2

3

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 239.100.100.100 Where 239.100.100.100 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.

mbrownnyc
  • 1,825
  • 8
  • 30
  • 50
  • "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](http://packeth.sourceforge.net/#screenshots) 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
  • [Promiscuous mode](http://www.tcpdump.org/faq.html#q7) should allow tcpdump to see all packets that arrive at the interface. I think you've gotten too deep in your analysis on how to do this. [Stop pondering theory and test some actions.](http://blog.serverfault.com/post/eating-our-vegetables/) – mbrownnyc Oct 28 '11 at 15:41
  • I tested `iperf`, I cannot specify which interface to use so it sends the multicast joins on the wrong physical interface (no, I don't want to set up a route table entry for that)... couldn't test the rest, as usual, I'm waiting for the netadms :/ – Karoly Horvath Oct 31 '11 at 18:02
  • You can't send a packet to a place without a route to that place. Since your multicast group is "living" on infrastructure interconnected to your server via, say eth4, the network stack would need to know where to send the packet with the IGMP JOIN. Otherwise, you can't join the multicast group. It's quite clear you're a super human sysadmin; but it seems that you're perspective is very complex. This is simple networking concept. You must add a route for your network stack to know where to route a packet. Otherwise, it will send it to the router who's the designated pathway to 0.0.0.0. – mbrownnyc Oct 31 '11 at 18:31
  • O'rly? search for IP_ADD_MEMBERSHIP. here is one good source: http://tldp.org/HOWTO/Multicast-HOWTO-6.html (it was in my question BTW) – Karoly Horvath Oct 31 '11 at 19:12
  • Sorry I'm not a developer. Maybe you would be better served inquiring on stackoverflow or programmers.stackexchange.com. I didn't realize you were re-writing the network stack or concerned with relying on your own API to interface directly with it. I strongly suggest that you just add the route statement and see what happens. Seems reasonable? – mbrownnyc Oct 31 '11 at 19:24
  • *sigh*.. it's not re-writing. it's pretty natural that you can select the interface for (in/out) multicast traffic, as it is valid address on multiple interfaces. note: thanks for you help! – Karoly Horvath Oct 31 '11 at 19:27
  • If you need a very specific feature set, and you do appear to be quite comfortable, maybe write your own (JOINer)? It seems like a reasonable feat given your knowledge. When I needed an IGMP v2 all-hosts querier written, the dev chose to use python to craft the packet and send it out, relying on the available py modules. It wasn't complex or difficult. iperf isn't the tool, but look into many more packet crafting tools. And, as I said, a port mirror/span may be an option if you don't know what the groups are. This will definitely have the traffic arrive to the wire.... – mbrownnyc Oct 31 '11 at 19:51
  • Obviously, this is a very interesting issue to me, so please post an response if you figure something. – mbrownnyc Oct 31 '11 at 19:51
  • Looks like I've finally come across a similar questions to yours with [ntop and ipt_NETFLOW](https://sourceforge.net/tracker/?func=detail&aid=3464029&group_id=232613&atid=1088104). I am now curious if you were looking to build something similar to that of [the PF_RING project](http://www.ntop.org/products/pf_ring/). – mbrownnyc Dec 23 '11 at 16:11
  • And your solution is to patch the kernel, or, much more easily, create a bridge between a dummy NIC and the real NIC, place the real NIC into promisc mode. See: http://ipt-netflow.git.sourceforge.net/git/gitweb.cgi?p=ipt-netflow/ipt-netflow;a=blob;f=README.promisc – mbrownnyc Dec 28 '11 at 16:40
  • hmm... http://www.computerworlduk.com/news/security/3333956/intrusion-detection-offered-as-cloud-package-by-metaflows/?olo=rss – mbrownnyc Feb 01 '12 at 15:29
1

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.