IPv6 breaks some tests

[aww-aww]

I configured a device on T-mobile using their IPv6 APN and some of the ping / traceroute tests stopped working (using baseband, not Wi-Fi). The exact failure reason is not clear as ping / traceroute fail to www.google.com and some of the mlab targets, but they work fine for others. It is not something simple like lack of a AAAA. I'll poke at it a bit more and try to sort out what the real issue is.

[mdwelsh]

For ping and traceroute it's using the system ping binary, not ping6.
You are one of a very small number of users with ipv6 enabled on T-Mobile's
global network, so I am not sure this is that critical :-)

On Wed, Jan 16, 2013 at 6:07 PM, Andy Warner notifications@github.comwrote:

I configured a device on T-mobile using their IPv6 APN and some of the
ping / traceroute tests stopped working (using baseband, not Wi-Fi). The
exact failure reason is not clear as ping / traceroute fail to
www.google.com and some of the mlab targets, but they work fine for
others. It is not something simple like lack of a AAAA. I'll poke at it a
bit more and try to sort out what the real issue is.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/150.

Not critical, but important. It should be trivial to detect if the
INetAddress connected to is v4 or v6 and change the binary used accordingly.

On Wed, Jan 16, 2013 at 8:42 PM, Matt Welsh notifications@github.comwrote:

For ping and traceroute it's using the system ping binary, not ping6.
You are one of a very small number of users with ipv6 enabled on
T-Mobile's
global network, so I am not sure this is that critical :-)

On Wed, Jan 16, 2013 at 6:07 PM, Andy Warner notifications@github.comwrote:

I configured a device on T-mobile using their IPv6 APN and some of the
ping / traceroute tests stopped working (using baseband, not Wi-Fi). The
exact failure reason is not clear as ping / traceroute fail to
www.google.com and some of the mlab targets, but they work fine for
others. It is not something simple like lack of a AAAA. I'll poke at it
a
bit more and try to sort out what the real issue is.

—
Reply to this email directly or view it on GitHub<
https://github.com/Mobiperf/MobiPerf/issues/150>.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/150#issuecomment-12354304.

[teamwork523]

In the coming version 2.1, it will check the resolved ip address byte length, and then apply ping or ping6 accordingly.

[aww-aww]

Great. I agree this is not super important, as it will affect very few people at this point, but from a doing the right thing perspective, it would be great to get to it sooner rather than later. Glad haokun is on it. It would be really nice to fix testing via Wi-Fi while adding the v6 hooks as it looked like the tweaks needed are largely in the same bits of code.

[teamwork523]

One of the common reason that MobiPerf will fail on ping/traceroute is that it could not find ping6 executable over IPv6. For the ping task, it will usually fall back to the http version ping (Java ping has specific port requirement). But current implementation uses AndroidHttpClient to setup the connection, which doesn't work over IPv6, so I switched to HttpURLConnection instead, and it works fine. For the traceroute task, I don't have a good solution for the alternatives of ping6, since we could not directly reset TTL for IP packets in Java.

So I dug a little deeper, and it seems that ping6 is on the handset but is
not setuid, which means only rooted phones can gain access to it, which
means it's a bad idea to use it.

On Tue, Feb 19, 2013 at 6:57 PM, Haokun notifications@github.com wrote:

One of the common reason that MobiPerf will fail on ping/traceroute is
that it could not find ping6 executable over IPv6. For the ping task, it
will usually fall back to the http version ping (Java ping has specific
port requirement). But current implementation uses AndroidHttpClient to
setup the connection, which doesn't work over IPv6, so I switched to
HttpURLConnection instead, and it works fine. For the traceroute task, I
don't have a good solution for the alternatives of ping6, since we could
not directly reset TTL for IP packets in Java.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/150#issuecomment-13813265.