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
-
TUXEDO Computers Unveils Linux Laptop Featuring AMD Ryzen CPU
This latest release is the first laptop to include the new CPU from Ryzen and Linux preinstalled.
-
XZ Gets the All-Clear
The back door xz vulnerability has been officially reverted for Fedora 40 and versions 38 and 39 were never affected.
-
Canonical Collaborates with Qualcomm on New Venture
This new joint effort is geared toward bringing Ubuntu and Ubuntu Core to Qualcomm-powered devices.
-
Kodi 21.0 Open-Source Entertainment Hub Released
After a year of development, the award-winning Kodi cross-platform, media center software is now available with many new additions and improvements.
-
Linux Usage Increases in Two Key Areas
If market share is your thing, you'll be happy to know that Linux is on the rise in two areas that, if they keep climbing, could have serious meaning for Linux's future.
-
Vulnerability Discovered in xz Libraries
An urgent alert for Fedora 40 has been posted and users should pay attention.
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.
-
New Pentesting Distribution to Compete with Kali Linux
SnoopGod is now available for your testing needs
-
Juno Computers Launches Another Linux Laptop
If you're looking for a powerhouse laptop that runs Ubuntu, the Juno Computers Neptune 17 v6 should be on your radar.