usbipd detach not exiting properly

[bimmerdriver]

I'm using usbipd-win with WSL2 and Ubuntu 22.04 on a desktop computer running Windows 10 22H2. They are all up-to-date.

My usecase for usbipd-win requires the USB device to be attached before a service in default.target starts. I'm trying to write a systemd service to attach the device. I've never done this before, but it seems simple enough. I need the service to support start, stop and restart.

• start will attach the device
• stop will detach the device
• restart will detach and attach the device

UPDATE: Since I wrote this post, I understand that systemctl restarts a service by issuing stop and start and there is not a restart. Regardless, that doesn't change that the detach command appears to not be exiting properly.

I wrote a bash script that takes one argument which can be start, stop or restart.

The output from the script with the restart argument is the following:

usbipd: error: There is no device with busid '4-4'.

(busid 4-4 is the actual busid of the particular device I'm testing with.)

In order to see if the problem was being caused by running the windows commands from within the WSL2 VM, I tested the commands on windows and found that the same thing happens, so I think there is a problem specifically with the usbipd detach command.

Here is are the commands to replicate the problem in batch file:

usbipd attach --wsl --busid=4-4
usbipd detach --busid=4-4
usbipd attach --wsl --busid=4-4

Here is the output:

`C:\WINDOWS\system32>usbipd attach --wsl --busid=4-4
usbipd: info: Using WSL distribution 'Ubuntu-22.04' to attach; the device will be available in all WSL 2 distributions.
usbipd: info: Using IP address 172.22.192.1 to reach the host.

C:\WINDOWS\system32>usbipd detach --busid=4-4

C:\WINDOWS\system32>usbipd attach --wsl --busid=4-4
usbipd: error: There is no device with busid '4-4'.`

If I run a stand-alone usbipd detach command, it displays a windows command prompt, but it doesn't output an info message like usbipd attach and the command prompt isn't working properly. For example, I can't up or down arrow to rerun a command, even if I enter CTRL-C to force an exit. I found that by clicking the mouse in the window, it seems to exit, after which I can up or down arrow the command line.

After the usbipd detach command exits, if I run it again, I get the following output:

C:\WINDOWS\system32>usbipd detach --busid=4-4 usbipd: info: Device with busid '4-4' was already not attached.

Based on these findings, the only conclusion I can reach is that the usbipd detach command doesn't exit properly.

Is this a known problem? Is there a work-around?

[dorssel]

Whenever a device is attached or detached, the USB port is reset to load a different driver. This essentially is an unplug/replug. For a brief moment, Windows doesn't see the device until the reset is complete and the device is enumerated again.

When you run detach/attach in a batch script, then the attach is "too quick". This results in:

usbipd: error: There is no device with busid '4-4'.

You probably need a "sleep" after every detach, to give Windows some time to re-detect the device. (Note: the way usbipd attach works makes this unnecessary after an attach).

The stuck console is probably because you selected something in the console. That will freeze the console until you click again. It has nothing to do with usbipd detach itself.

[bimmerdriver]

I'm not sure what you mean when you say I "selected something in the console". I opened a Windows command prompt with admin rights, I attached the device and then I detached the device. After that, I pressed up-arrow every second or so for a minute and it didn't work even after a minute. I left it alone completely for around 15 seconds and finally when I pressed up-arrow, it actually responded. I tried this a second time and I clicked in the window immediately after entering the detach command. Right after I clicked in the window, up-arrow worked. I've never seen this behaviour with any other command.

[dorssel]

I'm quite sure it isn't usbipd that's causing this. usbipd detach simply removes a registry entry. It doesn't actually do the detach, that's the service. It completes immediately and does nothing with USB itself. However, maybe the USB driver stack is tied up putting the original drive back, and messes with your input device as well. I don't know. If you are not using the device in Windows, you can always use usbipd bind --force to permanently set the stub driver (if that's what's causing this).

I do know that Windows Terminal (and maybe also cmd.exe) "freezes" if you select any text, until you complete the copy, or click in the Window again...

[bimmerdriver]

I put in a 1 second timeout after the detach command and the subsequent attach command worked. Really strange...

[bimmerdriver]

It's definitely hung after the detach, not the attach. The error message "usbipd: error: There is no device with busid '4-4'." occurs when the attach command is issued, presumably because the device hasn't been fully detached.

I tried testing with this command:

bash -c "/mnt/c/'Program Files'/usbipd-win//usbipd.exe attach --wsl --busid=4-4; /mnt/c/'Program Files'/usbipd-win//usbipd.exe detach --busid=4-4; sleep 5; /mnt/c/'Program Files'/usbipd-win//usbipd.exe attach --wsl --busid=4-4"

Even a long sleep didn't prevent the it from being hung.

If I execute a detach after an attach (either separately or within bash -c "...", the command prompt is hung until I mouse click in the window.

[dorssel]

Oh, wait a second... You are running usbipd.exe (a Windows executable) from within WSL? Why are you doing that?
Why don't you just run a native Linux usbip client when you want to attach from within WSL?

What you are doing now is: run WSL which forwards the console to Windows, in WSL you run a Windows program, which forwards the console to WSL. And usbipd attach runs a command in WSL, which forwards the console to Windows. You are looping a lot there: Windows -> WSL -> Windows -> WSL.

usbipd.exe --wsl is a convenience command to attach/detach from within Windows. It essentially is a macro to run a native Linux usbip client tool in WSL. When you are already in WSL, you should be using a Linux client tool directly...

[dorssel]

And when you do this from a systemd service that starts at WSL bootup, you run into: WSL is booting, runs usbipd.exe in Windows, which wants to run usbip in WSL, which requires an already booted WSL -> circular requirement...

[bimmerdriver]

The only reason I'm using usbipd.exe on windows is because there isn't a linux version of usbip for the version of linux used by WSL2. If I type which usbip on linux, there is no reply.

[dorssel]

You just need to install the right linux-tools package for your distribution. It is distro-dependent, though...

[dorssel]

I saw you asked for a dedicated tools package for WSL. However, such tool packages already exist. They just happen to be distribution specific. For Ubuntu it is linux-tools-virtual.

[bimmerdriver]

All I'm trying to do is attach the USB device after booting, after the network is online, but before other the services that require it are started. This should work out of the box, but unfortunately, the WSL team at Microsoft apparently doesn't view this as a priority. I wrote a service unit and it works, other than the fact that systemctl hangs when systemctl stop or restart are used because usbipd.exe detach doesn't exit properly.

[bimmerdriver]

I found a usbip binary that works.

Here is the output of usbip list with two devices attached:

$ /usr/lib/linux-tools/5.15.0-101-generic/usbip list -r172.22.192.1
Exportable USB devices

• 172.22.192.1
  4-4: Alcor Micro Corp. : Flash Drive (058f:6387)
  : USB\VID_058F&PID_6387\3BCF0CF5
  : (Defined at Interface level) (00/00/00)
  : 0 - Mass Storage / SCSI / Bulk-Only (08/06/50)

   7-3: Realtek Semiconductor Corp. : RTL2838 DVB-T (0bda:2838)
      : USB\VID_0BDA&PID_2838\00000001
      : (Defined at Interface level) (00/00/00)
      :  0 - Vendor Specific Class / Vendor Specific Subclass / Vendor Specific Protocol (ff/ff/ff)
      :  1 - Vendor Specific Class / Vendor Specific Subclass / Vendor Specific Protocol (ff/ff/ff)
  

There is not any obvious port number. I tried the bus id and the hardware id. Neither worked.

Using usbipd.exe, I was able to attach and detach using either the busid or the hardware-id, which is predictable. If the port number isn't predictable, I will have to parse the output to find it.

[dorssel]

What port number? To detach? How about usbip port?

[bimmerdriver]

Here is the output of usbip port:

$ sudo /usr/lib/linux-tools/5.15.0-101-generic/usbip port
Imported USB devices

Port 00: at High Speed(480Mbps)
Realtek Semiconductor Corp. : RTL2838 DVB-T (0bda:2838)
1-1 -> usbip://172.22.192.1:3240/7-3
-> remote bus/dev 007/003
Port 01: at High Speed(480Mbps)
Alcor Micro Corp. : Flash Drive (058f:6387)
1-2 -> usbip://172.22.192.1:3240/4-4
-> remote bus/dev 004/004

In order to determine the port, the output needs to be parsed. This is why it is simpler to use usbipd.exe detach -hardware-id 058f:6387. It's not necessary to know the ip address of the host or the busid or the port.

Obviously this is not difficult if you are doing this manually from the command line, but to automate the attach and detach in a systemd service, it's cumbersome.

If usbipd.exe detach didn't hang, there would be no need for a native linux command. (It even hangs on windows. The problem is not executing the windows command on linux.)

[dorssel]

The fact that it hangs when executing on Windows shows there is something wrong with your system/installation/setup. Really, there is no reason why usbipd.exe detach would hang. And it has never been seen before. Maybe a repair install of the usbdip-win software?

[bimmerdriver]

I did a repair install and it made no difference. The detach command still hangs even if I execute it on windows.

C:\WINDOWS\system32>wsl --version
WSL version: 2.1.5.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.4239

C:\WINDOWS\system32>wsl --status
Default Distribution: Ubuntu-22.04
Default Version: 2

Both Windows Linux are fully up to date.

[dorssel]

What is the exact command line you use to detach under Windows?

[bimmerdriver]

I've tried all of the following:

usbipd detach --busid=4-4
usbipd detach --busid 4-4
usbipd detach --hardware-id=058f:6387
usbipd detach --hardware-id 058f:6387

In all cases, the console is hung until I click in the window in which I executed the command. By "hung" I mean that I cannot enter another command or up-arrow to another command.

This is the same whether the command is executed natively in a Windows Command Prompt window or in WSL2 in a bash window.

[dorssel]

I cannot reproduce (or explain that). What type of device are you attaching? Some HID device (which may cause Windows re-enumerate and perhaps lose window focus)? Can you try with another device type?

[bimmerdriver]

I'm attaching a USB memory stick. I tried another different one and the result was the same. The same problem happens with wsl, executing the command from within bash and also when systemd executes the command to stop a service, not sure if it's plausible that it could be caused by losing window focus.

Here are the commands to start and stop the service:

ExecStart=bash -c "/mnt/c/'Program Files'/usbipd-win//usbipd.exe attach --wsl --hardware-id VID:PID"
ExecStop=bash -c "/mnt/c/'Program Files'/usbipd-win//usbipd.exe detach --hardware-id VID:PID"

There is no problem attaching, only detaching.

[dorssel]

I give up...

[bimmerdriver]

I asked someone else to test this on his system. He's getting exactly the same result that I'm getting.

I'm running the latest version of wsl on a host running fully up to date Windows 10 22H2. He is also running Ubuntu 22.04 LTS, fully up to date.

C:\WINDOWS\system32>wsl --version
WSL version: 2.1.5.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.4239

I encountered this problem when I was testing a service to automatically attach a USB device after booting, before another service that requires the device to be attached.

Here is a test version of the service with the reference to the other service removed. All it does is attach the device after network-online.target.

# USBIPD-WIN-TEST Service for Ubuntu 22.04 systemd
# Attach USB after the network is online
# Requires github.com/dorssel/usbipd-win to be installed on WSL host
# To Install:
# Replace <VID:PID> with actual VID:PID
# sudo cp ./usbipd-win-test.service /etc/systemd/system
# sudo systemctl daemon-reload
# sudo systemctl enable usbipd-win-test
# sudo systemctl start usbipd-win-test
# sudo systemctl stop usbipd-win-test
# sudo systemctl restart usbipd-win-test

[Unit]
Description=USBIPD-WIN-TEST Attach USB
Wants=network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=bash -c "/mnt/c/'Program Files'/usbipd-win//usbipd.exe attach --wsl --hardware-id VID:PID"
ExecStop=bash -c "/mnt/c/'Program Files'/usbipd-win//usbipd.exe detach --hardware-id VID:PID"

[Install]
WantedBy=default.target

When the service is started, it works properly. When the service is stopped, it gives the appearance of working, but the command hangs due to the detach command not exiting. When the service is restarted (detach, followed by attach), it fails because the detach command doesn't exit properly, causing the device to not actually be available to attach. This can be seen by running

sudo systemctl status usbipd-win-test

The same thing happens when I execute the exact commands from the script in bash or on Windows.

I don't know what else this could be other than a bug in usbipd detach.

[dorssel]

When I run from Ubuntu 22.04 in WSL:

bash -c "/mnt/c/'Program Files'/usbipd-win//usbipd.exe detach --hardware-id VID:PID"

(with the VID:PID replaced, of course), then it works as expected. I did not try it as a service, but you say it also happens when running from the command line. I cannot reproduce the problem. Note that when the command is executed without the device actually being attached, then it (correctly) reports an error and exits with a non-0 exit code. It doesn't lock the console in any way.

[bimmerdriver]

Below is the output from executing the following command line:

bash -c "/mnt/c/'Program Files'/usbipd-win//usbipd.exe detach --hardware-id 0951:1666; echo $?; /mnt/c/'Program Files'/usbipd-win//usbipd.exe attach --wsl --hardware-id 0951:1666; echo $?"

In this case, the USB device was already detached before I executed the command:

$ bash -c "/mnt/c/'Program Files'/usbipd-win//usbipd.exe detach --hardware-id 0951:1666; echo $?; /mnt/c/'Program Files'/usbipd-win//usbipd.exe attach --wsl --hardware-id 0951:1666; echo $?"
usbipd: info: Device with hardware-id '0951:1666' found at busid '6-2'.
usbipd: info: Device with busid '6-2' was already not attached.
0
usbipd: info: Device with hardware-id '0951:1666' found at busid '6-2'.
usbipd: info: Using WSL distribution 'Ubuntu-22.04' to attach; the device will be available in all WSL 2 distributions.
usbipd: info: Using IP address 172.22.192.1 to reach the host.
0

In this case, the USB device was attached before I executed the command:

$ bash -c "/mnt/c/'Program Files'/usbipd-win//usbipd.exe detach --hardware-id 0951:1666; echo $?; /mnt/c/'
Program Files'/usbipd-win//usbipd.exe attach --wsl --hardware-id 0951:1666; echo $?"
usbipd: info: Device with hardware-id '0951:1666' found at busid '6-2'.
0
usbipd: error: No devices found with hardware-id '0951:1666'.
0

You can see that even though the detach command reported a clean exit, it did not complete cleanly because the device wasn't available to attach. If the device was already attached, it would have reported a different message.

I can understand if my system was the only one with this problem, my system would be suspect. However, my system isn't the only one with this problem.

If you want to take a look at my system, we can use TeamViewer. (I'm located in UTC-7.)

[dorssel]

So it is not locking up the the console?

You are right that in the last case, an error value should be returned. I'll fix that. For the time being you could check if there is no output to stderr.

EDITED

usbipd.exe correctly returns 1 in case the hardware-id does not exist when attaching.

Your problem is that bash -c / Windows do not correctly pass on the return value when running executables.

If I run (on WSL, without bash -c in front):

/mnt/c/'Program Files'/usbipd-win//usbipd.exe attach --wsl --hardware-id 0951:1666; echo $?

it works correctly.

[bimmerdriver]

It's a good point that bash -c doesn't return error status. I forgot about that. But that's really not the problem.

The problem is that if I detach an attached USB device, the subsequent attach fails. This has been the problem from the start and it happens both on Windows and WSL. The error from the attach is not consistent with the device still being detached. It's the same error that I get if I try to attach a device with an incorrect hardware-id.

# Device was not attached before executing the following command:
$ bash -c "/mnt/c/'Program Files'/usbipd-win//usbipd.exe detach --hardware-id 0951:1666; echo $?; /mnt/c/'Program Files'/usbipd-win//usbipd.exe attach --wsl --hardware-id 0951:1666; echo $?"
usbipd: info: Device with hardware-id '0951:1666' found at busid '6-2'.
usbipd: info: Device with busid '6-2' was already not attached.
0
usbipd: info: Device with hardware-id '0951:1666' found at busid '6-2'.
usbipd: info: Using WSL distribution 'Ubuntu-22.04' to attach; the device will be available in all WSL 2 distributions.
usbipd: info: Using IP address 172.22.192.1 to reach the host.
0
# Device was attached by the previous command before executing the follwing command:
$ bash -c "/mnt/c/'Program Files'/usbipd-win//usbipd.exe detach --hardware-id 0951:1666; echo $?; /mnt/c/'Program Files'/usbipd-win//usbipd.exe attach --wsl --hardware-id 0951:1666; echo $?"
usbipd: info: Device with hardware-id '0951:1666' found at busid '6-2'.
0
usbipd: error: No devices found with hardware-id '0951:1666'.
0
# The following command was executed with an incorrect hardware-id:
$ bash -c "/mnt/c/'Program Files'/usbipd-win//usbipd.exe attach --wsl --hardware-id 0951:1667; echo $?"
usbipd: error: No devices found with hardware-id '0951:1667'.
0

If I didn't know any better, I would suspect there is a deadlock in the driver causing it to not fully release the device.

My offer for you to take a look at my system and see for yourself still stands.

[dorssel]

You're giving very confusing/mixed reports. The original issue you reported was that the console got stuck, and that detach was hanging ("not exeting properly") somehow. Now you are saying that it is attach that isn't working correctly. But I already explained that right after a detach, the device is temporarily (usually less than a second) unavailable, because it is being reset (essentially unplugged/re-plugged) by Windows (#902 (comment)). So far, from what I see in the logs/dumps/screenshots, everything works the way it is supposed to work.