Hello,
on Wednesday 12 February 2020 at 11:56, Stuart Henderson wrote:
> On 2020/02/12 10:19, Natasha Kerensikova wrote:
> > Since you all probably don't have the device, I don't expect a fix, but
> > I would be very interested in what I can do to further diagnose the
> > issue. I guess it would be nice to spy on what is going on in the USB
> > wire, but I don't have that kind of hardware. So I was hoping you could
> > help me navigate the USB stack to dump useful information.
>
> Linux and OpenBSD both support USB packet capture, you could compare
> traces (taken with tcpdump or wireshark) between the two, maybe that will
> give some clues.
Thanks a lot for pointing it out, I really had no idea such capture
existed and was so easy.
According to what I dumped on Linux, the whole enumeration thing is
cached, and repeated runs of my test program only registers as the
following exchange:
18:52:45.521580 BULK SUBMIT to 1:18:2
0x0000: 1b03 ..
18:52:45.521617 BULK COMPLETE from 1:18:2
18:52:45.521700 BULK SUBMIT to 1:18:1
18:52:45.521819 BULK COMPLETE from 1:18:1
0x0000: 0800 ..
In OpenBSD, there are several exchanges of control packets before the
bulk operations, which seem to be four "GET DESCRIPTOR Request
CONFIGURATION", the odd ones requesting 9 bytes and the even ones
requesting 32 bytes.
So I tried cutting the exploration code from the test case, jumping
directly from the loop after libusb_get_device_list() to the sequence
libusb_open(), libusb_claim_interface(), libusb_bulk_transfer(),
libusb_bulk_transfer(), libusb_close().
Following that change, I still have the same symptoms, but without the
control exchanges. Here is the successful exchange:
23:05:50.796876 bus 0 > addr 8: ep2 bulk 2
0000: 1b03 ..
23:05:50.796895 bus 0 < addr 8: ep2 bulk 0
23:05:50.809142 bus 0 > addr 8: ep1 bulk 0
23:05:50.809163 bus 0 < addr 8: ep1 bulk 2
0000: 0800 ..
And here is the failing one:
23:05:52.829576 bus 0 > addr 8: ep2 bulk 2
0000: 1b03 ..
23:05:52.829640 bus 0 < addr 8: ep2 bulk 0
23:05:52.830543 bus 0 > addr 8: ep1 bulk 0
23:06:02.828968 bus 0 < addr 8: ep1 bulk 0
23:06:02.829025 bus 0 > addr 8: ep0 ctrl 8
0000: 0002 0100 0081 0000 00 .........
23:06:02.829027 bus 0 > addr 8: ep0 ctrl 0
0000: 01 .
23:06:02.829227 bus 0 < addr 8: ep0 ctrl 0
0000: 02 .
23:06:11.359685 bus 0 < addr 4: ep1 intr 8
0000: 0100 0000 0000 0000 ........
So at this point, nothing I see on the capture explains the difference
of behavior between Linux and OpenBSD.
More intriguing is the fact that according to the capture, when the 10s
timeout occurs, the devices sends an empty response packet to the host,
but nothing in the capture ever says that the timeout is 10s. How is
this transmitted to the device?
It's probably unrelated, but there must be something somewhere that is
left different after the first (successful) exchange and which makes the
subsequent exchanges fail, and I still have no clue on whether the
"memory" is on the host OS or in the device.
Being out of ideas, I followed my intuition about some deinitialization
issue, and tried to reproduce the issue using a single executable run.
The result is available at
https://upload.instinctive.eu/t3QWc3v5LW-MzqNJ_twkqVenpvc/test-usb2.c
Basically, if I use two pairs libusb_bulk_transfer() in a row,
everything works fine, but I release the interface and claim it again
between them, I reproduce the timeout problem.
So at this point, I suspect that libusb_claim_interface() does not
exactly undo what libusb_release_interface().
Any idea on how to proceed at this point?
Thanks for your help,
Natasha
