backend/usb/hid: prepend 0 byte to packet #1809
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If a USB packet starts with a zero byte, that byte will be stripped by the C USB library (i.e. signal11 on Linux), leading to a broken package. We only need to add it if not on Windows, as karalabel/usb prepends this zero byte already for Windows (I think this is a bug in karalabe/usb and karalabe/hid, which didn't consider that a packet could start with a zero byte right after the report ID). Currently we don't observe a bug because the first byte in each packet is the `cid` (channel identifier), which is currnetly harddcoded to `0xff000000` in bitbox02-api-go. If we start using a random CID, and it starts with a zero byte, the packet will be corrupted and the BitBox02 will not be able to parse it. The same fix was also added to the bitbox01 in the BitBoxApp (https://github.com/digitalbitbox/bitbox-wallet-app/blob/bd70f6c400268355cee94891397447796f02fbde/backend/devices/bitbox/communication.go#L235-L241), where it was crucial because packets in the bitbox01 are padded with zero bytes to the left. We can remove the fix there, as it uses the same hid functions as the BitBox02.
|
I need to test this on bitbox01 (bootloader, firmware) and bitbox02 (bootloader, firmware) on all supported platforms. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If a USB packet starts with a zero byte, that byte will be stripped by the C USB library (i.e. signal11 on Linux), leading to a broken package.
We only need to add it if not on Windows, as karalabel/usb prepends this zero byte already for Windows (I think this is a bug in karalabe/usb and karalabe/hid, which didn't consider that a packet could start with a zero byte right after the report ID).
Currently we don't observe a bug because the first byte in each packet is the
cid(channel identifier), which is currnetly harddcoded to0xff000000in bitbox02-api-go. If we start using a random CID, and it starts with a zero byte, the packet will be corrupted and the BitBox02 will not be able to parse it.The same fix was also added to the bitbox01 in the BitBoxApp (https://github.com/digitalbitbox/bitbox-wallet-app/blob/bd70f6c400268355cee94891397447796f02fbde/backend/devices/bitbox/communication.go#L235-L241), where it was crucial because packets in the bitbox01 are padded with zero bytes to the left. We can remove the fix there, as it uses the same hid functions as the BitBox02.