Bug 1425961 - USB with same vendor and product ID will only show the first one plugged into client in guest
Summary: USB with same vendor and product ID will only show the first one plugged into...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: mingw-virt-viewer
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ovirt-4.2.0
: ---
Assignee: ybendito
QA Contact: SPICE QE bug list
URL:
Whiteboard:
Depends On: 976685 1426537
Blocks: 1475444
TreeView+ depends on / blocked
 
Reported: 2017-02-22 21:12 UTC by Bill Sanford
Modified: 2019-05-16 13:14 UTC (History)
15 users (show)

Fixed In Version: mingw-virt-viewer-2.0-15.el7ev mingw-spice-gtk-0.31-7.el7ev
Doc Type: Bug Fix
Doc Text:
Previously, if more than one device from the same vendor and with the same device ID was plugged in, the device change signal was ignored and only the first USB device that was plugged into the client was seen on the guest. The current release makes each USB device unique, so that multiple devices from the same vendor and with the same device ID can be redirected.
Clone Of:
: 1426537 (view as bug list)
Environment:
Last Closed: 2018-05-15 18:02:00 UTC
oVirt Team: Spice
Target Upstream Version:


Attachments (Terms of Use)
remote-viewer log (474.67 KB, text/plain)
2017-02-23 15:16 UTC, Andrei Stepanov
no flags Details
dmesg on guest (two flashes are attached at client) (38.95 KB, text/plain)
2017-02-23 15:21 UTC, Andrei Stepanov
no flags Details
LIBUSB_DEBUG=4 for RV (377.07 KB, text/plain)
2017-02-23 15:32 UTC, Andrei Stepanov
no flags Details
USBView application (483.34 KB, application/zip)
2017-03-23 12:47 UTC, ybendito
no flags Details
UsbDk Controller file on client (1.12 KB, text/plain)
2017-06-26 14:46 UTC, Bill Sanford
no flags Details
MyUsbTree text file (41.86 KB, text/plain)
2017-06-26 14:47 UTC, Bill Sanford
no flags Details
MyUsbTree xml file (40.58 KB, text/plain)
2017-06-26 14:48 UTC, Bill Sanford
no flags Details
Virt-viewer file from RHV portal (3.82 KB, text/plain)
2017-06-28 18:23 UTC, Bill Sanford
no flags Details
Qemu grep (3.85 KB, text/plain)
2017-06-28 18:24 UTC, Bill Sanford
no flags Details
USBview as run on the Guest with both USBs plugged into Client (9.53 KB, text/plain)
2017-06-29 12:17 UTC, Bill Sanford
no flags Details
USBview as run on the Client with both USBs plugged into Client (40.50 KB, text/plain)
2017-06-29 12:18 UTC, Bill Sanford
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:1543 0 None None None 2018-05-15 18:03:13 UTC

Description Bill Sanford 2017-02-22 21:12:08 UTC
Description of problem:
Using 2 of the same USBs (specific vendor and product ID are identical), only the first one plugged into the client is seen on the guest. The subsequent identical USBs that are plugged into client, are seen only on the client and not the guest.

When I use different USB devices, I don't have this problem, all of them are redirected to the guest.

Version-Release number of selected component (if applicable):

Guest - RHEL 6.9
Client - Windows 7x64
Engine and Hosts - RHEL 7.3z
rhv-4.1.0-12
virt-viewer 2.0-208
spice-client-msi-x64-4.1-4.el7ev.noarch

How reproducible:
100%

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Victor Toso 2017-02-23 07:31:07 UTC
Could you please provide the logs from spice client?
Which kind of device is it?

Comment 2 Bill Sanford 2017-02-23 14:56:45 UTC
They are USB sticks. 

[bsanford@dhcp-25-232 ~]$ lsusb -d 8644:800b
Bus 001 Device 014: ID 8644:800b Intenso GmbG Micro Line (4GB)
Bus 001 Device 015: ID 8644:800b Intenso GmbG Micro Line (4GB)

I put the USB sticks in my laptop. Any devices that have the same vendor and product IDs, should work. I have another set of USBs that fail, as well as Brno team, astepano@redhat.com also confirmed this is a bug

Comment 3 Victor Toso 2017-02-23 15:13:12 UTC
It is still interesting to have:
1) dmesg (after trying to redirect the 2nd stick)
2) log of the session from spice client

Comment 4 Andrei Stepanov 2017-02-23 15:14:41 UTC
My case:

virt-viewer-2.0-6.el7_2.2.x86_64

spice-protocol-0.12.12-1.el7.noarch
spice-glib-0.31-8.el7.x86_64
spice-gtk3-0.31-8.el7.x86_64
spice-vdagent-0.14.0-14.el7.x86_64

spice-server-0.12.8-1.el7.x86_64

Flash on client can be seen as:

$ lsusb | grep -i king
Bus 001 Device 047: ID 0951:1666 Kingston Technology DataTraveler G4
Bus 002 Device 019: ID 0951:1666 Kingston Technology DataTraveler G4

Comment 5 Andrei Stepanov 2017-02-23 15:16:16 UTC
Created attachment 1256946 [details]
remote-viewer log

During connection:
step1: plug flash1
step2: plug flash2

Comment 6 Andrei Stepanov 2017-02-23 15:21:16 UTC
Created attachment 1256949 [details]
dmesg on guest (two flashes are attached at client)

Comment 7 Andrei Stepanov 2017-02-23 15:32:14 UTC
Created attachment 1256953 [details]
LIBUSB_DEBUG=4 for RV

Comment 8 Victor Toso 2017-02-24 07:37:40 UTC
Hi,

(In reply to Andrei Stepanov from comment #4)
> My case:
> 
> virt-viewer-2.0-6.el7_2.2.x86_64
> 
> spice-protocol-0.12.12-1.el7.noarch
> spice-glib-0.31-8.el7.x86_64
> spice-gtk3-0.31-8.el7.x86_64
> spice-vdagent-0.14.0-14.el7.x86_64

You can clone this one to rhel 7.4 then.

As it can be reproducible in rhel 7.4 it does not seem to be UsbDk bug.
Moving to client's component.

Comment 11 Andrei Stepanov 2017-03-10 15:09:25 UTC
If I plugin two identical USB driver into USB2 ports than I cannot reproduce this bug.

*** This bug has been marked as a duplicate of bug 976685 ***

Comment 12 ybendito 2017-03-14 07:29:56 UTC
It would be good to leave the bug open until BZ#976685 is verified and then ensure the problem is solved.

Comment 13 Bill Sanford 2017-03-15 13:00:26 UTC
This is not a duplicate of bug 976685. This has to do with virt-viewer not redirecting a USB device of the same specific vendor and product IDs that are identical.

Comment 14 Bill Sanford 2017-03-15 14:27:35 UTC
I put the USBs in a PC that I could get them to be seen. Here is the output:

[bsanford@localhost ~]$ lsusb -d 1e3d:2093
Bus 001 Device 123: ID 1e3d:2093 Chipsbank Microelectronics Co., Ltd CBM209x Flash Drive (OEM)
Bus 001 Device 122: ID 1e3d:2093 Chipsbank Microelectronics Co., Ltd CBM209x Flash Drive (OEM)
[bsanford@localhost ~]$ lsusb -d 1e3d:2093 -t
    |__ Port 4: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 1: Dev 122, If 0, Class=Mass Storage, Driver=usb-storage, 480M
    |__ Port 3: Dev 123, If 0, Class=Mass Storage, Driver=usb-storage, 480M
    |__ Port 4: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 2: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        |__ Port 3: Dev 8, If 0, Class=Mass Storage, Driver=usb-storage, 480M
        |__ Port 4: Dev 7, If 0, Class=Hub, Driver=hub/3p, 480M
    |__ Port 7: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M
    |__ Port 7: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M
    |__ Port 8: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
    |__ Port 8: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
[bsanford@localhost ~]$

Comment 15 ybendito 2017-03-15 14:39:05 UTC
(In reply to Bill Sanford from comment #14)
> I put the USBs in a PC that I could get them to be seen. Here is the output:
> 
> [bsanford@localhost ~]$ lsusb -d 1e3d:2093
> Bus 001 Device 123: ID 1e3d:2093 Chipsbank Microelectronics Co., Ltd CBM209x
> Flash Drive (OEM)
> Bus 001 Device 122: ID 1e3d:2093 Chipsbank Microelectronics Co., Ltd CBM209x
> Flash Drive (OEM)
> [bsanford@localhost ~]$ lsusb -d 1e3d:2093 -t
>     |__ Port 4: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
>     |__ Port 1: Dev 122, If 0, Class=Mass Storage, Driver=usb-storage, 480M
>     |__ Port 3: Dev 123, If 0, Class=Mass Storage, Driver=usb-storage, 480M
>     |__ Port 4: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
>         |__ Port 2: Dev 6, If 0, Class=Human Interface Device,
> Driver=usbhid, 1.5M
>         |__ Port 3: Dev 8, If 0, Class=Mass Storage, Driver=usb-storage, 480M
>         |__ Port 4: Dev 7, If 0, Class=Hub, Driver=hub/3p, 480M
>     |__ Port 7: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M
>     |__ Port 7: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M
>     |__ Port 8: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
>     |__ Port 8: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
> [bsanford@localhost ~]$

Do I understand it correctly that in your experiment the problem is not reproduced?

Comment 16 Bill Sanford 2017-03-15 17:58:36 UTC
This is the USBs that I use to have this test fail. This works on my laptop and it fails on my SPICE client.

Comment 17 ybendito 2017-03-23 12:47:10 UTC
Created attachment 1265735 [details]
USBView application

Comment 18 ybendito 2017-03-23 12:53:00 UTC
On the client machine (according to the description, Win7x64) please connect both USB devices.

1. Please use attached ZIP file with USBView application and create USB dump files:
    usbview /q /f /saveall:MyUsbTree.txt
    usbview /q /f /savexml:MyUsbTree.xml

2. Does the problem happen with latest remote viewer (5.0) and latest UsbDk (1.0-17)? If yes, please run from command line prompt:
%programfiles%\usbdk runtime library\usbdkcontroller.exe -n and collect it output

Comment 19 Bill Sanford 2017-06-26 14:46:22 UTC
Created attachment 1292003 [details]
UsbDk Controller file on client

Comment 20 Bill Sanford 2017-06-26 14:47:51 UTC
Created attachment 1292005 [details]
MyUsbTree text file

Comment 21 Bill Sanford 2017-06-26 14:48:29 UTC
Created attachment 1292007 [details]
MyUsbTree xml file

Comment 22 Bill Sanford 2017-06-26 14:55:54 UTC
Installed rhevm-4.1.3.5-0.1.el7. 

UsbDk still doesn't see second same USB thumb drive after the first one is in.

Comment 23 ybendito 2017-06-28 16:34:42 UTC
UsbDk recognizes both devices with different serial numbers, as we can see from UsbDk controller log.

1. (HOST) What is qemu command line for this VM (for example, 'ps ax | grep qemu')?
2. (CLIENT) What is remote-viewer command line, if any?
3. (GUEST) What is result of 'lsusb -v' and 'lsusb -t' when both disk-on-key inserted and redirected?
4. (GUEST) Do you use only RHEL 6.9 as specified in description or the same happens on Window guest?

Comment 24 Bill Sanford 2017-06-28 18:23:29 UTC
Created attachment 1292686 [details]
Virt-viewer file from RHV portal

Comment 25 Bill Sanford 2017-06-28 18:24:09 UTC
Created attachment 1292687 [details]
Qemu grep

Comment 26 Bill Sanford 2017-06-28 18:28:24 UTC
Reply to comment#23:

4. I used a Windows 7 client, this time. Still happens.

3. I used a Windows 7 client. 

2. Attached file.

1. Attached file.

I will plan on testing a 7.4 guest and see if that also happens.

Comment 27 ybendito 2017-06-29 08:07:06 UTC
(In reply to Bill Sanford from comment #26)
> Reply to comment#23:
> 
> 4. I used a Windows 7 client, this time. Still happens.
> 
> 3. I used a Windows 7 client.

Then, if the GUEST system is Windows, please use on GUEST system USBView application (https://bugzilla.redhat.com/attachment.cgi?id=1265735) and create USB dump file: "usbview /q /f /saveall:MyUsbTree.txt" when both USB drives are connected on CLIENT system and redirected to GUEST (client is the machine where remote viewer application is running, guest is virtual machine shown in the window of remote viewer).
 
> 
> 2. Attached file.
> 
> 1. Attached file.
> 
> I will plan on testing a 7.4 guest and see if that also happens.

Comment 28 Bill Sanford 2017-06-29 12:17:31 UTC
Created attachment 1292859 [details]
USBview as run on the Guest with both USBs plugged into Client

Comment 29 Bill Sanford 2017-06-29 12:18:07 UTC
Created attachment 1292860 [details]
USBview as run on the Client with both USBs plugged into Client

Comment 30 Bill Sanford 2017-06-29 12:19:31 UTC
I have attached the UsbView files from either one run on the guest or client.

Comment 31 ybendito 2017-06-29 14:13:41 UTC
If both USB drives are inserted into client machine before you start remote viewer and you use "File->USB device selection" dialog of remote viewer  to select devices to redirect, you should see both drives and if you select both of them, then you have both of them redirected correctly to the guest machine. 
Please confirm that this way both drives work.

Comment 32 ybendito 2017-06-29 16:15:44 UTC
The problem exists, related to plug-in flow and seems not dependent on UsbDk but on remote viewer or one of its libraries. Simple way to reproduce it without having two identical USB drives:
1. Run additional virtual machine with 2 emulated USB drives, without tablet device, install UsbDk and remote viewer on it. By default (when using virt-manager, for example) both drives are under the same root hub. 
2. Start remote viewer to any redirection-capable VM. Remote viwer ->'File->USB device selection' show 2 USB devices to share (that's correct). Close remote viewer.
3. Disable root hub in device manager and then start remote viewer. 'File->USB device selection' show no USB devices to share (that's correct). 
4. Enable previously disabled root hub. 'File->USB device selection' show just one device (incorect). Check USB device list in UsbDk: it contains 2 devices.

Comment 33 Bill Sanford 2017-06-29 16:17:26 UTC
Yes, that is the correct behavior. If you load the USBs before the virt-viewer is started, the Guest will see both. IF you try and insert them after, only one will show in Guest.

Comment 34 ybendito 2017-06-30 08:55:11 UTC
The problem caused by device plug-in flow in spice-gtk, procedures 'notify_dev_state_change' and 'gudev_devices_differ'. When they called on device plug-in and one device with such vendor and device id already exists, the device change signal is ignored.
https://cgit.freedesktop.org/spice/spice-gtk/tree/src/win-usb-dev.c, line 384

Preparing fix.

Comment 35 ybendito 2017-07-03 06:01:35 UTC
Patch sent to spice-devel@lists.freedesktop.org

Comment 36 ybendito 2017-07-14 12:58:23 UTC
(In reply to ybendito from comment #35)
> Patch sent to spice-devel@lists.freedesktop.org

Applied in upstream of spice-gtk

Comment 37 Bill Sanford 2017-10-26 15:56:24 UTC
I just installed UsbDk_1.0.19_x64.msi and the tools ISO 4.2-1 and still see this behavior.

Comment 38 ybendito 2017-10-26 17:59:58 UTC
(In reply to Bill Sanford from comment #37)
> I just installed UsbDk_1.0.19_x64.msi and the tools ISO 4.2-1 and still see
> this behavior.

Yes, because this does not depend on UsbDk, but on remote-viewer, more correctly on its spicegtk dll.

Comment 39 Victor Toso 2017-11-22 13:48:53 UTC
Patch upstream:

commit de41d93285461264d7d1c14a1e649433d3911da6
Author: Yuri Benditovich <yuri.benditovich@daynix.com>
Date:   Wed Jul 5 08:21:46 2017 +0300

    win-usb-dev: fix device arrival event logic
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1425961
    If attached new device when one device with the same vid
    and pid already present, the notification is ignored and
    attached device is not redirected (if auto share set) and
    not displayed in USB devices widget.
    
    This commit reverts older commit f9631cd6f8, which was
    intended to solve problem when bus:addr is sometimes changed when
    using WinUSB. The same commit creates the limitation for automatic
    redirection of second device with the same pid:vid.
    Now the preferred backend for Spice-GTK on Windows is UsbDk.
    In case users of newer WinUSB will still need backward compatible
    behavior, consider backend-aware comparison procedure.
    
    A device is now identified again by its bus.addr instead of vid:pid.
    
    Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
    Message-Id: <1499232106-16448-1-git-send-email-yuri.benditovich@daynix.com>
    Acked-by: Uri Lublin <uril@redhat.com>
    [ Marc-André - Added commit comment from Uri's review. ]
    Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

Comment 40 Victor Toso 2017-12-11 10:37:02 UTC
Fixing virt-viewer version that this bug should really be fixed. Previous build did not pick the correct dependencies with the backported patches.

Comment 48 errata-xmlrpc 2018-05-15 18:02:00 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:1543

Comment 49 Franta Kust 2019-05-16 13:07:36 UTC
BZ<2>Jira Resync


Note You need to log in before you can comment on or make changes to this bug.