[SOLVED] USB device drops out

Submitted by chibitul.smecher on #1

Hi,

I have a licensed VirtualHere USB server running on a Raspberry Pi at home. At work, I connect to my home network via Tailscale and use a USB device plugged into the Pi remotely. This setup worked flawlessly for about 4–5 months, but recently the USB device has started dropping out frequently, to the point where it is now unusable.

Let me say upfront that I believe this is likely an issue on my side; VirtualHere itself does not seem to be the problem.

I have done some basic troubleshooting. Pinging my Raspberry Pi from work typically shows 30–40 ms latency. Pinging a public DNS server (8.8.8.8) gives about half that, around 17–19 ms. So there is some added latency to my home network, though I am not sure whether to attribute that to Tailscale or my ISP.

Occasionally I see latency spikes of 200–300 ms when pinging the Pi. I initially suspected those were causing the dropouts, but here is the puzzling part: there is no clear correlation. The USB device sometimes drops out when the ping is normal (30–40 ms), and other times it stays connected through a 300 ms spike.

I am not sure what else to look into. Is there a diagnostic tool I can run, or a log file that would capture what is happening at the moment a dropout occurs? Any guidance would be appreciated.

Thank you.

Submitted by chibitul.smecher on Thu, 2026/04/02 - 11:13

#2

Actually I got home and decided to test the Virtual here connection from another laptop (Mac). I see the same issue, the connection drops out after a few minutes.

The raspberry Pi is a fresh install on a good SSD (last week I was running from MicroSD, I had the same issue). The Pi is wired to the router.

I really don't know what happened since the same Pi worked fine for many months before.

Submitted by Michael on Fri, 2026/04/03 - 08:54

#3

Not sure, try something like zerotier and see if thats better than tailscale

Submitted by chibitul.smecher on Fri, 2026/04/03 - 09:19

#4

This drop happens even when I am at home, on my own home network, without Tailscale. I am quite puzzled as the setup was rock solid for a year or more. This happens on my main Pi 4 (I purchased a license) and on a spare Pi 4 (with Virtual Here Server in trial mode)

I realized that I replaced the microSD in my Pi and I updated to a new Raspbian OS and a new version of VirtualHere Server.

I can easily roll back the Raspbian OS, I know where to find it. Where can I find older version of the VirtualHere Server and Client?

Thanks

Submitted by Michael on Sat, 2026/04/04 - 10:05

#5

There are no older versions of virtualhere. Its might be a bad ethernet cable or something like that

Submitted by chibitul.smecher on Sat, 2026/04/04 - 12:37

#6

Here is an update:

I installed install Raspbian OS "Bookworm" on the "spare" Pi and now the VirtualHere server seems stable. I didn't drop in about an hour.

The new Virtual Here server drops out on Raspbian OS "Trixie" on the same "spare" Pi

Tomorrow I will downgrade the other "main" Pi to Bookworm (which I bought the license for) to test if the connection is stable.

So at this time, it seems to be a Raspbian OS issue. I will update this thread as I find more information.

Thanks for the help.

Submitted by chibitul.smecher on Tue, 2026/04/07 - 12:27

#7

It appears the issue has been solved now.

In Bookwork, I was able to download the VH Server and run it from my Home Folder. It's been running fine for more than a year.

When I updated the Raspberry Pi to Trixie, I did the thing and the server starts fine but it's very unstable. What I didn't realize is that this happened after the Raspberry Pi OS update.

I now decided to use the script from GitHub which places the virtual here server in a different directory and that solved the issue.

I was curious why this is so I asked Claude:

Great find! The script is straightforward. Here's what it does and where everything lives:

Binary location: /usr/local/sbin/<binary_name>

Since your Pi 4 running Trixie 64-bit would report aarch64, the binary is vhusbdarm64, so the full path is /usr/local/sbin/vhusbdarm64.

Config location: /usr/local/etc/virtualhere/config.ini

Systemd service: /etc/systemd/system/virtualhere.service

The service runs the binary with -b (background/daemon mode) and -c /usr/local/etc/virtualhere/config.ini to explicitly point to the config file.

Why it's stable now: The key differences from running it manually out of your home folder are:

  1. Proper systemd service management. When you ran it manually, if the process crashed or the USB bus hiccupped, it just died. The systemd service can detect that and potentially restart it. More importantly, running under systemd gives the process a clean, predictable execution environment with proper cgroup isolation, no inherited shell environment variables, and no terminal session dependency.
  2. The -b flag (forking mode). This tells VirtualHere to properly daemonize itself. When you ran sudo ./vhusbdarm64from a terminal, it was running in the foreground tied to your shell session. Any SSH timeout, terminal signal, or even a stray SIGHUP could destabilize it.
  3. Home directory permissions (the Trixie change). Remember how we discussed that Debian 13 changed home directory permissions from 0755 to 0700? When VirtualHere ran from /home/pi/, the tighter permissions may have caused intermittent issues when the process tried to read its own binary or write its config/state. Under /usr/local/sbin/, there are no such restrictions.

Number 3 is probably the biggest factor explaining why Bookworm worked fine but Trixie didn't with the same manual approach. The install script places everything in system directories with standard permissions, sidestepping the Trixie home directory lockdown entirely.

 

Submitted by Michael on Wed, 2026/04/08 - 06:57

#8

OK thats good to know thanks for the feedback.