-
Notifications
You must be signed in to change notification settings - Fork 18k
x/mobile: Android net.Dial("tcp", ip, port) returns "protocol not available" #12598
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
Comments
Updated Sep 14: Added Samsung Grand Prime and Chuwi Vi8 to working device list. |
Please try the below on the node and report back the result here, thanks.
|
Samsung SM-T320 (Broken device)
Samsung GT-N7102 (Broken device)
|
Samsung Grand Prime (Working device)
Asus Zenfone2 (Working device)
|
No failures, nice. Please try the below. When you see some error on connect, that would be a key to the root cause.
|
@mikioh Result of new test with syscall.bind + syscall.connect Samsung SM-T320 (Broken device)
Samsung GT-N7102 (Broken device)
No errors on broken devices. Strange. But this give us some extra ammo to work with. We are going to try using the syscall.connect method to create a tcp fd and then converting that fd -> file -> fileConn(). We have already successfully passed java tcp socket's fd to go and going this route to bypass this problem. If the syscall fd works, it would be a pure go problem bypass. |
The above two snippets are basic waltzes. The real net.Dial does more dancing; a) DNS resolution (I guess you always pass a literal address, so it won't be a problem), b) Non-blocking IO with runtime-integrated network poller. If (b) is related to the issue, for example, somehow the poller takes a wrong descriptor and the kernel says "hey, protocol not available", subsequent read/write ops might be fail too. |
We just confirmed that taking your syscall test code to generate a tcp ipv4 con fd and then converting it to a File{} then to a FileConn{} worked perfectly. We are now able to correctly use the socket and do stuff like TLS handshake on it. So the problem is somewhere in net.Dial. |
FWIW, I can't reproduce this is my OnePlus One (4.4.4). I used golang.org/x/mobile/example/bind as starting point, added android.permission.INTERNET to AndroidManifest.xml and added GetTestResult and a call to it to hello.go. I got: I/GoLog ( 5004): Starting go test... 173.205.184.7:80 My uneducated guess is weird interaction with IPv6 where your phones are connected. Does your test program fail on WiFi as well as on mobile data (2/3/4G)? |
I have just retested on my OnePlus 4.4.4 CM 11.0-XNPH44S on both WIFI and LTE and failed the tests. I have access to another OnePlus, CM 12 this time and will test that later. So these are the net environments I have the listed devices tested. Note that I did not test each device at every location. Just the sum of all locations where these tests have been performed.
So the issue from my pov:
I am as perplexed as you are, especially the fact you weren't able to reproduce the result on your OnePlus. |
Awesome testing coverage! :) I'm not sure you mentioned it, but is there any indication of a timing issue? That is, have you ever had a configuration fail and then suddenly succeed efter some number of retries? |
The thing is, it is also failing on the official Android Studio/Google supplied "Lollipop API 22 armv7 Emulator" image. Can you launch an v22 armv7 AVD and run the apk? I am using Nexus 4 768x1280 template. If the code is working on your emulator and failing on mine, then...I need a drink. |
And I have never had a broken device succeed in my tests and vice versa with working devices, over the the past few days. So not likely to be time related. |
@diegomontoya I created an AVD from the "Google APIs ARM (armeabi-v7a)" ABI and "Google APIs (API level 22)" Target on a Nexus 4 device 768x1280 with no skin. Same result, "GOT TCP!" every time. |
@eliasnaur I am going to assume at this point, based on your test results, that this may be isolated to my localized build env and the end product my env is producing. Let's swap apks. This way, we can clarify some fog here.
Please email me at xing@fictionpress.com and we can start exchanging some test files. |
Good idea. I've sent you a mail with apk and source diff. |
Looks like the root cause of this issue comes from somewhere between Android SDK and bindings generated by gomobile, and not related to the package net directly. Have a safe trip, mobile guys. |
Thanks a lot @mikioh for helping with this! @diegomontoya, is #12725 the root cause of this problem? |
Timeout. Closing. |
Updated Sep 14: Added Samsung Grand Prime and Chuwi Vi8 to working device list.
Go ver: devel +0b5bcf5 Sat Sep 12 08:34:52 2015 +0000 linux/amd64
Go Mobile ver: +65551d8 Fri Sep 11 20:14:45 2015 +0000 (android); androidSDK=/opt/Android/Sdk/platforms/android-23
Android Studio ver: 1.4 Beta3
Go Mobile Bind Plugin: 0.2.2
Build Env: Linux x86_64
Problem:
TCP networking code generated for Android packaged as .so in APK with studio and go-bind plugin will sometimes work, and most often times, result in "protocol not available" error in net.Dial().
Setup:
xml <uses-permission android:name="android.permission.INTERNET" />
Expectation:
Test Code:
At the bottom I have included the Go code and relevant Java code you can insert into any go mobile android project.
Working Devices:
Failed Devices:
I will try to update the device list with working/non-working as I find more devices to test on.
The text was updated successfully, but these errors were encountered: