cmand / yarrp

High-speed Internet Topology Prober

Yarrp (Yelling at Random Routers Progressively)

Yarrp is a next-generation active network topology discovery technique and tool designed for rapid mapping at Internet scales. As with traditional traceroute, Yarrp discovers router interfaces and the links between them. However, Yarrp can probe at over 100Kpps and has been shown to discover >200K router interfaces in less than 5 minutes. Yarrp supports TCP, UDP-paris, and ICMP-paris probing over both IPv4 and IPv6. Yarrp is written in C++, runs on Linux and BSD systems, and is open-sourced with a BSD license.

Build

./bootstrap
./configure
make

Technical details

• See https://www.cmand.org/yarrp

yarrp's Issues

yarrp sends ethernet headers on point-to-point interfaces

I tested this with a Wireguard interface on Linux.

$ yarrp -v -o test.yrp -I wg-as206226 -t ICMP6 <target>
>> yarrp v0.7
>> Probing begins.
>> Waiting 60s for outstanding replies...
>> Listener: timeout 1/10
>> Listener: timeout 2/10
>> Listener: timeout 3/10

I built yarrp from git, commit 91bcd88. I used tcpdump to confirm that yarrp does indeed send Ethernet headers even though the interface does not use any link-layer protocol.

Bug found in timestamp decoding process

Hello,
I notice a bug in icmp.cpp when the encoded timestamp is extracted from udp header.

diff --git a/icmp.cpp b/icmp.cpp
index cb36644..a7823f6 100644
--- a/icmp.cpp
+++ b/icmp.cpp
@@ -59,7 +59,7 @@ ICMP4::ICMP4(struct ip *ip, struct icmp *icmp, uint32_t elapsed, bool _coarse):
         else if (quote->ip_p == IPPROTO_UDP) {
             struct udphdr *udp = (struct udphdr *) (ptr + 8 + (quote->ip_hl << 2));
             /* recover timestamp from UDP.check and UDP.payloadlen */
-            int payloadlen = ntohs(udp->uh_ulen) - sizeof(struct icmp);
+            int payloadlen = ntohs(udp->uh_ulen) - sizeof(struct udphdr);
             int timestamp = udp->uh_sum;
             sport = ntohs(udp->uh_sport);
             dport = ntohs(udp->uh_dport);

This bug prevents the carry of the timestamp to be calculated correctly, thus influencing the rtt.

Running multiple yarrp instances

Hi,

as part of the IPv6 hitlist service we used to run yarrp in parallel with different source addresses.

Currently we run yarrp-0.5. We saw in the change logs that you added an instance lock in 0.6 Commit f3c093d.
What is the reason for this? Is there still a possibility to run multiple instances in parallel for better performance?

Destination IP is ignored

Hello.

I noticed that traces produced by yarrp do not include destination IP even when using ICMP probes and destination responses to ping. For example:

$ sudo yarrp -t ICMP -i - <<<139.130.4.5
>> Listener: timeout 1/10
>> Listener: timeout 2/10
>> Listener: timeout 3/10
>> Listener: timeout 4/10
>> Listener: timeout 5/10
>> Listener: timeout 6/10
>> Listener: timeout 7/10
>> Listener: timeout 8/10
>> Listener: timeout 9/10
>> Listener: timeout 10/10

$ yrp2warts -i output.yrp -o /tmp/output.warts
Opening Yarrp file: output.yrp
Processed 21 Yarrp records
Created 1 traces
Opening output file /tmp/output.warts
Writing cycle start
Writing cycle stop

$ sc_warts2text /tmp/output.warts
traceroute from 192.168.2.162 to 139.130.4.5
 1  192.168.2.1  2.325 ms
 2  192.168.1.1  2.085 ms
 3  10.140.0.1  3.652 ms
 4  85.235.63.162  14.677 ms
 5  212.188.18.130  6.003 ms
 6  212.188.29.249  7.833 ms
 7  212.188.29.85  20.924 ms
 8  195.34.50.161  31.803 ms
 9  212.188.2.37  89.928 ms
10  212.188.54.2  49.383 ms
11  62.115.146.178  47.144 ms
12  62.115.123.26  219.209 ms
13  62.115.139.169  223.352 ms
14  213.155.134.50  159.106 ms
15  213.155.130.129  217.790 ms
16  80.239.128.77  266.369 ms
17  202.84.247.18  221.273 ms
18  202.84.141.26  353.336 ms
19  203.50.13.89  355.261 ms
20  203.50.6.60  355.373 ms
21  203.50.11.221  353.067 ms

Regular traceroute includes the destination:

$ sudo traceroute -I 139.130.4.5
traceroute to 139.130.4.5 (139.130.4.5), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.2.1)  5.835 ms  7.381 ms  16.784 ms
 2  192.168.1.1 (192.168.1.1)  17.045 ms  18.309 ms  18.519 ms
 3  10.140.0.1 (10.140.0.1)  56.319 ms  90.790 ms  141.986 ms
 4  85-235-63-162.rev.utk.ru (85.235.63.162)  121.019 ms  121.223 ms  121.423 ms
 5  asb-cr01-ae19.0.ekt.mts-internet.net (212.188.18.130)  128.661 ms  129.474 ms  129.502 ms
 6  zoo-cr01-be1.66.ekt.mts-internet.net (212.188.29.249)  152.927 ms  9.834 ms  16.167 ms
 7  pob-cr02-be7.66.kaz.mts-internet.net (212.188.29.85)  29.793 ms  30.403 ms  30.448 ms
 8  mag9-cr01-be6.16.msk.mts-internet.net (195.34.50.161)  40.386 ms  48.343 ms  50.022 ms
 9  oct-cr03-be1.78.spb.mts-internet.net (212.188.2.37)  60.694 ms  61.700 ms  80.641 ms
10  kivi-cr02-ae8.78.hel.mts-internet.net (212.188.54.2)  87.671 ms  109.981 ms  110.829 ms
11  hls-b2-link.telia.net (62.115.146.178)  110.850 ms  50.887 ms  52.387 ms
12  s-bb3-link.telia.net (62.115.123.26)  230.409 ms  231.200 ms  231.229 ms
13  kbn-bb3-link.telia.net (62.115.139.169)  231.231 ms  231.248 ms  231.251 ms
14  nyk-bb3-link.telia.net (213.155.134.50)  158.885 ms  160.885 ms  160.923 ms
15  sjo-b21-link.telia.net (213.155.130.129)  231.153 ms  217.066 ms  215.983 ms
16  telstra-ic-326434-sjo-b21.c.telia.net (80.239.128.77)  219.706 ms  222.440 ms  218.051 ms
17  i-92.eqnx-core02.telstraglobal.net (202.84.247.18)  225.953 ms  219.395 ms  218.012 ms
18  i-20208.sydp-core04.telstraglobal.net (202.84.141.26)  354.557 ms  353.809 ms  356.581 ms
19  bundle-ether3.pad-gw11.sydney.telstra.net (203.50.13.89)  359.426 ms  359.763 ms  356.776 ms
20  bundle-ether3.ken-core10.sydney.telstra.net (203.50.6.60)  360.148 ms  360.588 ms  360.929ms
21  bundle-ether2.ken-ncprouter101.sydney.telstra.net (203.50.11.221)  355.469 ms  375.893 ms 379.293 ms
22  139.130.4.5 (139.130.4.5)  379.603 ms  385.109 ms  386.120 ms

In my use-case it is necessary to know the distance (in hops) between router and destination, which requires knowing TTL of the destination.

From the quick look at the code it seems that ICMP_ECHOREPLY, which is expected from destination IP, is not handled:

yarrp/icmp.cpp

Lines 35 to 36 in ec16b8e

	if (((type == ICMP_TIMXCEED) and (code == ICMP_TIMXCEED_INTRANS)) or
	(type == ICMP_UNREACH)) {

Is this something that can be fixed or by design?

Thanks.

Occasional incorrect inferred target when probing using ICMP6 echo

As reported by Dave Plonka [email protected]:

"What I've found is that some [IPv6] routers will respond with an echo reply to an echo request destined for a host on their LAN."

ICMP6 echo responses only quote the ECHO probe payload (not the full IPv6 packet). Thus, yarrp assumes that ICMP6 echo responses originate from the target that was probed. In the above case (when a different IPv6 source is sending responses), yarrp incorrect outputs the probed target as the responding proxy.

cperm.h is lost in the project

It seems that cperm.h is lost in the project.

When I ran make, I got an error as follows:

yarrp.h:77:20: fetal error: cperm.h: No such file or directory.

I did not find file cperm.h in the project.