On 14-11-17 20:29, Linus Torvalds wrote:
On Tue, Nov 14, 2017 at 11:17 AM, Linus Torvalds
<torva...@linux-foundation.org> wrote:
On Tue, Nov 14, 2017 at 10:52 AM, vavincavent <vavincav...@gmail.com> wrote:
and ... i join usb.pcap file!
Ok, that's a good dump. I see
- device 1: root hub (1d6b:0002)
- device 2: logitech LX710 (046d:c517)
- device 3: RealTek RTS5129 card reader (0bda:0129)
- device 4: Realtek something (0bda:57de) Wifi?
- device 59: Lite-On bluetooth donge (04ca:3018)
- device 60: c251:2006
I assume that matches what you'd expect on that bus?
So it's that device 60.
And the only traffic I see there is (apart from the two empty reads)
is that one URB_INTERRUPT write packet with data 0110.
Very odd.
Also, for some reason wireshark is not showing it as a USB HID
protocol thing. That's odd. I was pretty sure wireshark should do
that.
Oh, it only does that for the setup packets that aren't there.
And I do notice a big difference to what I get when I do a similar dump.
Your dump shows:
Frame 1573: 66 bytes on wire (528 bits), 66 bytes captured (528
bits) on interface 0
USB URB
[Source: host]
[Destination: 1.60.2]
URB id: 0xffff97a01200de40
URB type: URB_SUBMIT ('S')
URB transfer type: URB_INTERRUPT (0x01)
Endpoint: 0x02, Direction: OUT
Device: 60
URB bus id: 1
Device setup request: not relevant ('-')
Data: present (0)
URB sec: 1510685037
URB usec: 39850
URB status: Operation now in progress (-EINPROGRESS) (-115)
URB length [bytes]: 2
Data length [bytes]: 2
[Response in: 1574]
[bInterfaceClass: Unknown (0xffff)]
Unused Setup Header
Interval: 8
Start frame: 0
Copy of Transfer Flags: 0x00000000
Number of ISO descriptors: 0
Leftover Capture Data: 0110
for that 0110 command packet.
When I do it, I get:
Frame 579: 95 bytes on wire (760 bits), 95 bytes captured (760 bits)
on interface 0
USB URB
[Source: host]
[Destination: 3.6.1]
URB id: 0xffff914c372596c0
URB type: URB_SUBMIT ('S')
URB transfer type: URB_INTERRUPT (0x01)
Endpoint: 0x01, Direction: OUT
Device: 6
URB bus id: 3
Device setup request: not relevant ('-')
Data: present (0)
URB sec: 1510686848
URB usec: 546665
URB status: Operation now in progress (-EINPROGRESS) (-115)
URB length [bytes]: 31
Data length [bytes]: 31
[Response in: 580]
[bInterfaceClass: HID (0x03)]
Unused Setup Header
Interval: 4
Start frame: 0
Copy of Transfer Flags: 0x00000000
Number of ISO descriptors: 0
Leftover Capture Data: 011b00000000000000000000000000000000000000000000...
Notice the different in Data length and padding.
So I think what's going on here is that different versions of libusb
end up padding things differently, and your dive computer doesn't like
the short packets that your version of libusb creates.
I dunno. Maybe it's some other thing that results in this difference.
Anyway, let's just hack around it and test, See that
"libusb_interrupt_transfer()" call in the function dc_usbhid_write()
in src/usbhit.c?
Add something like
if (length < 31)
length = 31;
to just before it. It will send garbage padding, but the dive computer
sends _us_ garbage padding, so that's probably ok.
It's a horrible hack, but it's just for testing.
I suspect this is not caused by a difference in the libusb version, but a
difference in the subsurface branch of libdivecomputer. If you look at the
g2.log of the successful download on Windows, then you can clearly see
libdivecomputer is sending out 33 byte packets (1 byte report id and 32 bytes
payload). So somehow the subsurface branch doesn't use the right size. It's
probably the csize+1 in this code:
// BLE GATT protocol?
if (io->packet_size < 64) {
// No report type byte
status = io->packet_write(io, buf+1, csize+1, &transferred);
} else {
status = io->packet_write(io, buf, sizeof(buf), &transferred);
}
I don't have an explanation for the 32 vs 31 bytes.
Jef
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
