Attaching remote device by VID rather than BUS ID

[fragtion]

As per title, it would be nice to have the option built in to have the ability to select a remote device (to attach etc) by its VID, not only the BUS ID. This can help in setups where resilience is needed for a single USB device potentially shifting USB port

usbipd supports binding a device in this way, so it seems to make a lot of sense to allow this on the client side as well for a seamless/consistent setup on both ends

[vadimgrn]

Linux 'usbip bind' uses --busid only, as well as 'usbip attach'. pid/vid is not unique.

[vadimgrn]

See also https://github.com/torvalds/linux/blob/master/tools/usb/usbip/src/usbip_network.h#L62,

[fragtion]

@vadimgrn Thanks for taking the time to provide such an interesting & on-point response

In response, I wonder why usbipd allows binding by VID if it's possible for a "non-unique" exception to be raised on the host side as well, in theory?

So I still find this inconsistency between the client and host to be strange, and I still maintain that it would be a convenient feature to allow binding by VID on the client side. If there are more than 1 device with the same VID, the client could just throw an error. But if there's one device that matches, I don't see why the method can't be used, as it would save more trouble than it causes (you have to ask yourself: how common is it to explicitly bind several devices with the same VID on the host side?). Only in special cases where the host is binding several devices with the same VID (relatively rare occurence), should the client need to take special care about which BUS ID has a specific device. For every other case (which I imagine is over 90% of use cases), people will need to forward a single device only (and even if more than one device, chances are they have different VIDs), in which case VID matching would make a lot more sense

But yes, ideally the patch would then be applied upstream at the linux codebase first... So I guess it's up to this project's maintainers to decide if an exception should be made for the windows version or not...

In the meanwhile, I guess I'll just need to create a script that does the matching externally, from usbip list output.

Cheers for now & thanks again.

[vadimgrn]

I do not understand where did you get info about support for bind or attach by VID? Kernel 6.2.0-26-generic

~$ usbip bind -h
usage: usbip bind <args>
    -b, --busid=<busid>    Bind usbip-host.ko to device on <busid>
vadym@pc:~$ usbip attach -h
usage: usbip attach <args>
    -r, --remote=<host>      The machine with exported USB devices
    -b, --busid=<busid>    Busid of the device on <host>
    -d, --device=<devid>    Id of the virtual UDC on <host>

[fragtion]

I do not understand where did you get info about support for bind or attach by VID? Kernel 6.2.0-26-generic

C:\WINDOWS\system32>usbipd bind --help
usbipd-win 2.4.1

Description:
  Registers a single USB device for sharing, so it can be attached to other machines. Unless the --force option is
  used, shared devices remain available to the host until they are attached to another machine.

  Exactly one of the options '--busid' or '--hardware-id' is required.

Usage:
  usbipd bind [options]

Options:
  -b, --busid <BUSID>          Share device having <BUSID>
  -f, --force                  Force binding; the host cannot use the device
  -i, --hardware-id <VID:PID>  Share device having <VID>:<PID>
  -?, -h, --help               Show help and usage information

note the -i parameter (which, by the way, works exactly as expected on the host side). But yeah this is for usbipd-win (https://github.com/dorssel/usbipd-win) so I just assumed it was the same on linux side... It should be, anyway.

[vadimgrn]

This is Windows implementation of usbipd which is not canonical. In my project I'm considering Linux compatibility only. This project is abandoned defacto.