Ever since I started working with multicast back in the early 2000's, I've had to make my own tools. There weren't that many useful ones available, at least not in the Open Source space where I worked.
The first tool made, mcjoin,
was based on an example an IBM'er had made public. I used that, the
standard ping(1) tool, and tcpdump(1), to check my multicast flows.
It served me well and it evolved into a nice stand-alone tool with both
IPv6 support and graphic (well) presentation view.
However, when scripting tests I often found myself always back using my basic tools again. So, having learned a lot from mcjoin (and quite a few other multicast tools along the way), I decided to create something I could actually use when writing tests for my other projects (mrouted, SMCRoute, pimd, pimd-dense, and pim6sd). The result is mping :-)
I always recommend people use released tarballs instead of cloning the latest from GitHub. Those are supported releases, if you check out a GIT branch you may get a work-in-progress build that does not satisfy your needs, and is also very difficult to support by the author.
cd ~/Downloads
wget https://github.com/troglobit/mping/releases/download/v2.0/mping-2.0.tar.gz
cd ~/src
tar xf ~/Downloads/mping-2.0.tar.gz
cd mping-2.0/
make
sudo make install
The resulting program is by default installed in /usr/local/bin/mping
so make sure you have /usr/local/bin in your $PATH environment
variable. Usually you set this up in your ~/.bashrc, but YMMV.
Like its sibling mcjoin, the mping program comes with both the sender
and receiver (or reflector) built-in. Since multicast is usually one-way,
and operating systems (unless they are routers) don't reply to multicast
ICMP (ping) messages, we need to have an mping instance running at both
ends of a stream. Effectively emulating a sender and a receiver.
mping has a few defaults built-in that can seem confusing at first, but
what you need to get going is:
- Between which two systems should I run the test?
Take note of the system names and any login credentials you might need. - What interfaces on my two systems are connected to the network?
Take note of the interface names. - Is there a/many multicast router(s) in between the two systems?
If so, you will need to set the TTL-t NUM_ROUTERS+1on both mpings
When you've figured this out you can start playing with mping. For a
continuous run all you need is to provide the interface and, optionally,
the multicast group.
mping -r -i eth0
mping -s -i eth0
Continous operation is not that exciting, also mcjoin usually does a better job here. When scripting you set up boundarys; a defined set of rules, e.g. number of packets to send, expected number of packets to receieve, with an optional timeout (receiver). mping supports all that and if it fails to perform the operation it returns an error code which you can use in your scripts.
mping -qr -t 3 -c 10 -W 30 -i eth0 225.3.2.1
mping -s -t 3 -c 10 -w 15 -i eth0 225.3.2.1
The receiver is set up to reflect 10 (count) packets, exiting after a timeout of 30 sec of no activity. We're not super interested in any return value from the receiver at this point, what's interesting is the sender.
The sender is what we want to check the return code of. It expects 10 (count) packets to be sent and received. It waits for up to 15 seconds for the last packet(s) to arrive before giving up, and then returning non-zero exit.
So, for example, to check the result of the mping sender, when it runs in a network namespace:
if ! nsenter --net="$left" -- ./mping -s -t 3 -c 10 -w 15 -i eth0 225.1.2.3; then
echo "mping: failed, did not receive expected number of multicast packets (10)"
exit 1
fi