traviscross / mtr

Official repository for mtr, a network diagnostic tool
http://www.bitwizard.nl/mtr/
GNU General Public License v2.0
2.67k stars 340 forks source link

Feature request: explicitly specify which ttls to send #295

Open danpritts opened 5 years ago

danpritts commented 5 years ago

First, thank you for mtr, it is a very valuable tool.

Consider:

 11.|-- 1.2.3.4                              0.0%     3   44.0  45.8  42.9  50.6   4.1
 12.|-- 5.6.7.8                                0.0%     3   22.8  22.8  22.8  22.8   0.0
 13.|-- ???                                        100.0     3    0.0   0.0   0.0   0.0   0.0
 14.|-- ???                                        100.0     3    0.0   0.0   0.0   0.0   0.0
 15.|-- ???                                        100.0     3    0.0   0.0   0.0   0.0   0.0
 16.|-- 9.10.11.12                                0.0%     3   23.7  23.5  23.2  23.7   0.3
 17.|-- ???                                        100.0     3    0.0   0.0   0.0   0.0   0.0
 18.|-- ???                                        100.0     3    0.0   0.0   0.0   0.0   0.0
 19.|-- ???                                        100.0     3    0.0   0.0   0.0   0.0   0.0
 20.|-- ???                                        100.0     3    0.0   0.0   0.0   0.0   0.0
 21.|-- ???                                        100.0     3    0.0   0.0   0.0   0.0   0.0
 22.|-- destination.compute-1.amazonaws.com  0.0%     3   23.2  23.3  23.2  23.3   0.0

I can specify minimum and maximum TTL's to use, which is great.

But in this case, I'd like to try 11,12,16,22 and ignore the rest, which are not responding to me.

Sure, I can just grep out the output, but testing this way means I have to send about twice as much traffic to get the data I want.

rewolff commented 5 years ago

I don't think I'll have time to build this anytime soon. But...

I would think that this is quite "fragile". Sometimes the internet shifts a bit and the route to what's in this case "host 11: 1.2.3.4" would become one hop shorter or longer. This means that the host at position 16 suddenly drops from view!

How about: If the response on the last n probes is < x% avoid sending y% of probes. So maybe x=10% and y=95%, you'd reduce the probe rate of 13-15 and 17-21 by a factor of 20, but they would pop back in view as soon as they start responding. (either because of a configuration change in the internet or on the router itself).