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 > <torva...@linux-foundation.org> wrote: > > On Tue, Nov 14, 2017 at 10:52 AM, vavincavent <vavincav...@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 _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface