2

I have the following output from hping on OpenBSD:

# hping --icmp-ts www.openbsd.org
HPING www.openbsd.org (re0 129.128.5.194): icmp mode set, 28 headers + 0 data bytes
len=46 ip=129.128.5.194 ttl=237 id=23807 icmp_seq=0 rtt=155.3 ms
ICMP timestamp: Originate=22085077 Receive=22085171 Transmit=22085171
ICMP timestamp RTT tsrtt=156

len=46 ip=129.128.5.194 ttl=237 id=4150 icmp_seq=1 rtt=154.8 ms
ICMP timestamp: Originate=22086078 Receive=22086171 Transmit=22086171
ICMP timestamp RTT tsrtt=155

^C
--- www.openbsd.org hping statistic ---
2 packets tramitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 154.8/155.0/155.3 ms

I require some extra arithmetic to troubleshoot asymmetric routes, as available in a patch in some bugreport, but I don't want to have to recompile the software.

TL;DR, the two new fields are calculated as Receive − Originate and Originate + tsrtt − Transmit, to result in something like the following (without necessarily having to span 4 lines).

len=46 ip=129.128.5.194 ttl=237 id=23807 icmp_seq=0 rtt=155.3 ms
ICMP timestamp: Originate=22085077 Receive=22085171 Transmit=22085171
ICMP timestamp RTT tsrtt=156  src->dst=94  dst->src=62

How do I do this with awk? (I'm fine with any other *BSD tool, too.)

Community
  • 1
  • 1
cnst
  • 25,870
  • 6
  • 90
  • 122

2 Answers2

3

Using perl, you can do something like this:

#!/usr/bin/perl -n
#
if (/Originate=(\d+) Receive=(\d+) Transmit=(\d+)/) {
    ($o, $r, $t) = ($1, $2, $3);
} elsif (/tsrtt=(\d+)/) {
    print $r - $o, " ", $o + $1 - $t, "\n";
}

If you call this icmpstats.pl, you can use as hping | perl icmpstats.pl.

janos
  • 120,954
  • 29
  • 226
  • 236
  • hm, i think it's related to some kind of buffering issues -- if I save the output from `hping` to an intermediate file, and then `cat` and pipe that to `perl -ne 'if ...'`, then i do get the two numbers printed per each input sequence, but a direct pipe from hping leaves no output at all, except for the ping summary upon `^C` – cnst Nov 24 '13 at 07:32
  • 1
    I see. Try the first two answers of this question: http://serverfault.com/questions/294218/is-there-a-way-to-redirect-output-to-a-file-without-buffering-on-unix-linux – janos Nov 24 '13 at 07:35
  • Yes, also at http://unix.stackexchange.com/a/61833/28354. `script -q /dev/null hping` makes it line-buffered, although it's somewhat ugly. Thanks, +1! – cnst Nov 24 '13 at 07:43
2

A modification of the solution from janos, to provide a usable snippet.

Note that the output of hping becomes fully buffered when redirected to a pipe, which, surprisingly, quite inhibits in the portability of the solution. See https://unix.stackexchange.com/questions/25372/turn-off-buffering-in-pipe and https://unix.stackexchange.com/questions/102403/turn-off-buffering-for-hping-in-openbsd.

The following works on OpenBSD, after installing the expect package:

unbuffer hping --icmp-ts ntp1.yycix.ca \
| perl -ne 'if (/icmp_seq=(\d+) rtt=(\d+\.\d)/) {($s, $p) = ($1, $2);} \
if (/ate=(\d+) Receive=(\d+) Transmit=(\d+)/) {($o, $r, $t) = ($1, $2, $3);} \
if (/tsrtt=(\d+)/) { \
print $s, "\t", $p, "\t", $1, " = ", $r - $o, " + ", $o + $1 - $t, "\n"; }'

The following is required on OS X, since its expect is not accompanied by unbuffer:

script -q /dev/null hping3 --icmp-ts ntp1.yycix.ca \
| perl -ne 'if (/icmp_seq=(\d+) rtt=(\d+\.\d)/) {($s, $p) = ($1, $2);} \
if (/ate=(\d+) Receive=(\d+) Transmit=(\d+)/) {($o, $r, $t) = ($1, $2, $3);} \
if (/tsrtt=(\d+)/) { \
print $s, "\t", $p, "\t", $1, " = ", $r - $o, " + ", $o + $1 - $t, "\r\n"; }'

This is a sample output form the script, which shows that the forward path is congested, and the return path is most likely not:

0       145.5   146 = 75 + 71
1       142.7   142 = 72 + 70
2       140.7   140 = 70 + 70
3       146.7   146 = 76 + 70
4       148.3   148 = 77 + 71
5       157.5   157 = 87 + 70
6       167.1   167 = 96 + 71
7       166.3   166 = 95 + 71
8       167.7   167 = 97 + 70
9       159.0   159 = 88 + 71
10      156.7   156 = 86 + 70
11      154.9   155 = 84 + 71
12      151.9   152 = 81 + 71
13      157.3   157 = 86 + 71
14      155.0   155 = 84 + 71
15      157.7   158 = 87 + 71
16      156.6   156 = 86 + 70
17      157.8   158 = 87 + 71
18      161.9   162 = 91 + 71
19      160.1   160 = 89 + 71
20      166.3   166 = 95 + 71
21      163.9   164 = 93 + 71
22      172.0   172 = 101 + 71
23      177.9   178 = 107 + 71
24      177.0   177 = 106 + 71
25      172.1   172 = 101 + 71
26      167.4   167 = 97 + 70
27      167.1   167 = 96 + 71
28      161.0   161 = 90 + 71
29      150.5   150 = 80 + 70
30      155.6   155 = 85 + 70
31      162.0   162 = 91 + 71
32      154.3   154 = 84 + 70

Note that if the clock is out-of-sync, then you'd be going negative, which, nonetheless, still serves as a good indicator of which side is experiencing the congestion.

The following example is through the same path; notice how one value still goes up and down randomly, whereas the other one changes monotonically.

0       165.9   166 = -142113 + 142279
1       160.2   160 = -142118 + 142278
2       155.2   155 = -142122 + 142277
3       156.5   156 = -142121 + 142277
4       164.7   165 = -142112 + 142277
5       164.4   164 = -142111 + 142275
6       160.9   161 = -142114 + 142275
7       158.1   158 = -142117 + 142275
8       155.6   156 = -142119 + 142275
9       143.0   143 = -142131 + 142274
10      153.2   153 = -142120 + 142273
11      157.1   157 = -142115 + 142272
12      158.3   158 = -142114 + 142272
13      148.6   149 = -142123 + 142272
14      144.3   144 = -142127 + 142271
15      145.3   145 = -142125 + 142270
16      141.9   142 = -142128 + 142270
Community
  • 1
  • 1
cnst
  • 25,870
  • 6
  • 90
  • 122