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

"Internet connection lost" appears immediately when starting installer on macOS or Windows #1847

Closed
UniversalSuperBox opened this issue Mar 11, 2021 · 6 comments · Fixed by #1913
Labels
bug a bug in the software itself

Comments

@UniversalSuperBox
Copy link
Member

UniversalSuperBox commented Mar 11, 2021

You can work around this issue by downloading an older version of the UBports Installer, such as 0.8.6. After this issue is closed, there is no reason to download an older version of the UBports Installer any more.

UBports Installer in debug mode showing 'internet connection lost'

When starting the installer 0.8.7 or the prerelease 0.8.8, the "internet connection lost" message appears immediately. It does not appear that it's actually made any network requests at this point, or it's made requests that the Chrome devtools can't see.

The only log is:

info: Welcome to the UBports Installer version 0.8.8-beta!

I do feel rather welcomed, at least!

@NeoTheThird
Copy link
Member

dev tools only show requests made from the ui process, not from the main process (where all the magic happens nowadays). Requests made at startup include fetching the list of supported devices, as well as confirming the running version of the installer is the latest version.

@NeoTheThird NeoTheThird added the bug a bug in the software itself label Mar 12, 2021
@Keneda-ut
Copy link

Seems a reccurrent issue :
#1854
#1868

@UniversalSuperBox
Copy link
Member Author

UniversalSuperBox commented Apr 11, 2021

More investigation today reveals that the issue is the Heimdall binary exiting without any output on Windows and macOS. This is even happening with the newest version of Heimdall available from their website.

PS C:\Users\Dalton\Downloads\Heimdall Suite> .\heimdall.exe
PS C:\Users\Dalton\Downloads\Heimdall Suite> .\heimdall.exe help
PS C:\Users\Dalton\Downloads\Heimdall Suite> .\heimdall.exe detect
PS C:\Users\Dalton\Downloads\Heimdall Suite> .\heimdall.exe help
PS C:\Users\Dalton\Downloads\Heimdall Suite> $LASTEXITCODE
-1073741515

This may be the exit code STATUS_DLL_NOT_FOUND.

@UniversalSuperBox
Copy link
Member Author

There are two problems here:

  1. The UBports Installer reports "No internet connection" when any of its tools (adb, fastboot, heimdall) fail to run their wait() promise, as "no device" in index.js bubbles up to "failed to resolve device name" in core.js accidentally. I believe that this error should be caught in plugins.wait() instead.
  2. There is no way that the Heimdall plugin has ever worked on Windows or macOS. Heimdall requires a shared object or dll file of libusb 1.0 be available on the system prior to running. On Windows, it also requires the Microsoft Visual C++ 2012 Redistributables for x86 (NOT x86_64) are installed.

@UniversalSuperBox
Copy link
Member Author

The issue with Heimdall is now filed as https://gitlab.com/ubports/installer/android-tools-bin/-/issues/1. I still don't think it should cause an "Internet connection lost" error.

@UniversalSuperBox
Copy link
Member Author

UniversalSuperBox commented Apr 12, 2021

The error on macOS is actually different:

error: Failed to wait on a plugin: Error: {"error":{"code":1,"cmd":"adb -P 5037 wait-for-any-any"},"stderr":"* daemon not running; starting now at tcp:5037\nADB server didn't ACK\nFull server startup log: /var/folders/8h/2l6_vm5j1q12cj21_mgm1tm00000gn/T//adb.501.log\nServer had pid: 3793\n--- adb starting (pid 3793) ---\nadb I 04-12 10:06:33  3793 26088 main.cpp:62] Android Debug Bridge version 1.0.41\nadb I 04-12 10:06:33  3793 26088 main.cpp:62] Version 30.0.4-6686687\nadb I 04-12 10:06:33  3793 26088 main.cpp:62] Installed as adb\nadb I 04-12 10:06:33  3793 26088 main.cpp:62] \nadb E 04-12 10:06:33  3791 26087 usb_osx.cpp:161] Unable to create an interface plug-in (e00002be)\nadb E 04-12 10:06:33  3793 26094 usb_osx.cpp:161] Unable to create an interface plug-in (e00002be)\nadb I 04-12 10:06:33  3791 26081 auth.cpp:417] adb_auth_init...\nadb I 04-12 10:06:33  3791 26081 auth.cpp:152] loaded new key from '/Users/ddurst2/.android/adbkey' with fingerprint 1146A2FEC71BDF2822FE7518B92EFA3C335E3CE6133C1DA631BF7B096D1A15CE\nadb F 04-12 10:06:34  3793 26088 main.cpp:153] could not install *smartsocket* listener: Address already in use\n\n* failed to start daemon\nerror: cannot connect to daemon"}

Interesting enough, the error doesn't occur on the start-server command, but on the first command after it. It appears that the server starts correctly, but maybe it crashes, or maybe the new client tries to use it too quickly.

ADB's log file sheds almost no light on the situation:

--- adb starting (pid 3791) ---
adb I 04-12 10:06:33  3791 26081 main.cpp:62] Android Debug Bridge version 1.0.41
adb I 04-12 10:06:33  3791 26081 main.cpp:62] Version 30.0.4-6686687
adb I 04-12 10:06:33  3791 26081 main.cpp:62] Installed as /Users/ddurst2/development/ubports-installer/node_modules/android-tools-bin/dist/darwin/x86/adb
adb I 04-12 10:06:33  3791 26081 main.cpp:62] 
--- adb starting (pid 3793) ---
adb I 04-12 10:06:33  3793 26088 main.cpp:62] Android Debug Bridge version 1.0.41
adb I 04-12 10:06:33  3793 26088 main.cpp:62] Version 30.0.4-6686687
adb I 04-12 10:06:33  3793 26088 main.cpp:62] Installed as /Users/ddurst2/development/ubports-installer/node_modules/android-tools-bin/dist/darwin/x86/adb
adb I 04-12 10:06:33  3793 26088 main.cpp:62] 
adb E 04-12 10:06:33  3791 26087 usb_osx.cpp:161] Unable to create an interface plug-in (e00002be)
adb E 04-12 10:06:33  3793 26094 usb_osx.cpp:161] Unable to create an interface plug-in (e00002be)
adb I 04-12 10:06:33  3791 26081 auth.cpp:417] adb_auth_init...
adb I 04-12 10:06:33  3791 26081 auth.cpp:152] loaded new key from '/Users/ddurst2/.android/adbkey' with fingerprint 1146A2FEC71BDF2822FE7518B92EFA3C335E3CE6133C1DA631BF7B096D1A15CE
adb F 04-12 10:06:34  3793 26088 main.cpp:153] could not install *smartsocket* listener: Address already in use
adb E 04-12 10:06:34  3791 26087 usb_osx.cpp:161] Unable to create an interface plug-in (e00002be)
adb E 04-12 10:06:35  3791 26087 usb_osx.cpp:161] Unable to create an interface plug-in (e00002be)
adb E 04-12 10:06:36  3791 26087 usb_osx.cpp:161] Unable to create an interface plug-in (e00002be)
adb E 04-12 10:06:37  3791 26087 usb_osx.cpp:161] Unable to create an interface plug-in (e00002be)
...continues forever

The same error occurs after a reboot, so I don't think it's a problem of adb already running.

UniversalSuperBox added a commit that referenced this issue Apr 12, 2021
Prior to this change, it was possible for errors initializing or waiting
on plugins to go undetected. Errors in wait() would bubble up to the
"no-network" error, which has been even more confusing for users.

Related, but does not fix:
#1847
UniversalSuperBox added a commit to ubports/promise-android-tools that referenced this issue Apr 14, 2021
Since we don't return the start-server exec promise, clients would run
more adb commands before the server was up. This would cause "Connection
Refused" to be returned to the second adb command, and everyone was
confused.

Actually returning the exec allows downstreams to wait on the server
starting.

Ref: ubports/ubports-installer#1847
UniversalSuperBox added a commit that referenced this issue Apr 16, 2021
Prior to this change, it was possible for errors initializing or waiting
on plugins to go undetected. Errors in wait() would bubble up to the
"no-network" error, which has been even more confusing for users.

Related, but does not fix:
#1847
@UniversalSuperBox UniversalSuperBox unpinned this issue Apr 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug a bug in the software itself
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants