Scubapro Aladin Square

[vavincavent]

new usb.pcap file following 

     if (length < 31)
          length = 31;

Vincent

Le mardi 14 novembre 2017 à 11:29 -0800, Linus Torvalds a écrit :
> 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.co
> > m> 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.
> 
>                     Linus