OMPING(8)

📦 version 0.0.4, in centos-stream 10, centos-stream 9, fedora 43, fedora 44

💖 OMPING(8) 💖

okay bestie, sit down, we're reading the manual page for omping — it lives in section 8 of the System Manager's Manual, which is the admin/daemon shelf, iykyk. It's literally ping's chaotic younger sibling and I'm obsessed. Let's go ✨

🌸 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 ✨

So omping is a program that uses User Datagram Protocol to figure out whether a 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 a very similar way as ping(8) and it also has some features of the fping(8) command. 💅

The way that ping(8) and omping differ is in who replies. With ping(8) the replies are sent by the operating system, and with omping another instance of omping sends the reply. This means — and this is the part you cannot skip, fr fr — that omping must be running on all the 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. This option is the default for interval 0.
  • -E — The default behaviour when every client is in stop state is to exit. This may happen if all servers send a stop message, or if count query messages were sent. This option changes that default behaviour, so 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. The option can be used twice, and then only the summary is displayed. 🤫
  • -V — Display version and quit. The option can be used twice, and then the remote version is displayed.
  • -v — Set level of verbosity. The 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, the 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 0 there, with the meaning that packets are sent either after the 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. The default is 232.43.211.234 for IPv4 and ff3e::4321:1234 for IPv6 multicast, or the broadcast address of the local interface for Broadcast. 📡
  • -O op_mode — omping can be running in three different modes. The 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 to them. And finally there's the client mode, which sends queries, but never responds 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. The minimum value for this option is 2048. If not specified, rcvbuf is not changed and the default OS provided value is used.
  • -r rate_limit — Rate limit the interval between two query messages to rate_limit seconds. The default value is the same as the interval given by the -i option. Rate limiting can be disabled by specifying 0 as the value. Rate limiting is by default disabled for -i with 0 seconds.
  • -S sndbuf — Set socket sndbuf. The minimum value for this option is 2048. If not specified, sndbuf is not changed and the 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 expiry) it is moved to a special state when no queries are made and the server answers all queries by server response (stop message). This makes it possible to give a correct (unbiased) result of lost packets on other nodes. The default is 3 times the interval or 1 second, depending on which one is larger. Also the special value 0 can be used to not wait at all, or -1, which means wait forever (this can still be terminated by sending SIGINT).
  • remote_addr — List of addresses to test. One of them must be the address of the 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. 📍

The program is normally terminated by SIGINT. After the signal is received, the summary is displayed. You can also display the summary during running by sending SIGINFO or SIGUSR1 signal. 🌈

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

🎀 EXIT STATUS 🎀

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

🔥 EXAMPLES 🔥

The following commands and output are a typical way how to find out and solve network problems using omping. In this situation, we have 3 computers 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 the nodes we should be able to see 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 (the 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 the 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 the 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 the 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 distance between the computers is 0, so they are on the same link net. The 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 the same as the previous two, but for node-03.

If the node is able to receive unicast packets, but never multicast, it means that the 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

The last line has additional information (seq>=2 %0) which means that after receiving the first multicast packet with seq number 2, no other multicast packet was lost. Because creating a multicast tree is time consuming, it's pretty normal to lose the first few multicast packets. The 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 a duplicate packet by looking at the output and finding a line which has the 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 the 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 the OS doesn't provide at least milliseconds precision, results may be incorrect.
no cap, those last three are real caveats — if your OS is being weird about TTL or timing precision, omping's numbers can be off. Not a skill issue, just a kernel issue. 🙈

and that's the whole page bestie, you ate it 💅 this one ships out of Debian, dated Jun 22, 2011 — iconic vintage energy, still slaying to this day. go forth and multicast responsibly 🦋💖

📦 where this page comes from