asmping works pretty much the same way, except that the group to use is specified on the command line. It will then join this group, and in the requests it will tell ssmpingd which group to respond to. In order to partly prevent ssmpingd being told to send to random groups (which could be used as some sort of attack), the last octet of an IPv4 group address is forced to end with 234, and the last 4 octets of an IPv6 group address to 4321:1234.
$ ssmping ssmping.uninett.no ssmping joined (S,G) = (2001:700:1:7:211:d8ff:fe8f:1f9b,ff3e::4321:1234) pinging S from 2001:630:d0:111:250:fcff:fe6a:42b3 unicast from 2001:700:1:7:211:d8ff:fe8f:1f9b, seq=0 dist=20 time=57.106 ms unicast from 2001:700:1:7:211:d8ff:fe8f:1f9b, seq=1 dist=20 time=56.929 ms unicast from 2001:700:1:7:211:d8ff:fe8f:1f9b, seq=2 dist=20 time=62.466 ms multicast from 2001:700:1:7:211:d8ff:fe8f:1f9b, seq=2 dist=12 time=65.706 ms unicast from 2001:700:1:7:211:d8ff:fe8f:1f9b, seq=3 dist=20 time=57.226 ms multicast from 2001:700:1:7:211:d8ff:fe8f:1f9b, seq=3 dist=12 time=59.455 ms unicast from 2001:700:1:7:211:d8ff:fe8f:1f9b, seq=4 dist=20 time=56.090 ms multicast from 2001:700:1:7:211:d8ff:fe8f:1f9b, seq=4 dist=12 time=58.956 ms --- 2001:700:1:7:211:d8ff:fe8f:1f9b ssmping statistics --- 5 packets transmitted, time 4744 ms unicast: 5 packets received, 0% packet loss rtt min/avg/max/std-dev = 56.090/57.963/62.466/2.296 ms multicast: 3 packets received, 40% packet loss 0% loss since first multicast packet received (after 2067 ms) rtt min/avg/max/std-dev = 58.956/61.372/65.706/3.077 ms $
This shows that it took about 2s for the multicast tree to be established. The first two multicast packets got lost. It also shows the round-trip time for the unicast and multicast (note that the multicast is really unicast in one direction). This shows here that there is roughly 3-4ms additional delay for the multicast packets. It also shows that the unicast packets have travelled 20 hops, while multicast only 12 hops. This shows that there probably is some tunneling for multicast. This is measured by having ssmpingd send all packets with a TTL/hop-limit of 64.
You may also obtain current sources from subversion. To check out the sources, do "svn co https://svn.testnett.uninett.no/ssmping". There is also a web interface.
Binaries for Windows XP and Vista are also available. You can get them zipped or individually: zip - ssmping - asmping - ssmpingd - mcfirst
Release of ssmping-0.8.1. The main change from 0.8 is the Windows code, which now also supports IPv6 SSM on Vista. This means you now can do IPv6 SSM on Vista. Also asmping is now available for Windows.
Binaries of the ssmping and asmping clients are available for Windows XP
and Vista. Note that Vista supports IPv6 SSM, while Windows XP does not.
Windows ssmping client - Windows asmping client
Release of ssmping-0.8. The only new feature is ASM support, but large parts of the code have been rewritten. ASM is supported by a separate client called asmping. ssmpingd has been extended to serve as a server for both ASM and SSM.
ssmping-0.7 has no new functionality. A minor bug related to the statistics output has been fixed. The main difference is that this source supports both UNIX and Windows systems. There are a number of changes in the code, but the intention is that it should work as 0.6. It needs more testing on Windows. There are also some limitations on Windows. It does not display number of hops, and also the RTT time granularity is not so good. If you know how to fix this, please let me know. For Windows there is also a binary available.
Release of ssmping-0.6. The only change is that the client now has an option "-I" for specifying which interface to join. On some broken systems ssmping will fail to join the multicast channel unless interface is specified.
Release of ssmping-0.5. The client now prints out statistics, mostly similar to standard ping. The server is identical to 0.3 (and 0.4).
Release of ssmping-0.4. The client now has options for forcing IPv4 or IPv6, and also an option for number of requests to send. The server is identical to 0.3.
Release ssmping-0.3 should work properly on Solaris. To use ssmping the system must support SSM. I believe you need a patched Solaris 10 for that. Also the latest server now makes sure it sends responses from the address it receives queries on. The client expects this.
Previous versions 0.2 and 0.1 are also available.
Note that the multicast beacon dbeacon can also act as an ssmping server (but only SSM, not with asmping). For some additional IPv6 ssmping servers, see this beacon matrix. At the bottom of the page the beacon clients are listed. There is a column for ssmping servers there.