This has a customer impact. He is unable to redirect usb which is affecting his users work

To debug this I'm going to need to know what data the device is sending so that we can compare it to what Chrome is passing to the app. If you can reproduce this issue on Linux then the application Wireshark can be used to generate a trace of USB traffic that can be compared to the output of the API. Please let me know if you need more information on how to collect this trace and I can walk you through it.

Scanning has failed on Linux as well. Attaching the Wireshark trace here. USB interface 1.6.x is the source.

Deleted: WireShark_Ubuntu_EpsonTM-S1000_ScanAttempt.pcapng 4.7 MB

WireShark_Ubuntu_EpsonTM-S1000_ScanAttempt.pcapng 4.7 MB Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks for the logs. I will investigate this soon.

Hi, is there any update on this bug? Thanks!

Sorry for the delay. I'm looking at this right now at it appears that while most interrupt transfers are returning no data there is a small handful of transfers that do return some data. The fact that the operating system is completing these transfers without error (as shown by the Wireshark log) points to Chrome operating correctly in this case.

Since the data itself is meaningless to me (does this scanner implement a standard protocol?) we need to do a comparison between the scanner operating correctly and the scan failing. I assume that the actual scanner driver software is running in a virtual desktop environment that is being connected to using Citrix's app. Can you run this software locally on a Windows or Linux machine directly connected to the scanner and collect a Wireshark trace from there to compare to the one above?

Hi, I'm attaching the Wireshark trace collected from a Windows machine directly. I'm not sure what protocol the scanner implements. I will get back to you on that.

Deleted: WireShark_Windows_EpsonTM-S1000_ScanSuccess.pcapng 107 KB

WireShark_Windows_EpsonTM-S1000_ScanSuccess.pcapng 107 KB Download

The scanner implements standard TWAIN protocol

Is there an update on this issue? 

Thanks for uploading the trace from Windows. Something interesting that stands out is that it looks like the packet data length on Windows is always 8 bytes while the (requested) packet length on Linux is always 512 bytes.

The next steps here are going to be tricky. You need to match up a scan trace from Linux and Windows and try to find the pattern in the data being sent. Knowing that this is TWAIN traffic should help if you look up how TWAIN is being mapped to USB and how the protocol works. You need to find the places where the data is the same and the places where the data is different. I unfortunately can't really do this without the device or a copy of the environment in which it is being used. Without an example that points out where the same USB request has different results with or without Chrome involved there's not much more I can do to diagnose this issue with your app.

Re #8 - There isn't a native software from Epson that runs on Linux currently.

In addition to capturing the Wireshark on Windows and also on Linux running the Chrome Citrix Receiver app we can try the following on a Chromebook in Developer mode to collect a pcap file.

See this external document here Wireshark capture on a Chromebook see this external doc here where you can put a ChromeOS device in developer mode and run a capture.
https://enterprise.cloudshark.org/blog/packet-capture-in-chrome-os/

I ran the packet capture for wlan0 and here is the link to the pcap file in Google Drive.

https://drive.google.com/file/d/1Xv8jf5wj19ACpEIx9CeMEFpMDfIZ4YgO/view?usp=sharing

When I ran the command 'connectivity show devices' wlan0 was the only device that showed up.  

I am also attaching the capture trace to this entry

Deleted: packet_capture_w61T.pcap 9.2 MB

packet_capture_w61T.pcap 9.2 MB Download

Citrix Comment- 
The cheque scanner is working only on one pixelbook with all versions of receiver and Workspace app every time (Corey tried older version and new)
Please find below its details:
Google Model: C0A 8714G03NX2
Chrome Version: 68.0.3440.118 (Official Build) (64-bit)
 
However, it isn’t working on another Pixelbook that we have or other chromebook, even though the Chrome version and Receiver/workspace versions we tried are same.
Please find below its details:
Google Model: C0A 7923G006YR
Chrome Version: 68.0.3440.118 (Official Build) (64-bit)

Can you pls verify what could be the difference?

Hello,
We are now experiencing a new issue, and have done a bunch of debugging to narrow it down. Some packets that Chrome OS receives from the device are not being passed to the Chrome app through chrome.usb.interruptTransfer. 

We have a wireshark trace from chrome os and from the virtual windows session captured at the same time here: https://citrix.sharefile.com/d-s1b75de8673e4123b

There is an inconsistency in the packets shown here. 
On the ChromeOS side:
Frame 429 – bulk packet sent to scanner (data = 10 14 08 01 03 14 01 06 02 08)
Frame 430 – bulk packet response received from scanner

Windows side:
Frame 274 – bulk packet sent to scanner (data = 10 14 08 01 03 14 01 06 02 08)
There is never a response received.


If you look at the packets immediately preceding this one, you can see that several bytes of data are simply missing from the Windows trace. On the physical side these are packets 363 and 427: 66 packets between 2 events. On the virtual side these are packets 237 and 274: only 37 packets between 2 events. 

This results in the check scanner showing a "scanner is offline" error on the second attempt to scan a check. 

Can you please take a look and help us understand what might be going on with these missing packets?

Tharu, do we know yet whether on the Chrome OS side the bulk packet response is being dispatched to the app and then lost in transit to Windows or whether it is lost somewhere after the OS tries to deliver it to Chrome?

Citrix Comment-
The packet response is not reaching Citrix Workspace app. It's not lost in transit to Windows. It's lost somewhere before it reaches the Citrix Workspace app.