On Mon, Oct 28, 2019 at 12:07:20PM +1100, Damien Miller wrote: > On Mon, 28 Oct 2019, Damien Miller wrote: > > > On Fri, 25 Oct 2019, Patrick Wildt wrote: > > > > > > So from what I understood the Yubikey expects the transfer to happen > > > > on the Interrupt OUT pipe instead of doing a control transfer. Read- > > > > ing some code and documentation, it looks like that we should by de- > > > > fault send our reports on the interrupt pipe, and only if it does not > > > > exist fall back to control transfers. Linux seems to do exactly that. > > > > > > > > I tried to come up with the following diff, which appeard to make a > > > > test program work for me. Though I'm not sure I got all the specifics > > > > right. > > > > > > > > Can you give this a go with your test progam? > > > > > > > > Patrick > > > > > > Oops, obvious error. Though I still cannot write/read multiple times > > > in a row, so there is probably still something wrong (unless my test > > > is as well). > > > > It didn't work for me - I think because uhidev_set_report() (and _async) > > is still prepending a report ID. If I modify uhid.c to send writes > > without a report ID, then it does work: > > BTW, the token still becomes unresponsive after the first transaction, > but looking at a sniff (using an OpenViszla), it seems we're getting the > DATA0/DATA1 flipping incorrect on the wire. > > On OpenBSD, this is the last rx of the transaction with the card: > > [ ] 12.992349 d= 0.001951 [154.0 + 3.500] [ 3] IN : 8.4 > [ ] 12.992352 d= 0.000003 [154.0 + 6.667] [ 67] DATA0: 00 10 00 01 > 0e 1b 4a 78 ec 87 06 bd 47 d4 a0 49 d9 c7 2d 89 d9 7e 2c c5 62 87 53 92 9b 90 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 3a e8 > > and this is the first tx of the first packet of the subsequent transaction > that hangs: > > [ ] 22.201067 d= 0.001998 [146.0 + 4.333] [ 3] OUT : 8.4 > [ ] 22.201070 d= 0.000003 [146.0 + 7.583] [ 67] DATA0: ff ff ff ff > 86 00 08 c0 65 eb 53 9a 48 04 7d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 d6 1d > > On Linux, the sequence bit does get flipped between the last rx: > > [ ] 14.174783 d= 0.001951 [214.0 + 3.417] [ 3] IN : 24.4 > [ ] 14.174786 d= 0.000003 [214.0 + 6.583] [ 67] DATA0: 00 12 00 01 > 0e 2e 25 14 32 f4 a4 68 d1 81 d1 29 e1 47 6f 4c 7d e2 69 dc b9 96 e5 f5 23 90 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 be 67 > > and the tx of the next attempt: > > [ ] 20.057155 d= 0.001997 [208.0 + 3.417] [ 3] OUT : 24.4 > [ ] 20.057158 d= 0.000003 [208.0 + 6.667] [ 67] DATA1: ff ff ff ff > 86 00 08 82 40 e5 bf c6 94 7e e8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 22 8b > > I think it's losing the sequence bit state across open/close of > /dev/uhidX - If I try to do two transactions without an intervening > close/open then it seems to work... > > -d
I have also sniffed this on both OpenBSD with xhci(4) and some Linux. Turns out, yes, we're always doing DATA0 instead of toggling to DATA1 and back. But I'm not sure where exactly this happens. I'll investigate. Patrick
