High-resolution network monitoring with ping
Return Values
The ping
command also has a return value, in addition to the RTT, that can assume all kinds of values, because pong (the answer to ping) can contain different messages: from A for communication with destination network administratively prohibited
to Z for communication with destination host administratively prohibited
. In other cases, you could have corrupted data and ICMP error messages.
The ping programs distinguish between cases but is unfortunately not very specific; even the very useful version from the iputils package only utilizes three cases, as you can see from the man page: "If ping does not receive any reply packets, it terminates with code 1. For other errors, it terminates with code 2. In all other cases it exits with code 0."
In short, the iputils ping returns code 1 for a timeout or loss, 2 for all other errors, and 0 if the ping returns without error. Therefore, lost pings (e.g., through wire breaks) can be identified by a return value of 1, and other errors by a return value of 2.
Deviations from this rule occur in practice: if the network of the target computer is unreachable, ping reports Network is unreachable
with a return value of 2. Thus, users cannot tell wire breaks from other errors. Interruptions, however, such as a spy box inserted along the path, will always cause a non-zero return value.
Success Quota
The Pinger program creates exponential moving averages for the return values and RTTs, expressed as percentages, so that a return value of 0 is usually close to 100 percent, and code 1 or 2 errors, as in the case of wire breaks, are well above 0 percent. An advantage compared with typical monitoring programs such as MRTG [6] is that Pinger determines values every second, whereas MRTG and the like usually only check every five minutes (300 seconds).
Moreover, Linux users can identify wire breaks on the local computer from kernel messages, as Listing 2 shows. ethtool
gives you the current Ethernet status.
Listing 2
Kernel Messages
Other computer components are similar; for example, the keyboard has timeout flag 0x40
on port 0x64
– even PS/2 keyboards, for which the kernel does not provide any messages.
Finding Switches and Bridges
In practice, Pinger can be used to find a switch or a transparent bridge on the gigabit LAN. Such a device is barely noticeable on the network because it does not change the data packets when it forwards them. Yet an attacker could use it to sniff, evaluate, or manipulate the traffic. Pure sniffing goes undetected on the basis of data only.
However, metadata associated with data is on the network, such as the latency of a connection. A switch means additional latency, with a delay that increases with the size of the package, because it only forwards a packet after receiving and processing it completely. Therefore, at least the packet reception time is detectable as a longer packet at run time. For monitoring, you would theoretically want to use packets that are as large as possible and unfragmented. In practice, 44-byte pings have been shown to do the trick, as a test with a gigabit LAN switch shows.
Figure 1 shows the RTT between two Linux PCs. A D-Link DGS-1008D digital gigabit switch is initially between the computers. In the afternoon, that switch is removed and replaced by a 4cm adapter. The diagram plots the RTTs of pings sent every second (in milliseconds) over time, after exponential smoothing with a factor of 0.001, to create approximately 1,000-second mean values.

The absence of the gigabit switch is clearly shown by the 30µs shorter RTTs. One thousand pings are all it takes, and they can run in the background during normal operations.
Shortly before noon on the following day, I replaced the adapter with a Netgear GS105 switch that suddenly increased the RTT by more than 20µs. The TP-LINK TL-SG1024 switch, however, shows no significant difference in RTTs, at least in the 1,000-second mean values for the first hours compared with the adapter. Then, the increase is just 15µs, which means the switch is initially significantly closer to the theoretical 352ns packet reception time limit than the others.
Here, the RTTs vary only by a few microseconds; large ping packets might deliver clearer results. You do not need jumbo frames and huge pings; pings with a size of 1,500 bytes prove to be perfectly okay. The packet reception time is an easily measurable 12µs. The RTT difference is 32µs, a change from 228 to 260µs, as Figure 2 shows.
On closer inspection, Figure 1 reveals a daily rhythm, caused by RTT values that increase with the load average of the participating computers and the network load. For example, on the last day of the test, the load average increased by one, and the RTT increased by 5µs on one computer. Minimum values occur at night between 2 and 3am.
You can easily compute these influences in a first approximation; to determine the net RTT for a load average and a network load of 0, thus resulting in significantly more accurate values. Because same-day procedures almost always return the same daily averages, this case can make do without such corrections and thus ensure high resolution, as shown in the next example.
Incidentally, alternatives to using more pings for higher resolution include pinging with real-time threads under Linux-RT (preemption) using a soft real-time or RTAI (real-time application interface) with a hard real-time, and taking differential measurements (i.e., pinging on two different connections) and evaluating the differences in the RTT values.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

News
-
First Release Candidate for Linux Kernel 6.14 Now Available
Linus Torvalds has officially released the first release candidate for kernel 6.14 and it includes over 500,000 lines of modified code, making for a small release.
-
System76 Refreshes Meerkat Mini PC
If you're looking for a small form factor PC powered by Linux, System76 has exactly what you need in the Meerkat mini PC.
-
Gnome 48 Alpha Ready for Testing
The latest Gnome desktop alpha is now available with plenty of new features and improvements.
-
Wine 10 Includes Plenty to Excite Users
With its latest release, Wine has the usual crop of bug fixes and improvements, along with some exciting new features.
-
Linux Kernel 6.13 Offers Improvements for AMD/Apple Users
The latest Linux kernel is now available, and it includes plenty of improvements, especially for those who use AMD or Apple-based systems.
-
Gnome 48 Debuts New Audio Player
To date, the audio player found within the Gnome desktop has been meh at best, but with the upcoming release that all changes.
-
Plasma 6.3 Ready for Public Beta Testing
Plasma 6.3 will ship with KDE Gear 24.12.1 and KDE Frameworks 6.10, along with some new and exciting features.
-
Budgie 10.10 Scheduled for Q1 2025 with a Surprising Desktop Update
If Budgie is your desktop environment of choice, 2025 is going to be a great year for you.
-
Firefox 134 Offers Improvements for Linux Version
Fans of Linux and Firefox rejoice, as there's a new version available that includes some handy updates.
-
Serpent OS Arrives with a New Alpha Release
After months of silence, Ikey Doherty has released a new alpha for his Serpent OS.