Bug 1425961

Could you please provide the logs from spice client?
Which kind of device is it?

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 also confirmed this is a bug

It is still interesting to have:
1) dmesg (after trying to redirect the 2nd stick)
2) log of the session from spice client

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

Created attachment 1256946 [details]
remote-viewer log

During connection:
step1: plug flash1
step2: plug flash2

Created attachment 1256949 [details]
dmesg on guest (two flashes are attached at client)

Created attachment 1256953 [details]
LIBUSB_DEBUG=4 for RV

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.

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 ***

It would be good to leave the bug open until BZ#976685 is verified and then ensure the problem is solved.

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.

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 ~]$

(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?

This is the USBs that I use to have this test fail. This works on my laptop and it fails on my SPICE client.

Created attachment 1265735 [details]
USBView application

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

Created attachment 1292003 [details]
UsbDk Controller file on client

Created attachment 1292005 [details]
MyUsbTree text file

Created attachment 1292007 [details]
MyUsbTree xml file

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.

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?

Created attachment 1292686 [details]
Virt-viewer file from RHV portal

Created attachment 1292687 [details]
Qemu grep

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.

(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.

Created attachment 1292859 [details]
USBview as run on the Guest with both USBs plugged into Client

Created attachment 1292860 [details]
USBview as run on the Client with both USBs plugged into Client

I have attached the UsbView files from either one run on the guest or client.

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.

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.

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.

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.

Patch sent to spice-devel.org

(In reply to ybendito from comment #35)
> Patch sent to spice-devel.org

Applied in upstream of spice-gtk

I just installed UsbDk_1.0.19_x64.msi and the tools ISO 4.2-1 and still see this behavior.

(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.

Patch upstream:

commit de41d93285461264d7d1c14a1e649433d3911da6
Author: Yuri Benditovich <yuri.benditovich>
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>
    Message-Id: <1499232106-16448-1-git-send-email-yuri.benditovich>
    Acked-by: Uri Lublin <uril>
    [ Marc-André - Added commit comment from Uri's review. ]
    Signed-off-by: Marc-André Lureau <marcandre.lureau>

Fixing virt-viewer version that this bug should really be fixed. Previous build did not pick the correct dependencies with the backported patches.

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

BZ<2>Jira Resync