USB debugging on physical device within a virtual machine development environment

Issue

I have a development environment set up in a Hyper-V virtual machine (Windows 10). Using Visual Studio 2019 as my IDE with Xamarin (a monodroid project). My physical device is unable to "passthrough" due to decisions made by the Hyper-V designers, from what I've read. I have also tried to use workarounds, unfortunately, the device does not show up (even in Device Manager) in the Guest machine.

I was unable to see the device (within the IDE) initially, however, after some research and work, I've managed to get the device showing. I used this to "trick" adb running on the Guest to see the device (which is connected to my physical machine). Host machine runs the script with IP 192.168.1.13 on port 6037 (adb daemon runs on 5037, which is default). Guest machine runs the script, with remotehost set to the Host IP, with the same port. I believe this configuration is fine, according to the documentation.

Unfortunately, even though I am able to deploy to my device, the debugger is unable to connect, and I receive Cannot start debugging: Cannot connect to 127.0.0.1:29300: No connection could be made because the target machine actively refused it 127.0.0.1:29301 Couldn't connect debugger. You can see more details in Xamarin Diagnostic output and the full exception on logs.

From what I have gathered, the debugger is trying to connect to localhost, and since the IDE is running within the Guest, the physical device will not be at localhost:29301. I assume if I could get the IDE to connect to 192.168.0.13:29301 (Host IP) instead, it would find the device, given that's where it is connected.

When I run adb devices, both the Host and Guest show the physical device, and after attempting to run the debugger, running adb forward --list, the forward rules are as such:

V4QBB18807150883 tcp:29300 tcp:29300
V4QBB18807150883 tcp:29301 tcp:29301

I can also see in Xamarin Diagnostics that setprop "debug.mono.extra" "debug=127.0.0.1:29302:29303,timeout=1585047190,loglevel=0,server=y" is executed. I assume manipulating that would give me some joy, but, I don't know how.

I'm not too familiar with adb and networking, so anyone with more experience in the matter could shed some light on my situation.

How can I get the debugger (within the Guest) to connect to my physical device?

PS: I've searched a lot before asking here. I know this exists: How can I connect to Android with ADB over TCP? and even after trying multiple answers on that page, I was unable to solve my problem.

Solution

After considerable amount of research, I came across this. Instead of searching for a way to setup adb port forwarding, I tried to see if there was a way to setup a USB passthrough via Hyper-V.

If using RDP is an option (directly connecting through "Hyper-V Manager" also works):

On host machine

1. Press Win+R type gpedit.msc and hit enter

2. Go to Computer configuration > Administrative templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Client > RemoteFX USB Device Redirection

3. Select the only GPO there and Enable it and change the access rights to "Administrators and Users"

On VM:

1. Press Win+R type gpedit.msc and hit enter

2. Go to Computer configuration > Administrative templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Device and Resource Redirection

3. Select GPO "Do not allow supported Plug and Play device redirection" and disable it

Reboot both machines...

You may need to force update Group Policy, as per this comment:

I had to force update group policy (gpupdate) for it to take effect. Just shutting down and restarting both host and vm wasn't enough. Thanks

Eventually, after carrying out those steps (I ran gpupdate and restarted both machines), I had an extra option of listed devices, "Other supported RemoteFX USB devices", within that was my physical device. After checking the tick box, the VM detected the device, without the need to port forward.

This can potentially cause security risks allowing a passthrough like this, however, my VM is not public. Only accessible via my Host. I would appreciate if someone in security could comment on the possible security risks just to inform myself and potential others that come across this post.

Answered By - user959631