[Bug]: Random USB Disconnection

[MaxBlack84840]

Describe the bug

Hello, sorry for my poor English.
I'm using WinVRn on PikaOS. I'm a new Linux user and I'm impressed by Steam games. Thanks to the developers. I play Automobilista 2, Project Cars 2, and ACEvo. I use WiVRn with a USB connection. The results are perfect.
I sometimes experience disconnections. Do you have a solution in progress to stabilize this connection? (It's not a cable or hardware issue.)

My setup: Alienware X16, NVIDIA GeForce RTX 4080 Laptop GPU, QUEST 3.
Thank you.

Steps to Reproduce

No response

Expected behavior

No response

WiVRn Version

26.2.2

Installation method

flatpack

Server Config

No response

Server Logs

No response

What GPU did the bug occur on?

NVIDIA

Vulkan Info

What HMD did the bug occur on?

Quest 3

ADB Logs

[xytovl]

Without any log, it is not possible to know the root cause. This may be a problem with adb itself.

In order to capture adb logs:

• stop adb with adb kill-server
• restart it with ADB_TRACE=all adb start-server
• get the pid of adb with pidof adb, there should be a single line
• run your wired WiVRn session until you get a disconnection
• logs are in `/proc//fd/1

This may help understand what is causing the disconnection.

[MaxBlack84840]

Hi,
adb kill-server: OK
ADB_TRACE=all adb start-server: OK
pidof adb: 52842
Are the logs located in /proc//fd/1? Unknown folder?

Okay, I understand: I assume: /proc/52842/fd/1
and the pidof adb changes with each connection.

I'll retrieve the log next time I disconnect.
Thanks for your help.

[alexcrea]

Hi ! I got similar issue and got told about this issue for abd debug steps
running pretty updated arch, wivrn-full-git (26.2-59-g42c64a65)

I do want to say I got 2-3 "disconnect but can reconnect" and last one disconnect with no possibility of reconnection

file is about 1GB uncompressed, so need to upload compressed log outside of gh
https://www.dropbox.com/scl/fi/gcgow2kgvhvecljclj4uv/adblog.zip?rlkey=lx5j6eq9rjujvjwppfgodb6f5&st=i9los068&dl=0

after that I tried killing and restarting the adb server but it won't restart

02-19 20:26:28.725 27958 27958 D adb     : adb_trace.cpp:198 Android Debug Bridge version 1.0.41
02-19 20:26:28.725 27958 27958 D adb     : adb_trace.cpp:198 Version 35.0.2-android-tools
02-19 20:26:28.725 27958 27958 D adb     : adb_trace.cpp:198 Installed as /usr/bin/adb
02-19 20:26:28.725 27958 27958 D adb     : adb_trace.cpp:198 Running on Linux 6.18.9-arch1-2 (x86_64)
02-19 20:26:28.725 27958 27958 D adb     : adb_trace.cpp:198 
02-19 20:26:28.725 27958 27958 D adb     : commandline.cpp:1697 Using server socket: tcp:5037
02-19 20:26:28.725 27958 27958 D adb     : adb_client.cpp:358 adb_connect: service: host:start-server
02-19 20:26:28.725 27958 27958 D adb     : adb_client.cpp:160 _adb_connect: host:version
* daemon not running; starting now at tcp:5037
02-19 20:26:28.732 27959 27959 D adb     : adb_trace.cpp:198 Android Debug Bridge version 1.0.41
02-19 20:26:28.732 27959 27959 D adb     : adb_trace.cpp:198 Version 35.0.2-android-tools
02-19 20:26:28.732 27959 27959 D adb     : adb_trace.cpp:198 Installed as /usr/bin/adb
02-19 20:26:28.732 27959 27959 D adb     : adb_trace.cpp:198 Running on Linux 6.18.9-arch1-2 (x86_64)
02-19 20:26:28.732 27959 27959 D adb     : adb_trace.cpp:198 
02-19 20:26:28.732 27959 27959 D adb     : commandline.cpp:1697 Using server socket: tcp:5037
ADB server didn't ACK
Full server startup log: /tmp/adb.1000.log
Server had pid: 27959
--- adb starting (pid 27959) ---
02-19 20:26:28.732 27959 27959 I adb     : main.cpp:63 Android Debug Bridge version 1.0.41
02-19 20:26:28.732 27959 27959 I adb     : main.cpp:63 Version 35.0.2-android-tools
02-19 20:26:28.732 27959 27959 I adb     : main.cpp:63 Installed as /usr/bin/adb
02-19 20:26:28.732 27959 27959 I adb     : main.cpp:63 Running on Linux 6.18.9-arch1-2 (x86_64)
02-19 20:26:28.732 27959 27959 I adb     : main.cpp:63 
02-19 20:26:28.732 27959 27959 D adb     : usb_libusb.cpp:1060 initializing libusb...
02-19 20:26:28.744 27959 27962 D adb     : usb_libusb.cpp:1024 libusb hotplug thread started
02-19 20:26:28.745 27959 27962 D adb     : usb_libusb.cpp:1031 libusb hotplug: device arrived
02-19 20:26:28.745 27959 27959 D adb     : transport_local.cpp:233 transport: local client init
02-19 20:26:28.745 27959 27962 D adb     : usb_libusb.cpp:1031 libusb hotplug: device arrived
02-19 20:26:28.745 27959 27962 D adb     : usb_libusb.cpp:1031 libusb hotplug: device arrived
02-19 20:26:28.745 27959 27959 I adb     : auth.cpp:416 adb_auth_init...
02-19 20:26:28.745 27959 27965 D adb     : transport_local.cpp:191 transport: client_socket_thread() starting
02-19 20:26:28.745 27959 27962 D adb     : usb_libusb.cpp:1031 libusb hotplug: device arrived
02-19 20:26:28.745 27959 27966 D adb     : usb_libusb.cpp:907 device connected: usb:2-2.1
02-19 20:26:28.745 27959 27962 D adb     : usb_libusb.cpp:1031 libusb hotplug: device arrived
02-19 20:26:28.745 27959 27966 D adb     : usb_libusb.cpp:404 skipping non-adb interface at 2-2.1 (interface 0)
02-19 20:26:28.745 27959 27966 D adb     : usb_libusb.cpp:417 found potential adb interface at 2-2.1 (interface 1)
02-19 20:26:28.745 27959 27966 D adb     : usb_libusb.cpp:922 constructed LibusbConnection for device 1WMHHA600E1492 (usb:2-2.1)
02-19 20:26:28.745 27959 27966 D adb     : transport.cpp:822 transport: 1WMHHA600E1492 registered
02-19 20:26:28.745 27959 27959 I adb     : auth.cpp:152 loaded new key from '/home/alexd/.android/adbkey' with fingerprint 298F8BB82A83BE562D70B15DF1142945F5F5FF9C73DD13691F9F4E237A44D641
02-19 20:26:28.745 27959 27959 I adb     : auth.cpp:391 adb_auth_inotify_init...
02-19 20:26:28.745 27959 27959 D adb     : main.cpp:232 Event loop starting
02-19 20:26:28.745 27959 27959 D adb     : fdevent_epoll.cpp:165 (fdevent 0: fd 5 R) got events 0x1
02-19 20:26:28.745 27959 27959 D adb     : usb_libusb.cpp:404 skipping non-adb interface at 2-2.1 (interface 0)
02-19 20:26:28.745 27959 27959 D adb     : usb_libusb.cpp:417 found potential adb interface at 2-2.1 (interface 1)
02-19 20:26:28.746 27959 27959 W adb     : usb_libusb.cpp:488 failed to get serial from device at 2-2.1LIBUSB_ERROR_IO
02-19 20:26:28.746 27959 27959 D adb     : usb_libusb.cpp:624 successfully opened adb device at 2-2.1, bulk_in = 0x82, bulk_out = 0x2
02-19 20:26:28.747 27959 27959 E adb     : usb_libusb.cpp:639 failed to clear halt on device '' endpoint 0x82: LIBUSB_ERROR_OTHER
02-19 20:26:28.747 27959 27959 I adb     : transport.cpp:1153 1WMHHA600E1492: connection terminated: failed to clear halt on device '' endpoint 0x82: LIBUSB_ERROR_OTHER
02-19 20:26:28.747 27959 27959 D adb     : adb.cpp:301 Calling send_connect
02-19 20:26:28.747 27959 27959 D adb     : transport.cpp:570 1WMHHA600E1492: to remote: [CNXN] arg0=0x1000001 arg1=0x100000 (len=291) 686f73743a3a66656174757265733d73 host::features=s [truncated]
02-19 20:26:28.747 27959 27959 D adb     : usb_libusb.cpp:328 USB write: [CNXN] arg0=0x1000001 arg1=0x100000 (len=291) 

* failed to start daemon
error: cannot connect to daemon

hopefully not an hardware issue, cable age is only 1 month

[xytovl]

The error is probably this one:

02-19 20:01:11.420  9965  9969 I adb     : transport.cpp:1153 1WMHHA600E1492: connection terminated: libusb write failed

It could be a physical error (unplugged cable, broken wire, USB controller error) or a bug in ADB.
I had to set ADB_LIBUSB=0 to workaround errors with Quest 1, you can check if it behaves differently.

[alexcrea]

I do not reject idea of broke wire or USB controller error and do think it may be that or partially that (even if I really dislike that possibility)

After an ok session, I got a crash. Tried to kill and restart server with ADB_LIBUSB=0 and it does start
but adb devices return an empty list*
*after trying to connect my phone the phone does appear in the device list only headset is absent

something I think could be relevant: I have not updated my headset (quest 2) for some time as I did not had to

(may be related)
I also just got a weird issue: when I was setting up my vr to try to test the proposed, I connected my headset & started wayvr and vrc, left my headset unintended for a short while and came back with vrc still open, but with the "select application" of WiVRn as display.
I was able to rotate my head with no issue clicked on wayvr I think making the frame freeze (still image in 3d space with black contour)
this is not the first time it has happened. It has been solved by upluging and repluging my headset and followed the ok session

I will try to plug the headset in another port and pray (will edit if happens to other ports too)
edit: plugging it to another port seems to "make it come back" in adb devices
It may just be hardware issue for my part where it is badly plugged ? issue is I did verify connection by unpluging & repluging but I assume my case is usb plug hardware failure. sorry ! (will create a new comment if I find evidence of the contrary)

[MaxBlack84840]

Hi,
I just had a disconnection at 7:10 PM.

--- adb starting (pid 4980) ---
02-21 18:13:04.991  4980  4980 I adb     : main.cpp:63 Android Debug Bridge version 1.0.41
02-21 18:13:04.991  4980  4980 I adb     : main.cpp:63 Version 35.0.2-android-tools
02-21 18:13:04.991  4980  4980 I adb     : main.cpp:63 Installed as /usr/bin/adb
02-21 18:13:04.991  4980  4980 I adb     : main.cpp:63 Running on Linux 6.19.2-200.nobara.fc43.x86_64 (x86_64)
02-21 18:13:04.991  4980  4980 I adb     : main.cpp:63 
02-21 18:13:04.991  4980  4980 I adb     : auth.cpp:416 adb_auth_init...
02-21 18:13:04.991  4980  4980 I adb     : auth.cpp:152 loaded new key from '/home/maxblack/.android/adbkey' with fingerprint F4A2464DDA2205004443DBF821C556850E01FCB490BDCED8A9DDA5202E2E5993
02-21 18:13:04.991  4980  4980 I adb     : auth.cpp:391 adb_auth_inotify_init...
02-21 18:40:25.666  4980  8706 I adb     : transport.cpp:341 2G0YC5ZF9Y02KH: read thread spawning
02-21 18:40:25.666  4980  8707 I adb     : transport.cpp:313 2G0YC5ZF9Y02KH: write thread spawning
02-21 18:40:25.668  4980  4980 I adb     : transport.cpp:1710 fetching keys for transport 2G0YC5ZF9Y02KH
02-21 18:40:25.668  4980  4980 I adb     : auth.cpp:468 Calling send_auth_response
02-21 18:40:25.684  4980  4980 I adb     : adb.cpp:181 2G0YC5ZF9Y02KH: offline
02-21 19:09:51.912  4980  8706 I adb     : transport.cpp:345 2G0YC5ZF9Y02KH: read failed: Cannot send after transport endpoint shutdown
02-21 19:09:51.912  4980  8707 E adb     : transport_usb.cpp:136 remote usb: 1 - write terminated: Cannot send after transport endpoint shutdown
02-21 19:09:51.912  4980  8706 I adb     : transport.cpp:1153 2G0YC5ZF9Y02KH: connection terminated: read failed
02-21 19:09:51.912  4980  4980 I adb     : adb.cpp:181 2G0YC5ZF9Y02KH: offline
02-21 19:09:51.912  4980  4980 I adb     : transport.cpp:836 destroying transport 2G0YC5ZF9Y02KH
02-21 19:09:51.912  4980  4980 I adb     : transport.cpp:413 BlockingConnectionAdapter(2G0YC5ZF9Y02KH): stopping
02-21 19:09:51.912  4980  4980 I adb     : transport.cpp:431 BlockingConnectionAdapter(2G0YC5ZF9Y02KH): stopped
02-21 19:09:51.912  4980  4980 I adb     : transport.cpp:300 BlockingConnectionAdapter(2G0YC5ZF9Y02KH): destructing
02-21 19:09:51.912  4980  4980 I adb     : transport.cpp:406 BlockingConnectionAdapter(2G0YC5ZF9Y02KH): already stopped
02-21 19:09:52.914  4980  4980 W adb     : sockets.cpp:304 timeout expired while flushing socket, closing
02-21 19:09:54.227  4980 23272 I adb     : transport.cpp:341 2G0YC5ZF9Y02KH: read thread spawning
02-21 19:09:54.228  4980 23273 I adb     : transport.cpp:313 2G0YC5ZF9Y02KH: write thread spawning
02-21 19:09:54.228  4980  4980 I adb     : transport.cpp:1710 fetching keys for transport 2G0YC5ZF9Y02KH
02-21 19:09:54.228  4980  4980 I adb     : auth.cpp:468 Calling send_auth_response
02-21 19:09:54.230  4980  4980 I adb     : adb.cpp:181 2G0YC5ZF9Y02KH: offline

I was in 3rd place in a race on AMS2. It's random; yesterday I played for about an hour without getting disconnected...

[galister]

It's hard to say, but it seems like the adb connection itself breaks down. This is likely not something that WiVRn can prevent. We could however do some auto-reconnect magic to minimize the damage.

[MaxBlack84840]

I switched back to Windows 11 to play games. Until now, I rarely experienced disconnections under Windows, but now there are a few... I'm going to order a new cable.