MTR and the IPv6 fuckup

I wrote about the internet and administrators unable to deal with IPv6, here is another sad story:

I use MTR to detect network issues:
$ mtr 8.8.8.8 --report --report-cycles=10 -n
Start: Sat Nov 21 14:31:47 2015
HOST: basteles-bastelknecht.baste Loss% Snt Last Avg Best Wrst StDev
1.|-- 88.198.253.2 0.0% 10 0.4 2.0 0.3 10.0 3.2
2.|-- 88.198.253.1 0.0% 10 0.6 0.5 0.4 0.7 0.0
3.|-- 88.198.244.253 0.0% 10 1.2 1.6 1.1 2.5 0.0
4.|-- 213.239.228.97 0.0% 10 1.1 0.8 0.4 1.4 0.0
5.|-- 213.239.245.113 0.0% 10 1.0 0.9 0.6 1.4 0.0
6.|-- 213.239.245.18 0.0% 10 5.3 5.5 5.3 6.3 0.0
7.|-- 213.239.245.1 0.0% 10 5.3 7.1 5.3 20.7 4.8
8.|-- 80.81.193.108 0.0% 10 5.8 6.3 5.6 9.9 1.2
9.|-- 72.14.238.225 0.0% 10 5.9 18.8 5.8 88.6 26.9
10.|-- 216.239.46.179 0.0% 10 6.3 7.3 6.0 13.1 2.2
11.|-- 8.8.8.8 0.0% 10 6.3 6.3 5.9 7.0 0.0

MTR works fine, until you place an IPv6 resolver in your /etc/resolv.conf. If MTR tries to use it, it exits. I tested this on Debian 8. There is a bug report from 2012! about this issue. I try to increase Ipv6 traffic so my first resolver is always a IPv6 one if the host has IPv6 as well. Is here anyone around that is able to provide a valid patch? Or knows an alternative to MTR with working IPv6 resolver support? Interesting is that MTR suppors tracing of IPv6 addresses very well, just not for resolver :(

This entry was posted in 30in30, General. Bookmark the permalink.

1 Response to MTR and the IPv6 fuckup

  1. Pingback: Augeas Bug while playing with ” in /etc/default/grub | the world needs more puppet!

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.