Hmmmm, that is unexpected, and I didn’t figure anything clever out from reading the logs. I can suggest two things to try next.
First, try (temporarily) giving the sys-usb dvm network and install trezorctl with pip pip install --user trezor, or the trezor suite, and see if it works that way. On my machine, I couldn’t get the trezor suite gui to behave on a VM in HVM mode, which is why I suggest the simpler trezorctl cli tool. If that doesn’t work, then it’s definitely not about the communication between the VMs.
Second, in the normal setup with e.g. coinpress-btc running the suite and sys-usb-dvm running trezord, try sudo wireshark on sys-usb-dvm, listen on all interfaces, and see if TCP packets appear to/from port 21325 when you open the trezor suite.
This should determine whether it’s about the inter-vm communication or about something wrong between sys-usb-dvm and the trezor itself.
Oh, one other thing is to try the trezor on another machine, or running tails on your qubes device, since it could be the trezor itself.
These logs aren’t documented on Trezor’s site, so I can only take an edumacated guesstimation that the USB protocol is functioning as expected. It seems the Trezor API is timing out. So yeah, I will try sys-usb install test when I have some cycles and report back.
P.S. My apologies on the edits. Bad habits from another platform. I’ll try to keep that to typo corrections.
Yeah that traffic looks like it’s working. So you can see a request originates from some random high port (40748) to 21325 with the [SYN] tag, which is like “hey, anyone there?” and then trezord which is listening on 21325 writes back an ACKnowledgement to 40748 [SYN, ACK] that it heard. And then after establishing the channel for TCP, they’re able to trade some HTTP packets. So the suite can talk to trezord!
So if we understood each other correctly that you took this wireshark data on sys-usb while running the trezor suite in an app vm, then the qubes rpc calls are working, and that’s not the source of the problem.
If you’re still having a bug where the device is in the incorrect state on qubes, and that doesn’t happen on another OS, then I’m afraid I have no idea. I guess you can double check that the content of your udev rules file matches what I wrote in the first post. You can maybe also try deleting the 51-trezor.rules file, since I know it works in my setup with only 50-trezor.rules present. Another last-ditch effort, try backing up the trezor and use a different PC to do a factory reset? If none of that helps, then maybe writing to trezor is the only hope.
Already did. I even dropped a link to this thread. They didn’t offer anything beyond the excellent help you all have. Factory reset did not help. I’ll try yet another fresh install of Qubes. Maybe there’s some bits floating around in bad places from all my trial and error. To be continued…
Then while it’s running, try to interact with it to reproduce the bug.
The -v flag makes the log very verbose, so you might try without it first and see if you get anything useful explaining the problem. I’m not that optimistic, but it might help anyway to try compiling the latest version of trezord for some reason.
There’s something in the source code about resetting the connection to put the device in the right state, and having some timing issues on some browsers that they fixed by giving it a few tries before giving up. The -r flag seems related to this, and it says it’s enabled by default, but give it a try with -r specifically included anyway. gl
Fixed. Installed bridge + udev rules on default TemplateVM ‘fedora-34’. For some reason, I had it stuck in my head that fedora-34-dvm was a TemplateVM.
This command returns: No such file or directory
And these return with PERMISSION DENIED on sys-usb
ln -s /rw/config/trezor/trezord /usr/bin/trezord
ln -s /rw/config/trezor/50-trezor.rules /lib/udev/rules.d/50-trezor.rules
ln -s /rw/config/trezor/trezord.service /usr/lib/systemd/system/trezord.service
ln -s /rw/config/trezor/qubes.Trezor /etc/qubes-rpc/qubes.Trezor
# add user that systemctl service is configured to use
useradd trezord
systemctl start trezord
The issue im having is that i get to he web wallet and it even shows my device name but nothing loads, cannot open any wallets its just stuck on loading forever. Any ideas??
This command returns: No such file or directory
And these return with PERMISSION DENIED on sys-usb
These should be pasted into /rw/config/rc.local, which means they will run as root when the VM starts up (so shouldn’t have permission denied), and you should put the files into /rw/config/trezor/ that it makes links to.
Also, question. I do it in an APPVM is that an issue? And then I pass Trezor from sys-usb to the APPVM
Yes, this is an issue. The whole point of this setup is that the usb device passthrough is complicated and doesn’t work reliably for many kinds of devices. The trezor is one like device that cannot be passed through. Because the client (trezor suite, trezorctl, electrum, etc.) communicates with the bridge (trezord) via TCP, we don’t need to use a usb passthrough. Instead we run the bridge in the usb vm, run the client in an app vm, and use TCP sockets to send the client<->bridge communication through qubes-rpc.
I would update the instructions in the original post to say “First you need the bridge software in sys-usb.” to make that part more clear. I’m new to the forums, and it looks like I can’t edit the original post.
I get it but how do I install bridge in sys-usb then? Could you try explaining it to my further or in private? If it works well I’m willing to pay u for your time.
The steps are in the original post. To summarize, you need to
get the RPM
install it
copy its files (50-trezor.rules, trezord, trezord.service) into /rw/config/trezor
create the qubes.Trezor rpc script
add the lines to /rw/config/rc.local to make the symbolic links and start the trezord service
With that done, trezord should be running in sys-usb whenever you start it up.
Then in dom0, you need to make the rpc policy, so that requests from the client will be allowed.
And in the client you need to add the line to /rw/config/rc.local that listens on port 21325 and forwards TCP packets in the rpc request.
I setup a minimum Qube with Trezor Suite, and everything it requires to connect. I can manually attach the device to Trezor Suite, and see accounts. However, I cannot upgrade firmware when connected through bootloader mode. Have any idea how I can get firmware updates to work?
Sorry to write a bit late. Hmm, I never got it to work in the first place by just attaching the device. So you have trezord running in the appVM where you run the trezor suite, and the trezor is attached through sys-usb? I don’t have a great understanding of what Qubes does to pass usb devices through, but it does seem to mangle some things. The advantage with the setup as I described in this post is that trezord runs in the VM that has direct access to the hardware, and then it talks to the trezor suite via TCP packets that Qubes can pass along without any problems, so you could try it that way. I have done a firmware update on mine and it’s worked.
If you don’t want to though, you could try running the trezor suite app VM in HVM and giving it direct access to the usb hardware (so you’d have to shutdown sys-usb and add the usb controller in the hardware settings for the app VM). On my computer, for some reason trezor suite was too resource hungry or something, and I just couldn’t get it to work in HVM, hence my solution, but maybe it’d work for you.
and no worries