-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IPv6 breaks some tests #150
Comments
For ping and traceroute it's using the system ping binary, not ping6. On Wed, Jan 16, 2013 at 6:07 PM, Andy Warner [email protected]:
|
Not critical, but important. It should be trivial to detect if the On Wed, Jan 16, 2013 at 8:42 PM, Matt Welsh [email protected]:
|
In the coming version 2.1, it will check the resolved ip address byte length, and then apply ping or ping6 accordingly. |
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. |
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 On Tue, Feb 19, 2013 at 6:57 PM, Haokun [email protected] wrote:
|
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.
The text was updated successfully, but these errors were encountered: