Stf: 'Failed to authenticate to ...' error with ADB connect command (ADB version 1.0.40 4986621)

[denis99999]

What is the issue or idea you have?
Using the latest version of ADB (1.0.40 4986621), the adb connect command return an error like Failed to authenticate to 10.193.14.128:15005, although the device has been well connected, it is confirmed by running adb devices -land adb shell commands, so it is not a blocking issue.

Note this error message does not appear while connecting directly to a device configured with a adb tcpip 5555 command, neither with lower version of ADB.

At stf-provider side, the ADB version is 1.0.36 but a I made also a test with an 1.0.40 version and the issue remains.

So, it seems the problem is perhaps located at stf-provider side using adbkit.

Does it only happen on a specific device? Please run adb devices -l and paste the corresponding row.
no device specific, but ADB specific from 1.0.40 4986621 version.

Please provide the steps to reproduce the issue.
see above.

What is the expected behavior?
ADB should return a message like connected to 10.193.14.128:15005

Do you see errors or warnings in the stf local output? If so, please paste them or the full log here.
No, just an info message like New remote ADB connection from ::ffff:10.193.14.11

Please run stf doctor and paste the output here.

debian@debian:~/stf-master$ stf doctor
2018-10-29T09:40:24.221Z INF/cli:doctor 7077 [*] OS Arch: x64
2018-10-29T09:40:24.224Z INF/cli:doctor 7077 [*] OS Platform: linux
2018-10-29T09:40:24.224Z INF/cli:doctor 7077 [*] OS Platform: 3.16.0-4-amd64
2018-10-29T09:40:24.225Z INF/cli:doctor 7077 [*] Using Node 8.9.3
2018-10-29T09:40:24.240Z INF/cli:doctor 7077 [*] Using ZeroMQ 4.0.5
2018-10-29T09:40:24.252Z INF/cli:doctor 7077 [*] Using ADB 1.0.36
2018-10-29T09:40:24.253Z ERR/cli:doctor 7077 [*] ProtoBuf is not installed (`protoc` is missing)
2018-10-29T09:40:24.269Z INF/cli:doctor 7077 [*] Using GraphicsMagick 1.3.20
2018-10-29T09:40:24.323Z INF/cli:doctor 7077 [*] Using RethinkDB 2.3.6~0jessie
debian@debian:~/stf-master$

[chagasaway]

+1

[zademaxfield]

+1

[koral--]

Please don't post comments with "+1" only or similar. It won't speed up fixing.
You can upvote this issue by adding reaction at the bottom of the first post.

[djcm75]

Hi
I use stf api inside a docker container to access devices connected on aother system.
The same docker image and api code works on production environment but fails on local environment
I get this response back from stf "success":true,"remoteConnectUrl":"192.168.187.109:7409"
followed by this line failed to authenticate to 192.168.187.109:7409
The user account associated with the container is root.

Please advise a fix

[djcm75]

Hi
I am facing the same issue, please see the attached logs

adb I 12-03 06:09:47 297 297 auth.cpp:473] Calling send_auth_response
adb I 12-03 06:09:47 297 297 auth.cpp:440] Calling send_auth_publickey
adb I 12-03 06:09:48 297 297 adb.cpp:145] 10.30.2.188:7401: offline
adb server killed by remote request
adb I 12-03 06:09:51 297 297 transport.cpp:337] BlockingConnectionAdapter(10.30.2.188:7401): stopping
adb I 12-03 06:09:51 297 446 transport.cpp:285] 10.30.2.188:7401: read failed: Success
adb I 12-03 06:09:51 297 297 transport.cpp:355] BlockingConnectionAdapter(10.30.2.188:7401): stopped
--- adb starting (pid 530) ---
adb I 12-03 06:11:10 530 530 main.cpp:56] Android Debug Bridge version 1.0.40
adb I 12-03 06:11:10 530 530 main.cpp:56] Version 4986621
adb I 12-03 06:11:10 530 530 main.cpp:56] Installed as /opt/android-sdk/platform-tools/adb
adb I 12-03 06:11:10 530 530 main.cpp:56]
adb I 12-03 06:11:10 530 530 auth.cpp:421] adb_auth_init...
adb I 12-03 06:11:10 530 530 auth.cpp:174] read_key_file '/root/.android/adbkey'...
adb I 12-03 06:11:10 530 530 auth.cpp:396] adb_auth_inotify_init...
adb I 12-03 06:11:16 530 543 transport.cpp:281] 10.30.2.188:7409: read thread spawning
adb I 12-03 06:11:16 530 544 transport.cpp:294] 10.30.2.188:7409: write thread spawning
adb I 12-03 06:11:16 530 530 auth.cpp:473] Calling send_auth_response
adb I 12-03 06:11:16 530 530 auth.cpp:440] Calling send_auth_publickey
adb I 12-03 06:11:16 530 530 adb.cpp:145] 10.30.2.188:7409: offline

[fightingAries]

Hi,
i am facing the same issue, what can i do to solve it?

[likezjuisee]

Hi,
i am facing the same issue, what can i do to solve it?

[jlvandusen]

adb connect 192.168.1.214

• daemon not running; starting now at tcp:5037
• daemon started successfully
  failed to authenticate to 192.168.1.214:5555

adb connect 192.168.1.214
already connected to 192.168.1.214:5555

adb devices
List of devices attached
192.168.1.214:5555 unauthorized

[vjmaiky]

any updates on this topic? any solutions? i;m inthe situatia that on my macbook pro i can connect to them using Android Debug Bridge version 1.0.40 Version 4797878, and from other mac minis i get failed to connect/authenticate....

[sorccu]

I took a brief look a few weeks ago. It seems that adbkit itself is fine, if used by itself everything works well. The issue seems to be that the auth handler in STF rejects the client due to the device already being in use, even if it wasn’t. Seems like events like autojoin may be firing in an incorrect order. I was not able to look into it further yet.

[likezjuisee]

I took a brief look a few weeks ago. It seems that adbkit itself is fine, if used by itself everything works well. The issue seems to be that the auth handler in STF rejects the client due to the device already being in use, even if it wasn’t. Seems like events like autojoin may be firing in an incorrect order. I was not able to look into it further yet.

Yes, I guess the auth flow is changed.

[vjmaiky]

if i close the active screen share and i do adb connect to it's ip..it works..it seems that i cannot be connected with share screen and via adb to it

[djcm75]

I solved it by downgrading adb to ver 1.0.39 if I use version 1.0.40 I constantly get the error message. Simply downgrading solved the problem. This was done on linux system, I never checked on windows

[vjmaiky]

how did you downgraded adb?

[djcm75]

i had an old version of adb preserved somewhere in git, i copied over the old file into /usr/bin/ folder. If you search google, you may find it somewhere.

[knallaf]

Downgrading adb to v.1.0.39 fixed the problem for me too. Attached, adb file for Linux (extracted from docker container sorccu/adb).
adb.zip

[koral--]

It seems that there is no need to downgrade ADB nor apply any workaround.
The message printed to console is incorrect but connection is actually successful.

[knallaf]

Yes, I agree with you, but in my case, the correct adb output is important as I use it to verify adb status by the automatic test framework.

[codeskyblue]

@sorccu It seems it is the problem of adbkit it self. The issue can be reproduced with the following steps.

Here I use adb 1.0.40

npm i -g adbkit
adbkit usb-device-to-tcp -p 20067 FFKDU17314004185

Then open another terminal

$ adb version
# should show adb version 1.0.40
$ adb connect 127.0.0.1:20067

The first terminal will show

Connect with `adb connect localhost:20067`
An error occured: Unrecognizable public key format
An error occured: Unrecognizable public key format
An error occured: Unrecognizable public key format
An error occured: Unrecognizable public key format
...

------- more ---------
Then I start adbkit with debug mode
DEBUG=adb:* adbkit usb-device-to-tcp -p 20067 6EB0217704000486

An error show that

adb:tcpusb:socket Received RSA public key 'UUFBQUFKVm1TY3REeXlyM1U3VnlrQmQ5S09LdG1UOGI5dEc2RGQ4cjc3bkdQWU1ZWm9vTzROZk04UnpldXRkcThxcThud0pzWEx4T2Z4bzJMVUdaRHZONk9EZWxpclBZMy8wU0hwWng1MkZhM1drTW40QllOcXp0bkdtQzBXaDZadjZlc21zOTNCY09TY2M5MEhyZEgvSnRPQk1tSUpMTHRzTVhkYmtscW1ocFNGUjlEQjJjSVJ3b1FjZDRWdEkyUjU0ZnRkUGFTMjRmWCt5Y0M2a05Md01CNUoyOGRFWXFHZHhjRTBJS0Y4ZmJVbHFLNnNSM2ROM1M1K25pYThtRjlSVGlMUEZsRjZXWHRVN1J1bVVMZUJYWUdvRVpubmpCald3b2lvejBFY0ZFMTFtNEloUFFMb005Yk04ZmgvSmlJaEMzNU9zNWE2N2tlN3lxa0NONWVWaTBkcUhac2NMTFBNL1JSNWV4VkswZ3RRY25GY1FmU0I0MkdCR2FYaVd4RHhyUG1EWW1QOWowMTNBbE5xMm1IbnpwWHZsd0hMZGQ2aGNwYWRZdUlOb1crWWJUelZCNHhDNE44a0tYa1FjWUdxWW53dGQvemFEQzRsbFBjeUhYTFlnM0ExMGtuQ2cra2ljNEJOQy9yRTAwR01rdGVFZDlvWTM2YTNmM29uaDAzZ2V6elI3U05xSVdjZFhWcXRuc3poUzdXYWt5WW1abzNDTExGMXA4VzA3QXBUd1lEa1VwN0VYd1oremo0NEh3aU5pV2hSbEFRMnZjRXBlcVdTV3FkSlRQVko4TjFOOGNmSVgvV3J2bURoUkpmSVhtbm45NDBCMDR0aHAvY0lhSFN4bVFUbjRnbFpLa0wxK21CbmlYc2JpazlVajFxYldndWNQNHBEOVFDdVVIbk12ZEw2TERZQUVBQVFBPQA='
An error occured: Unrecognaizable public key format

It seems little fix of the line code could fix the issue.
https://github.com/openstf/adbkit/blob/7f1581016f1b1d4a8f4a45597f33ca09beed7332/src/adb/auth.coffee#L22

I can make a pr if you want.

[jlvandusen]

@codeskyblue - how do I merge this into my HASS.IO install?

[codeskyblue]

What is HASS.IO?

[JayagopalVenkatesh93]

Hi,

I have deployed OpenSTF using Docker-Compose.
While I used Public Ip, I unable to remote connect devices using adb connect ip:port
I am using sorccu/adb docker image.
However I able to connect remote adb connect when running services hosted in local IP(Within LAN).

The ADB version in docker is

Android Debug Bridge version 1.0.39
Version 0.0.1-4500957
Installed as /opt/platform-tools/adb

In remote machine, I tried with 1.0.39 too
Android Debug Bridge version 1.0.40

Is any idea about this?

[dexterm]

did you run whereis adb
or which adb
sometimes the container may be using ver 1.0.40 in such cases copy the the older version or execute adb using the full path /home/usr/

[JayagopalVenkatesh93]

did you run whereis adb
or which adb
sometimes the container may be using ver 1.0.40 in such cases copy the the older version or execute adb using the full path /home/usr/

yes, I am using 1.0.39 version inside the container.

/ # adb version
Android Debug Bridge version 1.0.39
Version 0.0.1-4500957
Installed as /opt/platform-tools/adb

[JayagopalVenkatesh93]

issue is not resolved. Please give any idea.

[JayagopalVenkatesh93]

I am facing as follow

Facing issue only while OpenSTF goes live in Public IP domain.

Everything seems fine in local network.

[JayagopalVenkatesh93]

2019-05-03T15:57:47.853Z INF/device:plugins:connect 53 [XXXX] New remote ADB connection from ::ffff:49.207.180.110
provider_1              | 2019-05-03T15:57:48.246Z INF/device:plugins:connect 53 [XXX] New remote ADB connection from ::ffff:49.207.180.110
provider_1              | 2019-05-03T15:57:48.667Z INF/device:plugins:connect 53 [XXXX] New remote ADB connection from ::ffff:49.207.180.110
provider_1              | 2019-05-03T15:57:49.106Z INF/device:plugins:connect 53 [XXXX] New remote ADB connection from ::ffff:49.207.180.110
provider_1              | 2019-05-03T15:57:49.635Z INF/device:plugins:connect 53 [XXXX] New remote ADB connection from ::ffff:49.207.180.110
provider_1              | 2019-05-03T15:57:50.066Z INF/device:plugins:connect 53 [XXXX] New remote ADB connection from ::ffff:49.207.180.110
provider_1              | 2019-05-03T15:57:50.943Z INF/device:plugins:connect 53 [XXXX] New remote ADB connection from ::ffff:49.207.180.110
provider_1              | 2019-05-03T15:57:51.469Z INF/device:plugins:connect 53 [XXXX] New remote ADB connection from ::ffff:49.207.180.110
provider_1              | 2019-05-03T15:57:52.971Z INF/device:plugins:connect 53 [XXXX] New remote ADB connection from ::ffff:49.207.180.110
provider_1              | 2019-05-03T15:57:53.533Z INF/device:plugins:connect 53 [XXXX] New remote ADB connection from ::ffff:49.207.180.110
provider_1              | 2019-05-03T15:57:53.947Z INF/device:plugins:connect 53 [XXXX] New remote ADB connection from ::ffff:49.207.180.110
provider_1              | 2019-05-03T15:57:54.411Z INF/device:plugins:connect 53 [XXXX] New remote ADB connection from ::ffff:49.207.180.110
provider_1              | 2019-05-03T15:57:55.064Z INF/device:plugins:connect 53 [XXXX] New remote ADB connection from ::ffff:49.207.180.110
provider_1              | 2019-05-03T15:57:55.941Z INF/device:plugins:connect 53 [XXXX] New remote ADB connection from ::ffff:49.207.180.110
provider_1              | 2019-05-03T15:57:56.417Z INF/device:plugins:connect 53 [XXXX] New remote ADB connection from ::ffff:49.207.180.110
provider_1              | 2019-05-03T15:57:57.130Z INF/device:plugins:connect 53 [XXXX] New remote ADB connection from ::ffff:49.207.180.110
provider_1              | 2019-05-03T15:57:57.308Z INF/device:plugins:connect 53 [XXXX] New remote ADB connection from ::ffff:49.207.180.110
provider_1              | 2019-05-03T15:57:57.891Z INF/device:plugins:connect 53 [XXXX] New remote ADB connection from ::ffff:49.207.180.110
provider_1              | 2019-05-03T15:57:58.402Z INF/device:plugins:connect 53 [XXXX] New remote ADB connection from ::ffff:49.207.180.110

It seems fingerprint is not added. Also popup is not shown in STF Client.

[JayagopalVenkatesh93]

Issue fixed with patch update. Likely the system reboot cools off the issue.

Thanks a lot.

[kolyakrasnik]

@TheBogan Which patch are you talking about?

[sqamike]

The critical step in getting this to work is disconnecting the usb cable after issuing the adb connect xx.x.x.xx:5555 command. At this point you are connected but unauthorized. Execute adb kill-server and re-issue the connect command. Verify with execution of adb shell date.