R4.0 drops USB data

[Glen H]

Hi,

I'm using R4 (having never used R3) and trying to get my scanner working but it stops scanning a page half way through. After debugging with the author of the scanner software they say the program asks for 128 KBytes of data and the first 256 bytes of this data is dropped (lost).

To fix this I've tried:
1) Turning off USB 3.0 in BIOS (unfortunately this isn't really an option as all the external ports are disabled). It doesn't revert back to USB 2.0
2) Set the ports to USB 2.0 via setpci:

```
lspci -nn | grep USB | cut -d '[' -f3 | cut -d ']' -f1 | xargs -I@ setpci -H1 -d @ d0.l=0
```

Unfortunately neither of those made a difference. Using the scanner/software in Windows on a different computer works.

I'm currently running a Qubes backup and then I'll try installing Ubuntu and see if that works. If so would seem to be related to Qubes.

Does anyone have any ideas? My laptop is a Dell e7440 with the latest BIOS.

Thanks,

Glen

[Yuraeitha]

These informations might give some extra insight;
- Where is your USB controller? dom0? sys-usb? sys-net? somewhere else? directly in the AppVM?
- It might be a bit annoying to do, but you could try install the printer on a different template. This would help you troubleshoot if the issue is template related or not template related.
- If you then in addition do as you're already planning to that test it on Ubuntu, it also gives better insight. Maybe use Ubuntu live-boot to install the printer and test it though? So you can avoid installing it just fro that.

If the printer works in another template, then you know it's a debian/fedora/whonix issue. If the printer doesn't work in another template, then it's likely not an issue in the templates (unless it's an universal kernel/driver or Qubes tools issue of ofc). But if it then works in Ubuntu, then you know it isn't a universal Linux/kernel issue. You're then more reasonably narrowed it down to potential culprits with some albeit rough, but useful estimates.

btw if your USB controller is in dom0, then that already might be an explanation as to why it fails. You can also try temporarily pass the USB controller directly into an AppVM and test directly printing inside that AppVM (or alternatively use qvm-open-in-vm and open the doc in the AppVM that hold's the controller, and try print directly from the AppVM instead of using the qvm-usb features. This would rule out or rule in a bug in the qvm-usb as well.

If you're up for some testings, then you should be able to narrow it down, maybe there are other useful ways to do this too, those mentioned are only the ones I could think of on the top of my head in the moment, there might be other good ways to narrow it down easily.

[Yuraeitha]

On Thursday, March 8, 2018 at 4:24:05 AM UTC+1, Glen H wrote:

oh btw, I recently had a printer issue that might be a bit similar in the cause, although different symptoms. I triggered it by using a different method to connect to the printer, out of the multiple of addresses IPP/DNS/etc./etc. I don't recall which one it was at the time, but one of connecting addresses drove my printer absolutely insane, causing it to require pulling the power, pull out the ink, and re-insert, wait 4-5 minutes for it to troubleshoot it. All this trouble, only because I used a different connection method, exactly the same driver too. I could repeat it as well, I went back to it again, and it happened again. The moment I used another address, it acted normal. This was on Qubes 4 as well, btw.

So this is also something I'd suggest you try as well, try connect with a different address method, see if it can finish the print if you do that.

[Ed]

Are you passing the device through to another VM?

The USB pass-through method has given me issues in the past for devices
that use a lot of bandwidth (webcams), though you are saying data is
lost after only a few bytes, I still might be suspect of the USB
passthrough system in qubes...

So if you ARE passing through you might want to try running the scanner
software directly from sys-usb to see if you can eliminate the USB
passthrough as a source of problems.

Ed

[Glen H]

Hi, I'll do some more tests in the next few days but just to answer some questions:

1) I have USB devices assigned in sys-usb

2) I use the devices panel widget to pass them to my AppVM.
- then it shows up as "Bus 001 Device 002: ID 04f9:60a0 Brother Industries, Ltd ADS-2000"

3) The controller info from Dom0 is:

00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC [8086:9c31] (rev 04)
00:1d.0 USB controller [0c03]: Intel Corporation 8 Series USB EHCI #1 [8086:9c26] (rev 04)

I'll try testing in the debian-9 AppVM, test from sys-usb, and install Ubuntu too once I have time. One other thing I haven't investigated is "Configure strict reset for PCI devices" but it is grayed out in sys-usb Devices tab.

Thanks for the help.

Glen

[Leo Gaspard]

On 03/08/2018 02:12 PM, Ed wrote:
> [...]

>
> Are you passing the device through to another VM?
>
> The USB pass-through method has given me issues in the past for devices
> that use a lot of bandwidth (webcams), though you are saying data is
> lost after only a few bytes, I still might be suspect of the USB
> passthrough system in qubes...
>
> So if you ARE passing through you might want to try running the scanner
> software directly from sys-usb to see if you can eliminate the USB
> passthrough as a source of problems.

Oh, I thought it was a hardware issue, but did hit the same issue (on
R3.2, haven't tried R4 yet). FWIW, [1] references this issue along with
a potential workaround.

That said, running still more things in sys-usb just increases once
again the attack surface to sys-usb, which is already way too high imo,
so that workaround isn't perfect…


[1] https://github.com/QubesOS/qubes-issues/issues/2594

[Glen H]

I ran some tests and the issue happens in sys-usb, Ubuntu (fresh install, no Qubes). When I use Windows 7 on the same hardware it works. So it looks like there is a driver issue with Linux. I tried updating the USB controller in Windows and then switching back to Linux and the problem still exists. So it seems the USB driver has an issue with reading data from my scanner. Any recommendations for what I should do?

Thanks,

Glen

[Yuraeitha]

When narrowed down to a likely driver issue, then I'd suggest a next step to find the modules name that handles the driver/scanner. You can also check if it's the same module across different Linux systems, Debian/Fedora template, as well as the one on Ubuntu. Another thing you can do is look up the printer and see if you can find any Linux drivers to it to download, or if it was written directly to the kernel/modules. Another approach could be unofficial drivers, for example drivers that might work on hardware, where the driver wasn't build by the hardware company. Sometimes you see hardware company employee's write drivers in their free time too, and other times you find similar drivers/modules which can work, albeit not perfectly. It can also do damage to the hardware if a wrong driver is used, so you need to take precautions or be wary not to take the unofficial drivers or unofficial modules, if you want to avoid risk of damage. It could also be that you're already using an unofficial driver/module, and that the official one might work.

For example, it might just be a module change you need to do, modules are kind of external drives to the drivers included in the kernel itself. So modules serves as a way to include drivers, without messing with the kernel too much. As far as I understand, it also makes it easier to maintain the kernel over the years, as modules can easily be out-dated and thrown away in favour for new ones, while keeping the kernel clean as it's been upgraded. But my understanding of kernels/modules is very vague, don't take it at face value, I might have gotten some details wrong.

But in general, what I'd suggest, is to identity the driver (module). Also chances are its the same module in all Linux distro's, but as extra redundancy check it might be worth checking if its the same module. If more modules/drivers exist that can do the job, switching it might help. i.e. are there any drivers on the printers website? If you dare take the risk (risk of hardware damage), does it help to pick a driver from a similar scanner/printer by the same developer? It might be discourages to test that, but if you don't mind buying a new printer if it goes wrong, then it's worth a try.

I didn't quite catch if the windows driver worked in Qubes Windows HVM? If yes, then as a last resort if nothing else works, an alternative could be to install a Windows system in Qubes purely for printing jobs, and then block any internet on it, and then print from there securely, since it doesn't have internet access anyway. It wastes a lot of disk space, but if you have a lot of disk space, then this one might work, or work until you find a better solution.