My best bet would be to use something like:
tcpdump -ieth0 -s96 -w traffic.dump 'ip or icmp or tcp or udp'
Where the "tricky" part will be to chose a correct value for the "-s" (snaplen) parameter (snaplen is the maximum length of the packet tcpdump will capture).
From the tcpdump man pages:
Snarf snaplen bytes of data from each
packet rather than the default of 68
(with NIT, the minimum is actually
96). 68 bytes is adequate for IP,
ICMP, TCP and UDP but may truncate
protocol information from name server
and NFS packets (see below). Packets
truncated because of a limited
snapshot are indicated in the output
with ``[|proto]'', where proto is the
name of the protocol level at which
the truncation has occurred. Note that
taking larger snapshots both increases
the amount of time it takes to process
packets and, effectively, decreases
the amount of packet buffering. This
may cause packets to be lost. You
should limit snaplen to the smallest
number that will capture the protocol
information you're interested in.
In this example i'm using 96 to be "almost" sure that I would capture 100% of ethernet+ip+(icmp || udp || tcp) header values.
In case your traffic have IP or TCP options (i.e. timestamps) and you want to also capture this info, then you will have to play with the snaplen parameter (i.e. increase/decrease it).
In case the length of the headers of your packet is less than snaplen, you may also capture part of the payload.
Finally, to read the traffic captured, I would use something like:
tcpdump -e -nn -vv -r traffic.dump
Where the important part is to use the "-e" option so you can get the ethernet headers printed.
This page gives you an idea about the size of the ethernet/tcp/udp headers under different circumstances and may help you to arrive to a "correct" value for the snaplen parameter.
I've used tcpdunp a fair bit but don't find it very easy so I use ngrep
which supports regex too.
ngrep -t -d eth3 '' broadcast
and ngrep -t -d eth3 '' multicast
should both put the interface into promiscuous mode and achieve the same thing.
I'm not suggesting that this is much different from what you're trying with tcpdump but in case for some reason it's misbehaving then ngrep is another tool on top of the Java tool to try.
Best Answer
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.