BitBox2 not detected by app #1401
Comments
|
Hey there. It looks like everything's there but maybe the app cannot access (open) the device due to /dev/path permissions? Could you plug in the bitbox, tap a side and execute this: It should show something like this: That would be a good sign. It means udev rules are working. You can then check permissions on the dev files those symlinks point to. For me it looks like this: If you get to this point, might as check if those dev files are writable, so to make sure permissions are ok: If you don't see "writable" in the output, permissions are incorrect. You could then add Once you modified the rules, replug the bitbox and tap a side again. Please let me know if this works. We'll then update the udev rules on the website. |
|
Thanks for the answer. I checked the permissions and they look good to me but I can't get the "writeable" output. I then added the MODE="0666" to both rules, but it's still not writeable even after a PC reboot. (Also, I'm getting 3 devices.) Here is what I did: |
|
OMG so sorry, I suggested incorrect command with I have another idea. Let me double-check... |
|
I noticed there's an ACL entry associated with the files, indicated by the plus sign at the end: Good news is, your system does seem to trigger udev rules when the bitbox is connected. |
Yes, with Here is |
|
This is very strange. The app should definitely detect the bitbox. I would come back to the app's log file and check for any errors. The log you posted in the beginning seems unusually short. Could you grab the whole thing and email it to support@shiftcrypto-dot-ch. If it's larger than 10Mb, please email only the last 10Mb. I'll let my colleagues know and they'll route the ticket to me. The reason to continue on support@ is the log may contain some data I wouldn't want you to expose here in the public. |
|
I just found out that there is indeed an error being logged. Either I didn't notice it the other day, or it's new now. Anyway, I sent the log to the email. It's very short, as I cleared it a few times to see when the error occurred. Here's what I did in the log:
When touching a side, the error shows up. The app seems to want to send a request, but fails to do so. |
|
Hi all, Not sure it is the same problem on my end, but I am not able to use bitbox02 with the latest BitBox Linux App ( Curiously, I only experience this issue with the newer kernel v5.11, but not with the older kernel v4.14. FWIW, I am getting the following warnings and errors on 5.11 kernel during bitbox02 connect/disconnect: If anybody sees similar messages via |
|
Hey, |
|
Hi @seriousm4x
I basically go through the same sequence as described by you in #1401 (comment) , i.e.
IMHO it's worth the effort to try 4.14.
It's working fine for me on Windows 10. |
|
I just figured out that my Bitbox02 HW wallet works without problems on Ubuntu 20.04 when connected to a normal USB3.0-typeA port on my x86 motherboard (through USB-typeA-USB-typeC adapter). Previously I was connecting the HW wallet to a native USB-typeC port on the motherboard. All my findings shared previously still apply, but they are just limited to the native USB-C port on my desktop PC. In other words, the Bitbox02 wallet would communicate flawlessly with v4.14 (and presumably older) kernels via USB-C port, but would fail to communicate using newer Linux kernels on the same USB-C port. This means that there is either a culprit commit, a potential CONFIG change or kernel command line parameter update in the newer kernel (particularly |
|
@chatraed thanks so much for the info very useful. I'm on a voidlinux and its stock kernel 5.12.19_1 without issues. It's definitely possible Ubuntu is setting some CONFIG flags in their 20.04 release, although it seems @seriousm4x might have a different issue. My next step would be to upgrade our libusb/libhid libraries. We're currently using https://github.com/karalabe/usb which contains an older copy of the upstream usb: karalabe/usb#10. I'll temporary fork karalabe/usb to get the exact diff and see whether there are any potential changes relavant to this issue. |
|
So, I've tried again today and it magically worked. Same hardware but updated arch. Run as root: Reboot and all was working. I can't tell at all what caused the issue back then but it's working now. |
|
Hello again :) So i resurfaced this issue but now running on endeavourOS (basically arch) on same hardware. Exact same behavior as previously. Did all the setup setups like so:
App wants me to enter the password while bitbox device tells me to "See the BitBoxApp". Here is some updated terminal output from the above requests: ~ ❯❯❯ ls -l /dev/ | grep bitbox ✘ 130
lrwxrwxrwx 1 root root 8 22. Mai 19:27 bitbox02_10 -> hidraw10
lrwxrwxrwx 1 root root 15 22. Mai 19:27 bitbox02_2 -> bus/usb/003/015
~ ❯❯❯ ls -l /dev/hidraw10
crw-rw-r--+ 1 root plugdev 245, 10 22. Mai 19:27 /dev/hidraw10
~ ❯❯❯ ls -l /dev/bus/usb/003/015
crw-rw-r-- 1 root plugdev 189, 270 22. Mai 19:29 /dev/bus/usb/003/015
~ ❯❯❯ test -w /dev/hidraw10 && echo writable
writable
~ ❯❯❯ test -w /dev/bus/usb/003/015 && echo writable
writable
~ ❯❯❯ cat /etc/udev/rules.d/5*
SUBSYSTEM=="usb", SYMLINK+="dbb%n", GROUP="plugdev", MODE="0664", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2402"
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", SYMLINK+="dbbf%n", GROUP="plugdev", MODE="0664", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2402"
SUBSYSTEM=="usb", SYMLINK+="bitbox02_%n", GROUP="plugdev", MODE="0664", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2403"
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", SYMLINK+="bitbox02_%n", GROUP="plugdev", MODE="0664", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2403"
~ ❯❯❯ groups
sys libvirt docker rfkill wheel autologin max plugdev
~ ❯❯❯ getfacl /dev/hidraw10
getfacl: Removing leading '/' from absolute path names
# file: dev/hidraw10
# owner: root
# group: plugdev
user::rw-
user:max:rw-
group::rw-
mask::rw-
other::r--
~ ❯❯❯ getfacl /dev/bus/usb/003/015
getfacl: Removing leading '/' from absolute path names
# file: dev/bus/usb/003/015
# owner: root
# group: plugdev
user::rw-
group::rw-
other::r--
~ ❯❯❯ uname -a
Linux arch 6.9.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 17 May 2024 16:56:38 +0000 x86_64 GNU/LinuxAlso, here is the bitbox log. I've replaced my device id: There are two errors in the lower half of the log complaining about an hidapi error. Not really sure what to do with this. Any help appreciated! |
|
Exact same issue here on Ubuntu 22.04 |
Just tried to connect my BitBox2 after half a year. Updated the app and connected my device, but it doesn't get recognized.
BitBox2 says "See the BitBoxApp" but the app says "Please connect your device to get started".
I've enabled usb permissions as described in https://shiftcrypto.ch/download/
I read this article and verified that my device is connected.
I can't seem to find any error in the logs, so I just give you everything which might be important.
I also tried different usb ports. Everything works fine under Windows.
uname -a
dmesg when connecting the bitbox
lsusb | grep "BitBox"
bitbox log file
The text was updated successfully, but these errors were encountered: