Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
OMPING(8)		FreeBSD	System Manager's Manual		     OMPING(8)

     omping -- test IP multicast

     omping [-46CDEFqVv] [-c count] [-i	interval] [-M transport_method]
	    [-m	mcast_addr] [-O	op_mode] [-p port] [-R rcvbuf] [-r rate_limit]
	    [-S	sndbuf]	[-T timeout] [-t ttl] [-w wait_time] remote_addr...

     The omping	is program which uses User Datagram Protocol to	determine if
     computer is able to send and/or receive IP	unicast	and multicast or
     Broadcast packets from the	network. It's designed to be used in very sim-
     ilar way as ping(8) and also has some features of the fping(8) command.
     Where ping(8) and omping differ is	in who replies.	In ping(8) replies are
     sent by the operating system and with omping another instance of omping
     sends the reply. This mean	that omping must be running on all computers
     to	test sending/receiving IP multicast/broadcast.	Its arguments are as

     -4	     Force usage of IPv4.

     -6	     Force usage of IPv6.

     -C	     Display continuous	statistics for every reply message.

     -D	     Disable packet duplicate detection. Option	is default for inter-
	     val 0.

     -E	     Default behaviour when every client is in stop state is to	exit.
	     This may happen if	all server sends stop message or if count
	     query messages was	sent. This option changes default behaviour
	     and omping	doesn't	quit automatically.

     -F	     Allow entering of arguments which are not allowed or not recom-
	     mended by the specification. This is typically the	interval pa-
	     rameter. This option may be used multiple times.

     -q	     Quiet output. Nothing is displayed	except state changes and sum-
	     mary. Option can be used twice and	then only summary is dis-

     -V	     Display version and quit. Option can be used twice	and then re-
	     mote version is displayed.

     -v	     Set level of verbosity. Parameter can be used multiple times to
	     achieve higher verbosity.

     -c	count
	     Number of request packets to send to each target. After sending
	     count query messages, given client	is put to stop state and it is
	     no	longer sending query messages.

     -i	interval
	     Wait interval seconds between sending each	request	packet.	Float
	     values are	supported in millisecond precision.  It's possible to
	     set there 0 with meaning that packets are sent ether after	previ-
	     ous unicast reply is received or after 1 millisecond, depending
	     on	which of these intervals is smaller. The default is to wait
	     for one second between each packet.

     -M	transport_method
	     Set transport method to use. This can be asm for Any-source Mul-
	     ticast, ssm for Source-specific Multicast and ipbc	for IP Broad-

     -m	mcast_addr
	     Multicast or broadcast address to listen on for multicast/broad-
	     cast answer messages.  Default is for IPv4 and
	     ff3e::4321:1234 for IPv6 multicast, or broadcast address of local
	     interface for Broadcast.

     -O	op_mode
	     omping can	be running in three different modes. Default and rec-
	     ommended mode for quick testing is	normal mode, when omping be-
	     haves like	client and server together. It sends queries and is
	     able to respond them.  Finally the	client mode sends queries, but
	     never respond to other nodes.

     -p	port
	     Port to bind and listen on	for both unicast and multicast/broad-
	     cast messages. Default is 4321.

     -R	rcvbuf
	     Set socket	rcvbuf.	Minimum	value for this option is 2048. If not
	     specified,	rcvbuf is not changed and default OS provided value is

     -r	rate_limit
	     Rate limit	interval between two query messages to rate_limit sec-
	     onds. Default value is same as interval given by -i option. Rate
	     limiting can be disabled by specifying 0 as value.	Rate limiting
	     is	by default disabled for	-i with	0 seconds.

     -S	sndbuf
	     Set socket	sndbuf.	Minimum	value for this option is 2048. If not
	     specified,	sndbuf is not changed and default OS provided value is

     -T	timeout
	     Specify a timeout,	in seconds, before omping exits	regardless of
	     how many packets have been	received.

     -t	ttl  Time-To-Live of sent packets.

     -w	wait_time
	     after omping is stopped (by sending SIGINT	or timeout expire) it
	     is	moved to special state when no queries are made	and server an-
	     swer all queries by server	response (stop message). This makes
	     possible to give correct (unbiased) result	of lost	packets	on
	     other nodes. Default is 3 times interval or 1 second, depending
	     which one is larger. Also special value 0 can be used to not wait
	     at	all or -1 which	means wait forever (this can be	still termi-
	     nated by sending SIGINT).

	     List of addresses to test.	One of them must be address of local
	     internet interface. This local address is used for	bind and lis-
	     tening on for unicast packets. It's also used to determine	which
	     interface should be used for sending multicast/broadcast replies.

     Program is	normally terminated by SIGINT. After signal receive summary is
     displayed.	You can	also display summary during running by sending SIGINFO
     or	SIGUSR1	signal.

     When using	omping for fault isolation, it should first be run against lo-
     cal internet interface only, to verify that the local network interface
     is	up and running,	and firewall is	correctly configured. This mode	is
     available by entering only	local IP address.

     The omping	utility	exits 0	on success, and	>0 if an error occurs.

     The following commands and	output is a typical way	how to find-out	and
     solve network problems using omping. In this situation, we	have 3 comput-
     ers named node-01,	node-02	and node-03 with IP addresses - Let's run the following command on all of them.

	   $ omping node-01 node-02 node-03

     on	all of nodes we	should be able to seen similar output

	   node-01: waiting for	response msg
	   node-03: waiting for	response msg
	   node-01: joined (S,G) = (*,,	pinging
	   node-03: joined (S,G) = (*,,	pinging
	   node-01: unicast, seq=1, size=69 bytes, dist=0, time=0.192ms
	   node-01: multicast, seq=1, size=69 bytes, dist=0, time=0.284ms
	   node-03: unicast, seq=1, size=69 bytes, dist=0, time=0.279ms
	   node-03: multicast, seq=1, size=69 bytes, dist=0, time=0.360ms

     The first two lines tell us, that node-02 (actual node) is	waiting	for a
     response message from node-01 and node-03.	The second two lines contain
     information, that we were successfully able to send an init message and
     also received a response message from remote nodes. Both of these mes-
     sages are unicast,	so we are able to send and receive unicast messages on
     a given port. If all of nodes are up and omping is	running	on all of
     them, but we are not able to receive a response message, it's time	to
     check connectivity	between	nodes. First make sure that you	are able to
     ping(8) them. If so, make sure that your firewall allows port 4321	to re-
     ceive udp packets.

     The next line tells us that we were able to receive a 69 byte unicast re-
     sponse message from node-01, with a sequence number of 1. The distance
     between the computers is 0	so they	are on the same	link net. Time between
     send and receive packet was 0.192 ms, that	is also	the current average
     time and lastly there were	no lost	packets.

     The 6th line tells	us the same information	as the previous	one, but the
     received message is a multicast message. It means,	that multicast is
     probably well configured.

     The 7th and 8th lines are same as previous	two one	but for	node-03.

     If	the node is able to receive unicast packets, but never multicast, it
     means that	multicast configuration	is incorrect. It's recommended to turn
     off your firewall.	If multicast packets start to arrive, great. If	not,
     the problem is hidden in the switches/routers between the nodes. Contact
     your system administrator to allow	multicast traffic on the switch	or

     omping is terminated by SIGINT signal (CTRL-c). Summary statistics	are

	   node-01: unicast, xmt/rcv/%loss = 18/18/0%, min/avg/max/std-dev =
	   node-01: multicast, xmt/rcv/%loss = 18/18/0%, min/avg/max/std-dev =
	   node-03: unicast, xmt/rcv/%loss = 21/21/0%, min/avg/max/std-dev =
	   node-03: multicast, xmt/rcv/%loss = 21/20/4%	(seq>=2	0%),
	   min/avg/max/std-dev = 0.347/0.388/0.575/0.055

     Last line has additional information (seq>=2 %0) which means, that	after
     receiving first multicast packet with seq number 2, no other multicast
     packet was	lost. Because creating multicast tree is time consuming, it's
     pretty normal to lost first few multicast packets.	rcv field can also be
     formatted like

	   node-01: unicast, xmt/rcv/%loss = 3/3+1/0%, min/avg/max/std-dev =

     This means, that 1	duplicate packet was received. It's possible to	find
     out duplicate packet by looking to	output and find	line which has follow-
     ing format

	   node-01: unicast, seq=2 (dup), size=69 bytes, dist=0, time=0.469ms

     fping(8), ping(8)

     omping uses Internet-Draft	draft-ietf-mboned-ssmping-08 as	underlaying
     protocol and tries	to be as compliant as possible.

     The omping	utility	was written by Jan Friesse <>.

     -	 Some OSes may not have	support	for receiving TTL from packet.	omping
	 then cannot provide distance information.

     -	 Some OSes may not provide information about packet receive. Less pre-
	 cise actual time is then used.

     -	 omping	highly depends on precise poll(2) and gettimeofday(3) func-
	 tions.	If OS doesn't provide at least milliseconds precision, results
	 may be	incorrect.

FreeBSD	13.0			 Jun 22, 2011			  FreeBSD 13.0


Want to link to this manual page? Use this URL:

home | help