OMPING(8)						    BSD System Manager's Manual 						 OMPING(8)

NAME

     omping -- test IP multicast

SYNOPSIS

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

DESCRIPTION

     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 similar way as ping(8) and also has some features of the fping(8) com-
     mand.  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 follows:

     -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 interval 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 recommended by the specification. This is typically the interval parameter.
	     This option may be used multiple times.

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

     -V      Display version and quit. Option can be used twice and then remote 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 previous 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 Multicast, ssm for Source-specific Multicast and ipbc for IP Broadcast.

     -m mcast_addr
	     Multicast or broadcast address to listen on for multicast/broadcast answer messages.  Default is 232.43.211.234 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 recommended mode for quick testing is normal mode, when omping behaves
	     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/broadcast 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
	     used.

     -r rate_limit
	     Rate limit interval between two query messages to rate_limit seconds. Default value is same as interval given by -i option. Rate lim-
	     iting 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
	     used.

     -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 answer
	     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 terminated by sending SIGINT).

     remote_addr
	     List of addresses to test. One of them must be address of local internet interface. This local address is used for bind and listening
	     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 local internet interface only, to verify that the local network inter-
     face is up and running, and firewall is correctly configured. This mode is available by entering only local IP address.

EXIT STATUS

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

EXAMPLES

     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 com-
     puters named node-01, node-02 and node-03 with IP addresses 192.168.1.101 - 192.168.1.103. 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) = (*, 232.43.211.234), pinging
	   node-03: joined (S,G) = (*, 232.43.211.234), 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 con-
     tain information, that we were successfully able to send an init message and also received a response message from remote nodes. Both of
     these messages 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 receive udp packets.

     The next line tells us that we were able to receive a 69 byte unicast response message from node-01, with a sequence number of 1. The dis-
     tance 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 cur-
     rent 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 router.

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

	   node-01: unicast, xmt/rcv/%loss = 18/18/0%, min/avg/max/std-dev = 0.177/0.301/0.463/0.073
	   node-01: multicast, xmt/rcv/%loss = 18/18/0%, min/avg/max/std-dev = 0.193/0.335/0.547/0.090
	   node-03: unicast, xmt/rcv/%loss = 21/21/0%, min/avg/max/std-dev = 0.272/0.299/0.327/0.017
	   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 multi-
     cast 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 = 0.294/0.299/0.305/0.006

     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
     following format

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

SEE ALSO

     fping(8), ping(8)

STANDARDS

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

AUTHORS

     The omping utility was written by Jan Friesse <jfriesse@redhat.com>.

BUGS

     -	 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 precise actual time is then used.

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

BSD
								   Jun 22, 2011 							       BSD