Skip to content
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

Android Traceroute #572

Merged
merged 36 commits into from
Jul 26, 2018
Merged

Android Traceroute #572

merged 36 commits into from
Jul 26, 2018

Conversation

ssawchenko
Copy link
Contributor

@ssawchenko ssawchenko commented May 10, 2018

#159

Ok so, a looooooong time in the making. While I am certain there are still many issues with this, I was hoping to start a code review / round of testing to give me a good sanity check on what may be remaining with this feature.

Note, like... 18k files changed due to me removing a redundant boost library and creating an External-Code-Android folder to shelter Android from some problematic libraries. It may be easier to pull the code down and review it in an IDE rather than the diff window here due to that.

Summary from the initial ticket:

I was able to use https://android.googlesource.com/platform/external/iputils/+/master/tracepath.c as a bit of a guide to get ICMP packets sending (albeit over UDP) with incrementing TTLs and then read out the intermediate IPs at each hop. I believe this pretty much solidifies the validity of running a traceroute/path like function programatically in android.

Known issues:

  • Random crashes on Android 8.0. (see git issue for more details)

ssawchenko added 27 commits May 8, 2018 12:39
* Removed hard coded netinet folder, now using platform dependent libs
* Added basic ping to MapControllerWrapper JNI
* Moving to separate include dir as the netinet library iOS is using was causing conflicts with new Android traceroute attempts
* Had previously deleted netinet for an Android attempt; adding back to project fixed build issue.
@ssawchenko ssawchenko self-assigned this May 10, 2018
@ssawchenko ssawchenko requested a review from nbrooke May 10, 2018 23:52
@apike apike self-requested a review May 24, 2018 18:03
@abey
Copy link
Contributor

abey commented May 30, 2018

Tried to connect to the same bright spot in Romania(?). Android and iOS shows different data for some reason. Android doesn't seem to display the yellow line to destination

iOS
img_5479

Android
screenshot_2018-05-30-12-37-19

@ssawchenko
Copy link
Contributor Author

@nbrooke I have noticed some differences in the resulting path on iOS and Android at times, however, I have been comparing my Android trace with both a traceroute on my laptop and using a traceroute Android app I found in the play store, and my results have been almost spot on in comparison with those.

@apike
Copy link
Member

apike commented Jun 14, 2018

Testing this build it seems to work pretty well – we should get this wrapped up and released soon, so action plan:

  • @ssawchenko to fix up the commented code and straightforward code review comments
  • It sounds like Shayla needs to chat with Nigel about a couple of the more "C++y" issues here (memory leaks in particular) and decide whether it's worth getting some of Nigel's time to help fix them.

//free up the strings
jenv->DeleteLocalRef(from);
//oh, we need to free this too
jenv->DeleteLocalRef(probeWrapperClass);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on the local / global ref docs I found when validating the probeWrapper behaviour (https://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp1242), I don't think these calls are required. These should be freed automatically when this function returns.

* MapControllerWrapper and TracerouteUtil singletons; can now check isRunning to see if traceroute is running
* Do not start a new trace until the previous has finished
* Correctly clean up Timers for previous traceroutes
* Do not reuse probeWrapper
* More efficient string building
@ssawchenko
Copy link
Contributor Author

@abey Would you be able to run another round of testing on https://app.nevercode.io/#/project/4e922557-91dd-4635-8a56-bcbff3f9b239/build/cd2d9744-078f-4d62-973f-d1fc1c343429

@nbrooke Could you check the revisions I have made based on your suggestions?

@nbrooke nbrooke removed their assignment Jul 3, 2018
@abey
Copy link
Contributor

abey commented Jul 3, 2018

@ssawchenko Some comments:

  • If you tap the clock(?) icon to select the time range and tap any nodes on the globe, it will crash the app.
  • Android doesn't seem to have a lot of "ASN Hops" compared to iOS, I think this is related to differences in path finding in iOS and Android.
  • There are lines below a few labels in the iOS app (screenshot), I think we should add them in Android as well. Also, the text size seems to be larger on Android vis-a-vis iOS.
    img_0124

@apike
Copy link
Member

apike commented Jul 5, 2018

@abey The crash blocks merging this but the other items don't really, can you break those other two into separate issues?

@abey
Copy link
Contributor

abey commented Jul 5, 2018

Filed #576 and #577 for the other issues.

@apike
Copy link
Member

apike commented Jul 11, 2018

I think this is currently waiting on the crash fix Abey found above.

@ssawchenko
Copy link
Contributor Author

Will investigate crash first thing tomorrow.

@ssawchenko
Copy link
Contributor Author

ssawchenko commented Jul 12, 2018

@nbrooke @abey I have made the following changes:

  • Fixed the crash occurring when nodes were selected in timeline mode.
  • The destination node is now always added as the "end" if we have not reached it; traceroute highlights on iOS and Android should look much more similar now. (may fix Pathfinding is different on Android vis-a-vis iOS #576?)

@abey Would you be able to give this one more round of testing?
https://app.nevercode.io/#/project/4e922557-91dd-4635-8a56-bcbff3f9b239/build/528de277-ce09-4d65-87ea-8940ac914c65

@abey
Copy link
Contributor

abey commented Jul 12, 2018

@ssawchenko Looks good. 👍

Just one thing though. I think the time-out value is different in android and iOS. After the last IP Hop, android seems to take a lot more time compared to iOS. For example: I did a trace-route to the same location where android took 9264 ms while iOS took 3971 ms. I tried it with a few other locations and the trend was same.
Filed issues #578 , #579 & #580.

@ssawchenko
Copy link
Contributor Author

@abey I think there may be a difference in how each platform handles the hop timeout. Looks like on Android we are waiting one second per packet request, and then sending out a max of 3 probes. So we will be waiting at least the 3 seconds extra there when we reach an IP that is not returning us a response.

@apike I could spend more time digging into where this time is being spent exactly, however, my gut says it's not a super important issue at the moment. Thoughts?

@apike
Copy link
Member

apike commented Jul 19, 2018

Sounds like this is good to merge!

@ssawchenko
Copy link
Contributor Author

Not going to lie, squashing and merging that number of file changes makes me a little nervous XD

image

@nbrooke
Copy link
Member

nbrooke commented Jul 20, 2018

@ssawchenko Yeah, this seems like a change that might be worth doing an old fashioned regular merge on just to be on the safe side.

@ssawchenko
Copy link
Contributor Author

Discussed. Going to squash to reduce verbosity of commit history.

@ssawchenko ssawchenko merged commit 7984db0 into master Jul 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants