On a machine with modern, IPv6-enabled glibc, but with a Linux kernel
without IPv6 support, when mtr-ing a hostname that has an AAAA record,
mtr bails out with the following error message:

  $ mtr somehost.com
  Could not open IPv6 socket

MTR should just fall back to the IPv4 address the resolver gives it, not
give up.


Secondly (and this is probably a related issue in the network code), on
a host with IPv6-enabled glibc and an IPv6-enabled Linux kernel, but
without a Global-scope IPv6 address, mtr-ing a hostname with an AAAA
record results in no hops returning any data. In other applications,
connect() will fail with "network unreachable". Is it possible for mtr
to detect this as well, and fall back on IPv4 once it's clear that IPv6
is defunct?

  $ mtr -c 1 -r somehost.com
  HOST: something                   Loss%   Snt   Last   Avg  Best  Wrst  StDev


  (resolving somehost.com with 'host', and invoking mtr with the
  resulting IPv4 address works fine)


Marcel Moreaux <marcelm@luon.net>

I can confirm this still happens. I suppose I could cook up a patch on spare
time.

With the attached patch, the mtr compiled for IPv6 support fallbacks to IPv4
resolution when IPV6 isn't available on the host machine (the kernel lacks
IPv6 or have it disabled).

On Wed, Aug 03, 2005 at 09:30:42PM +0200, Marcel Moreaux wrote:

Hi,

Confirmed to work fine on Stretch. According to an upstream commit this
has been fixed in 0.86

https://github.com/traviscross/mtr/commit/12c53f98e44598b87d3f2308e0d892f49d7af8e4

This also works fine for me in Stretch with IPv6 enabled, but not
present on the network.

Bernhard