Destination IP is ignored about yarrp

[robertbeverly]

Hi @svbatalov, short answer is that it's by design but we don't ignore all responses from the destination, just echo replies. yarrp ignores ICMP echo replies because they don't quote the original probe packet headers (which yarrp requires to reconstruct state since it's stateless). If, for example, you run a UDP yarrp trace that reaches the destination, and the destination replies with an ICMP destination/port unreachable message, yarrp will record that it reached the destination. Does that work for your use case, or do you have to use ICMP probes?

[svbatalov]

Hey Robert,
thank you for the response!

yarrp ignores ICMP echo replies because they don't quote the original probe packet header

I see, so request headers are only included in ICMP error messages, not echo_reply so one would need to include all necessary data into request's payload, not its headers, to handle ICMP_ECHOREPLY. Makes sense.

Does that work for your use case, or do you have to use ICMP probes?

One reason to prefer ICMP probes was this scamper paper mentioning that ICMP traceroute reaches more destinations compared to other methods. Also, I encountered some problems with UDP scans, described below.

When doing UDP scans yarrp first yields a ton of ** IP dst in ICMP reply quote invalid! messages and, a bit later, a never-ending flow of messages like this

probeUDP(): error: Message too long
>> UDP probe: 113.30.35.178 ttl: 21 t=255340416

The output file stops increasing once these errors appear.

After some experimentation with various sysctl settings, which didn't help, I tried to find the reason in the code and came across this:

yarrp/trace4.cpp

Lines 100 to 104 in 049d3ae

	uint32_t diff = elapsed();
	payloadlen = 2;
	/* encode MSB of timestamp in UDP payload length */
	if (diff >> 16)
	payloadlen += (diff>>16);

So looks like two higher bytes of timestamp are encoded in UDP payload length, hence as time passes the UDP packet sizes will increase "without limit". I tweaked the code a bit and found that first error happens when payloadlen=1473. Apparently, UDP packets of this "size" are too big for my system (Ubuntu 16.04 on Linode VM) or some intermediate router. Indeed, at this specific packet size nping starts to yield the same error (with and without --df):

# nping --udp -p 11111 144.193.94.175 --data-length 1473 -c 1 --df
WARNING: Payload exceeds maximum recommended payload (1400)

Starting Nping 0.7.01 ( https://nmap.org/nping ) at 2020-06-28 18:06 UTC
sendto in send_ip_packet_sd: sendto(4, packet, 1501, 0, 144.193.94.175, 16) => Message too long
Offending packet: UDP 172.104.12.12:53 > 144.193.94.175:11111 ttl=64 id=58220 iplen=1501
SENT (0.0236s) UDP 172.104.12.12:53 > 144.193.94.175:11111 ttl=64 id=58220 iplen=1501

Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 1 (1.501KB) | Rcvd: 0 (0B) | Lost: 1 (100.00%)
Nping done: 1 IP address pinged in 1.05 seconds

My understanding is that one can not send IP packets bigger than MTU (1500 in this case) with fragmenting prohibited (which seem to be the case here). How is this supposed to work? Maybe one should not include this fake payload length into IP header length, as actual UDP payload size is only 2 bytes?

yarrp/trace4.cpp

Line 110 in 049d3ae

packlen = sizeof(struct ip) + sizeof(struct udphdr) + payloadlen;

Shouldn't it be something like this

diff --git a/trace4.cpp b/trace4.cpp
index 0f769f5..3365b0f 100644
--- a/trace4.cpp
+++ b/trace4.cpp
@@ -107,7 +107,7 @@ Traceroute4::probeUDP(struct sockaddr_in *target, int ttl) {
         probePrint(&target->sin_addr, ttl);
     }

-    packlen = sizeof(struct ip) + sizeof(struct udphdr) + payloadlen;
+    packlen = sizeof(struct ip) + sizeof(struct udphdr) + 2;

     outip->ip_p = IPPROTO_UDP;
 #ifdef _BSD
@@ -128,7 +128,7 @@ Traceroute4::probeUDP(struct sockaddr_in *target, int ttl) {

     /* compute UDP checksum */
     memset(data, 0, 2);
-    u_short len = sizeof(struct udphdr) + payloadlen;
+    u_short len = sizeof(struct udphdr) + 2;
     udp->uh_sum = p_cksum(outip, (u_short *) udp, len);

     /* encode LSB of timestamp in checksum */

As another workaround, I found an undocumented command-line option -C (for coarse) which changes timestamps from microsecond to millisecond accuracy, thus reducing its numerical values and payloadlen. However, resulting traces have millisecond RTT accuracy, which is not good.

Thanks,
Sergey.