pcap control fixes #143
pcap control fixes #143
Conversation
libusb always sets the endpoint to 0x00 for control transfers. Hower, the setup data contains a direction, and the kernel will use this direction bit in the endpoint so we cannot compare them.
benzea
force-pushed
the
benzea/pcap-control-fixes
branch
from
19684ea
to
23fba1f
Compare
Other control transfers will not be submitted by the kernel and do not need to be ignored. This avoids replay issues as the transfers could be skipped accidentally otherwise.
benzea
force-pushed
the
benzea/pcap-control-fixes
branch
from
23fba1f
to
1e3031d
Compare
|
Tests timed out on ubuntu:devel, re-running. |
|
@benzea : Timed out again, this smells systematic.. |
|
Yeah, though not a regression in umockdev. The test that is timing out is the only one that is running Xorg internally. So, probably xorg is not shutting down. |
benzea
force-pushed
the
benzea/pcap-control-fixes
branch
from
f51f3e4
to
4aa973b
Compare
| @@ -256,8 +272,11 @@ internal class IoctlUsbPcapHandler : IoctlBase { | |||
| urb_buffer_length -= 8; | |||
| } | |||
|
|
|||
| /* libusb always sets URB_CONTROL endpoint to 0x00, but the | |||
| * kernel exposes it as 0x80/0x00 depending on the direction | |||
There was a problem hiding this comment.
FWIW, the direction is a flag, the endpoint is only 4 bits:
https://www.beyondlogic.org/usbnutshell/usb6.shtml
There was a problem hiding this comment.
Yeah. The funny thing is that bmRequestType and the endpoint byte of other packets are very similar yet different. So it would be correct to just copy the top bit from the setup data into the endpoint, but we can also just ignore it.
|
OK, quite confusing. I added debug printf's, and we seem to be hanging inside the |
benzea
force-pushed
the
benzea/pcap-control-fixes
branch
from
4aa973b
to
1e3031d
Compare
|
Confirmed that the ubuntu:devel hang is not a regression from this PR, it just failed the same way on master. @benzea has a hunch that it's related to libglib2.0-0 2.68.3 → 2.68.4 update. |
Issues discovered while creating the uru4000 test in libfprint.