Show HN: An async traceroute(1) implementation in Rust(github.com)
github.com
Show HN: An async traceroute(1) implementation in Rust
https://github.com/overclockworked64/traceroute
4 comments
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, which is often the case.
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.
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.
They appear to be fingerprinting & dropping traceroutes specifically. Flipping it to reverse usually bypasses this.
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.
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.
Does Redox-OS have a built in traceroute? Either way, maybe this would be a good candidate for a future release.
Comments and suggestions are welcome!