Scubapro Aladin Square

[Jef Driesen]

On 14-11-17 20:29, Linus Torvalds wrote:
> On Tue, Nov 14, 2017 at 11:17 AM, Linus Torvalds
> <torvalds at linux-foundation.org> wrote:
>> On Tue, Nov 14, 2017 at 10:52 AM, vavincavent <vavincavent at 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