feature request - whitelist of devices to auto-connect?

[davidbuzz]

Many usb devices will start-up in "bootloader" mode for 1-5 seconds as they first get power applied, and afterwards will execute a 'main firmware' if available. If the main firmware is corrupted as part of a partial firmware update, then the bootloader can be used to re-flash without bricking the device. Bootloaders like this often have their own 'brief' usb identifiers etc. The only way to pass-through these devices to wsl for the few seconds of their existance would be to have a white-list of 'recently seen' devices that should be automatically connected to wsl on detection, and disconnected after .

[davidbuzz]

... tools like VirtualBox and Parallels and pretty much all desktop-virtualisation apps have a GUI that lets you do this.

[dorssel]

An 'auto-attach' flag seems perfectly doable. But it will have to wait a bit until the dust settles.

As for a GUI, I've thought about making a mmc.exe extension. But my GUI skills are ... well ... average at best. So this one is not on the top of the list.

[davidbuzz]

I'd settle for a auto-connect-device-list.txt file that gets dropped next to the binary. :-)

[mh166]

@dorssel Just curious: is there any particular benefit from coding a MMC snap-in vs. just using a 'standalone' GUI?

I'm not familiar with the process of creating such snap-ins, but I'd assume it's easier if you don't have to make use of certain APIs (and probably their constraints) but are free to use any GUI framework of your choice.

[dorssel]

These days, it is actually quite easy to make a 3.0 MMC snap-in that just hosts WPF views. It gives a familiar administration look, you get the tree-view on the left for free, and it will allow a future "remote" option. Remember that this is not only for WSL, another use case is headless Hyper-V servers where you need smartcards, tokens, dongles, etc. forwarded to guests.

I've done this for other projects and it works quite well. With the proper boilerplate (which I can provide), it would actually be less work that standalone.

For now, getting all devices to work has a higher priority. Next up will be PowerShell automation to improve the CLI experience and making things better "scriptable".

But maybe you want to open a new feature request for your needs? We are hijacking the OP, who just wants auto-attach...

[kumekay]

Yes, this feature will be really useful, even without GUI.

My workflow is slightly different, but the problem is similar.
I'm developing for an embedded with a software-implemented USB CDC.
The typical workflow is to run a command like idf.py build flash monitor. It builds the app, flashes it, and resets the MCU, then connects through the serial monitor to check the output.

The problem is that with soft USB CDC the device temporarily disappears on reset. So before the serial monitor can connect after flashing I have to run usbipd wsl attach again.

So the flag like auto-attach or auto-reattach for usbipd wsl/usbip attach will be very useful.

And thank all the contributors for a really great tool!

[davidbuzz]

Any chance we could move this issue up the priorities list..? this is the only issue right now preventing a bunch of people being able to use wsl2+usbipd to flash firmware, update autopilots, and a bunch of other stuff. i for one am trying to flash a firmware to an https://github.com/ardupilot/ardupilot compatible flight controller, ( Pixhawk2, Cube, and about 50 other flight controllers ) ..?

[dorssel]

@davidbuzz
It is unlikely that usbipd-win itself will ever include this functionality. The reason is that it is much easier and more logical to do this with a per-user service/background process, preferably even on the Linux side.

usbipd-win is a Windows service that runs as SYSTEM. It is totally unaware of WSL instances (which are per user), and whether those users (plural!) are even logged in or if their WSL instances (plural!) are even running. To solve this from the Windows-side of things, one would have to monitor WSL instance run status, for each user and for each instance.

It is much simpler to run a service/background process Linux side:

1. Its lifetime would be automatically tied to the lifetime of the WSL instance itself.
2. Automatically runs as the right user.
3. Can detect whether the USB device has been detached (either polling usbip port or event driven via udev) in order to attempt a re-attach.

In pseudo-code on Linux:

while (true)
  if (!attached(intended_usb_device))
     try_attach
  sleep(1 second)

[CraigHutchinson]

Has this feature been analysed further?

It could be possible that this degree of automation could be a separate tool altogether and not necessarily specific to USBIPD but it would be most useful that this were integrated. It should/could be an option when attach is called to remember the attachment command and reinstate the call when a matching device is found.

To break it down the key parts (as I see it)

1. Configure auto-attach but setting a flag on the initial attach e.g. -a, -auto-attach <1|0> Enabled/Disable automount for the specified attach
2. Detect new USB device is mounted on the Windows host
3. Match device to some filter/rule for auto-mounting (Name, Vendor:Product, GUID etc)
4. Run some inbuilt function, configured command, or execute a script to either:

• Notify the client VM that a device of interest exists
• Call respective uspdid wsl attach .... implicitly etc

Some issues/special-case I forsee with auto-remount rules:

• If a device is attached by busid then the auto-mount should only remount the same PID:VID device at the same port?
• If the device restarts into a bootloader the VID:PID and all device information changes, so maybe we do remount 'ANY' device on the same BUSID within a 10-second period for example. EDIT: Actually, the end-user just creates a separate auto-mount rule for both device modes

[dorssel]

@CraigHutchinson
Multiple people have gone the route to automate this from the Linux side (TL;DR: that is the way to go!). In fact, You yourself noted that Arch Linux even has a systemd service for it.

This is really best solved from the client side. It knows when the client OS is up and running, it can poll (or even use udev) to detect missing/broken attaches. Work for all kind of clients, not just WSL.

From the Windows side it is much harder. It would only work for WSL anyway (as there is no way to control other clients). WSL has no way of ëvent-driven detection on the running state of instances. And last but not least, it needs to run in the user context. So even if this would be written, it would require an entire new per-user background service that really has nothing to do with usbipd.

After all attach is client side. The fact that you can run wsl attach from Window is just convenience, it still comes down to the client OS doing the attach.

I keep repeating myself, see earlier comment #56 (comment).

[CraigHutchinson]

Apologies, a bit of a misunderstanding in my part. I don't beg to understand how this brilliant tech you've made works so just touching the surface here on understanding. Now, from the naive view the device being plugged/unplugged on the host pc we could assume would need the windows host daemon to play some part in trigger some event as a broadcast or otherwise. Apart from this I think I understand how it is the client that instigates the attach. For now we can poll for devices from the vm side which does appear simple enough. One random idea (I.e. Just chucking out there) for auto-mounting usb without writing Linux scripts whatsoever would be if we can mount a USB hub device itself into the VM? Feels like a crazy idea but there could be some level of cool if this were even remotely possible so all plugged devices would be implicitly connected at the vm as of course it owns and gets all the hub events! .... I'm gonna guess this isn't gonna be simple, I wouldn't expect this to be followed up as its a random thought. Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Frans van Dorsselaer ***@***.***> Sent: Thursday, April 14, 2022 10:40:39 PM To: dorssel/usbipd-win ***@***.***> Cc: Craig J. Hutchinson ***@***.***>; Mention ***@***.***> Subject: Re: [dorssel/usbipd-win] feature request - whitelist of devices to auto-connect? (Issue #56) @CraigHutchinson<https://github.com/CraigHutchinson> Multiple people have gone the route to automate this from the Linux side (TL;DR: that is the way to go!). In fact, You yourself noted that Arch Linux even has a systemd service for it. This is really best solved from the client side. It knows when the client OS is up and running, it can poll (or even use udev) to detect missing/broken attaches. Work for all kind of clients, not just WSL. From the Windows side it is much harder. It would only work for WSL anyway (as there is no way to control other clients). WSL has no way of ëvent-driven detection on the running state of instances. And last but not least, it needs to run in the user context. So even if this would be written, it would require an entire new per-user background service that really has nothing to do with usbipd. After all attach is client side. The fact that you can run wsl attach from Window is just convenience, it still comes down to the client OS doing the attach. I keep repeating myself, see earlier comment #56 (comment)<#56 (comment)>. — Reply to this email directly, view it on GitHub<#56 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AM6BJUC7P4ANR26F2UPMA63VFCGFPANCNFSM5HMRZWEQ>. You are receiving this because you were mentioned.Message ID: ***@***.***> Emteq Ltd, Sussex Innovation Centre, Brighton BN1 9SB Company Registration: 09708880 This e-mail (including any attachments) is considered confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this e-mail is prohibited except by or on behalf of the intended recipient. If you have received this email in error, please notify me immediately by reply e-mail, delete this e-mail, and do not disclose its contents to anyone. Thank you.

[dorssel]

@CraigHutchinson
No worries. When I started this project my understanding of USB and USBIP was minimal, and I made all the mistakes that could be made.

Originally, I wanted to forward ports instead of devices. So you could dedicate a specific port to a VM and then magically all devices connected to that port (including hubs with multiple devices) would be for the VM.

Unfortunately, that is not how USB works. HUBs must be controlled by the host. HUBs are, in fact, not considered USB devices. So, like you, I was mistakenly hoping for passing through an entire hub. Turns out ... it cannot be done.

Then there are COMPOSITE devices. They are somewhat in-between a hub and a device. They support multiple functions (like: keyboard and mouse). Turns out, you cannot forward only one of those functions. You will have to forward the entire composite device. This is a bit of a bummer for some dock devices. There are dock devices that expose themselves as a hub, such that each function (audio, network, etc). is a device on its own. That's nice, as you can forward each one individually. Others expose themselves as one single composite device, in which case you will have to forward the entire dock, or nothing at all.

So:

• ports -> special, cannot be forwarded
• hubs -> special, cannot be forwarded
• individual functions of a composite device -> special, cannot be forwarded individually
• single devices (composite or not) -> bingo! But you will always have to forward the entire device, including all its functions.

[dorssel]

A first attempt at auto-attach is in PR #351. Please have a try at this...
Installer can be found here: https://github.com/dorssel/usbipd-win/actions/runs/2186416751.

Use as: usbipd wsl attach --busid 1-1 --auto-attach

Should be pretty self-explanatory...

[cgxeiji]

I was just looking for something like this and found out that there is a PR from 2 days ago, amazing! So far it is working nice!

[dorssel]

Merged PR #351

[hjwmedenblik]

A first attempt at auto-attach is in PR #351. Please have a try at this... Installer can be found here: https://github.com/dorssel/usbipd-win/actions/runs/2186416751.

Use as: usbipd wsl attach --busid 1-1 --auto-attach

Should be pretty self-explanatory...

Hi, I can't find the installer which would enable this feature. Link seems expired?

[dorssel]

Feature was merged long ago. It is in the current release.

[realszopen]

It's nice and works just fine, but it would be even nicer if usbipd would be able to attach certain devices to wsl following their detection by the system, so that we would not have to attach devices with each system boot.

[dorssel]

@realszopen
That is something which has been discussed before. It would be best handled by another service, as currently the two functions included are "service that does the actual protocol" and "low-level command line tool that does a one-time attach". Anything "monitoring" requires a lot more than just monitoring devices. It would also have to monitor the WSL running status, whether the device is in use by Windows, etc. Sure, this could be added to the usbipd-win installer as an additional software feature, but it requires proper design and (most likely) some nice user interface. Currently, this is out of scope. Remember that usbipd-win is more generic than just WSL-usage. Maybe this should go in a different repo, something like usbipd-wsl, or so. Or it could be added to the GUI app that already exists (see https://gitlab.com/alelec/wsl-usb-gui).