Bug#840563: mtr: New 0.87 release fixes issue with paths with long gaps
On Sat, Oct 15, 2016 at 01:00:28AM -0400, Matthew Gabeler-Lee wrote: > On Thu, 13 Oct 2016, Rogier Wolff wrote: > > >No! Not a "more reasonable" value! An outrageous value! > > > >You have a network where 5 hops-in-a-row don't conform to IP standards. And > >then you expect mtr to work? > > traceroute works fine, ping works fine, tcp connections work fine > ... but mtr is special and should fail just because the network > doesn't meet your ideals? And yeah, MTR would work fine in this > case if it didn't decide to give up "just because". The "give up > after 5" is the /only/ thing preventing it from working properly. > > To put a concrete example to it, consider the case of tunnels, esp. > VPNs. It is common for the TTL of the tunneled packet to be copied > to the outer packet for various good reasons. But this means that > traceroute through that tunnel will not return the errors for any > TTL value that causes the packet to be dropped at points between the > endpoints of the tunnel, because the error will be returned back to > the tunnel endpoint, not the original sender. > > Happens with OpenVPN (it's even in their FAQ I think), happens with > the Cisco IPSEC site-to-site tunnel used at my employer. To discover the route to a "random" host we could just send out probes for every distance up to the max TTL. This is wasteful because most of the targets will be within say 12 hops, so sending out 64 packets is too much. Another common situation is that you start using mstr to determine where in the network packets are being dropped. If there is a 100% blockage at some point, after that moment no further probe will return results. So to prevent unnecessary load on the network (which when you're running mtr is already experiencing difficulties) we put an upper limit on the number of hosts that don't respond. Your example with a tunnel is a good one. At first I thought the TTL should be set to "max" when entering the tunnel, but on second thought that would be bad: routing / tunneling mishap could then "rejuvenate" a packet each time it enters the tunnel leading to chaos (packets that keep running circles and never die). Anyway, I've already increased the limit in the development version, and I thank you for explaining to me why this is becoming more common. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work.
Bug#840563: mtr: New 0.87 release fixes issue with paths with long gaps
On Thu, 13 Oct 2016, Rogier Wolff wrote: No! Not a "more reasonable" value! An outrageous value! You have a network where 5 hops-in-a-row don't conform to IP standards. And then you expect mtr to work? traceroute works fine, ping works fine, tcp connections work fine ... but mtr is special and should fail just because the network doesn't meet your ideals? And yeah, MTR would work fine in this case if it didn't decide to give up "just because". The "give up after 5" is the /only/ thing preventing it from working properly. To put a concrete example to it, consider the case of tunnels, esp. VPNs. It is common for the TTL of the tunneled packet to be copied to the outer packet for various good reasons. But this means that traceroute through that tunnel will not return the errors for any TTL value that causes the packet to be dropped at points between the endpoints of the tunnel, because the error will be returned back to the tunnel endpoint, not the original sender. Happens with OpenVPN (it's even in their FAQ I think), happens with the Cisco IPSEC site-to-site tunnel used at my employer. -- -Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#840563: mtr: New 0.87 release fixes issue with paths with long gaps
On Wed, Oct 12, 2016 at 03:29:41PM -0400, Matthew Gabeler-Lee wrote: > Package: mtr > Version: 0.86-1+b1 > Severity: wishlist > > A new upstream release 0.87 has a fix (of sorts) for the problem where MTR > will not trace a successful path that has more than five non-responding > hops. I say fix "of sorts" because the default limit for this has not been > changed, but it is now possible to override that default on the command > line. FWIW the MTR git shows that an upcoming not-yet-released version also > increases the default to a more reasonable value. No! Not a "more reasonable" value! An outrageous value! You have a network where 5 hops-in-a-row don't conform to IP standards. And then you expect mtr to work? Roger. > > -- System Information: > Debian Release: stretch/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages mtr depends on: > ii libatk1.0-0 2.22.0-1 > ii libc62.24-3 > ii libcairo21.14.6-1+b1 > ii libfontconfig1 2.11.0-6.7 > ii libfreetype6 2.6.3-3+b1 > ii libgdk-pixbuf2.0-0 2.36.0-1 > ii libglib2.0-0 2.50.0-2 > ii libgtk2.0-0 2.24.31-1 > ii libncurses5 6.0+20160917-1 > ii libpango-1.0-0 1.40.3-2 > ii libpangocairo-1.0-0 1.40.3-2 > ii libpangoft2-1.0-01.40.3-2 > ii libtinfo56.0+20160917-1 > > mtr recommends no packages. > > mtr suggests no packages. > > -- no debconf information > -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work.
Bug#840563: mtr: New 0.87 release fixes issue with paths with long gaps
Package: mtr Version: 0.86-1+b1 Severity: wishlist A new upstream release 0.87 has a fix (of sorts) for the problem where MTR will not trace a successful path that has more than five non-responding hops. I say fix "of sorts" because the default limit for this has not been changed, but it is now possible to override that default on the command line. FWIW the MTR git shows that an upcoming not-yet-released version also increases the default to a more reasonable value. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mtr depends on: ii libatk1.0-0 2.22.0-1 ii libc62.24-3 ii libcairo21.14.6-1+b1 ii libfontconfig1 2.11.0-6.7 ii libfreetype6 2.6.3-3+b1 ii libgdk-pixbuf2.0-0 2.36.0-1 ii libglib2.0-0 2.50.0-2 ii libgtk2.0-0 2.24.31-1 ii libncurses5 6.0+20160917-1 ii libpango-1.0-0 1.40.3-2 ii libpangocairo-1.0-0 1.40.3-2 ii libpangoft2-1.0-01.40.3-2 ii libtinfo56.0+20160917-1 mtr recommends no packages. mtr suggests no packages. -- no debconf information
