Comments and suggestions are welcome!
Show HN: An async traceroute(1) implementation in Rust
github.com
1–5 of 5 posts
Comments and suggestions are welcome!
Show HN: An async traceroute(1) implementation in Rust
github.com
Something I've always wanted in traceroute is a flag to make it count _down_ instead of counting _up_. I usually do this manually with ping which is cumbersome. Traceroutes which count up are often blocked along the way by a firewall.
Aside from this, please correct me if I'm wrong, but it is my understanding that if a router along the path is configured to drop ICMP Echo Request packets, it will drop them in any case - whether we trace from the beginning or in reverse.
Something I've always wanted in traceroute is a flag to make it count _down_ instead of counting _up_. I usually do this manually with ping which is cumbersome. Traceroutes which count up are often blocked along the way by a firewall.
I can see one potential issue with counting down instead of up. The maximum number of hops a packet can traverse along the path is 255 because TTL is an 8-bit field. This means the program implemented that way would need to account for the worst case and start the tracing process with the TTL of 255. In turn, this leads to sending excessively more packets than required if the path ends up being shorter than that, whi…
I'd be totally satisfied if it just accepted a TTL to count down from, but you can do a lot better than counting down from 255.
You can usually infer how many hops away something is from the TTL by assuming it was originally the nearest power of 2. Failing that, you can use binary search to identify the distance pretty quickly.
None of this is foolproof by any means, each packet could take a different route, but it seems to work fine.
Of course, if you do include this feature and people start to use it, they'll probably just improve the fingerprint, so maybe it's self defeating anyway.