Yubikey works #6
Conversation
| @@ -52,9 +52,10 @@ public static int doBulkTransfer(UsbDeviceConnection devConn, UsbEndpoint endpoi | |||
|
|
|||
| bytesTransferred += res; | |||
|
|
|||
| if (res < endpoint.getMaxPacketSize()) { | |||
| if (res != endpoint.getMaxPacketSize()) { | |||
There was a problem hiding this comment.
Hmm, I wonder if this is needed or if the while condition is sufficient. Does it work properly if you remove this check entirely?
There was a problem hiding this comment.
First of all the request comes with buff.length (expected) size of 65536. The only reasonable interpretation is maximum size. So we can't check buff.length vs. transferred size. Yubikey is sending back a certificate which is a variable size.
Second, I know this code is by definition wrong, because I can manipulate certificate to be exactly max packet size.
Now back to your question.
If I take the condition out it will terminate with timeout and return error.
Perhaps if there is nothing more, it would return right away. Nop, it is a real timeout with 1000ms.
I am reading the server part of the linux driver to figure out how it is done. First impression, things depend on transfer flags.
|
@cgutman, what are the original target devices? I assumed the primary use was a USB memory stick. |
It's been so long that I don't remember. Maybe a USB drive and gamepad?
I'm not sure. A bulk transfer from a mass-storage device seems like it would work. |
|
I have tested with a couple of memory sticks and in all cases all communication is completed with one call to bulkTransfer. I was not able to trigger any communication which would require 2 calls to bulkTransfer. How about removing the while loop? Can you think of any other devices with bulk transfer to get more testing? |
Yeah, I guess that's probably fine. |
Here are 2 fixes which make it possible to use yubikey remotely.
GPT suggested that detecting the end of bulk transfer is not universal condition and can depend on a device.
One of the logic listed was exactly what the original code did. If api gives back less than what max packet size is, that is the end of transmission. However, for yubikey it is actually more than max packet size. This hints at possibility that android api reports wrong max size or android api reassemble packets before giving it back or reported max size is wrong or something else. For now this is the fix. I will keep digging - have to look at android api source and probably check what yubikey tools are doing.