{"action":"created","issue":{"url":"https://api.github.com/repos/desowin/usbpcap/issues/63","repository_url":"https://api.github.com/repos/desowin/usbpcap","labels_url":"https://api.github.com/repos/desowin/usbpcap/issues/63/labels{/name}","comments_url":"https://api.github.com/repos/desowin/usbpcap/issues/63/comments","events_url":"https://api.github.com/repos/desowin/usbpcap/issues/63/events","html_url":"https://github.com/desowin/usbpcap/issues/63","id":377767422,"node_id":"MDU6SXNzdWUzNzc3Njc0MjI=","number":63,"title":"Odd output for certain USB functions when viewed in Wireshark","user":{"login":"MartyMacGyver","id":1078647,"node_id":"MDQ6VXNlcjEwNzg2NDc=","avatar_url":"https://avatars3.githubusercontent.com/u/1078647?v=4","gravatar_id":"","url":"https://api.github.com/users/MartyMacGyver","html_url":"https://github.com/MartyMacGyver","followers_url":"https://api.github.com/users/MartyMacGyver/followers","following_url":"https://api.github.com/users/MartyMacGyver/following{/other_user}","gists_url":"https://api.github.com/users/MartyMacGyver/gists{/gist_id}","starred_url":"https://api.github.com/users/MartyMacGyver/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/MartyMacGyver/subscriptions","organizations_url":"https://api.github.com/users/MartyMacGyver/orgs","repos_url":"https://api.github.com/users/MartyMacGyver/repos","events_url":"https://api.github.com/users/MartyMacGyver/events{/privacy}","received_events_url":"https://api.github.com/users/MartyMacGyver/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-11-06T09:51:10Z","updated_at":"2018-11-06T11:33:49Z","closed_at":null,"author_association":"NONE","body":"_tl;dr - I've been looking at the USB traffic to a simple little USB device (a fan with a programmable display), and couldn't figure out how the actual data was being sent. Turns out it's being captured but either the capture is wonky or Wireshark is incorrectly displaying this data._\r\n\r\nUSBpcap 1.2.0.4 (via the current version of Wireshark 2.6.4) on Windows 10 x64 shows all sorts of useful traffic: `USB_CONTROL out`, `SET CONFIGURATION Status`, `USB_INTERRUPT in`... but none of that appeared to have any data. In fact, other than IDs all the traffic from the host to the device (which the analyzer only showed being `USB_CONTROL out` traffic) was basically identical.\r\n\r\nSo, I gave USBlyzer a trial - it sees all that traffic, but it also sees `URB_FUNCTION_CLASS_INTERFACE`/`URB_FUNCTION_CONTROL_TRANSFER` traffic right before each of those `USB_CONTROL out` requests:\r\n\r\nFirst frame, out to the device:\r\n```\r\nDevice Object\tFFFF838D8636DA60h\r\nDriver Object\tUSBPcap\r\n\r\nURB Function\tURB_FUNCTION_CLASS_INTERFACE\r\n\r\nRequest\tSet Report\r\nReport Type\tOutput\r\nReport Length\t8\r\n```\r\n(I can see the raw 8 bytes in here)\r\n\r\nFollowed by another frame, also out to the device (though I'm not sure that's correct as it appears to be a response):\r\n```\r\nDevice Object\tFFFF838D8636DA60h\r\nDriver Object\tUSBPcap\r\n\r\nURB Function\tURB_FUNCTION_CONTROL_TRANSFER\r\nURB Status\tUSBD_STATUS_SUCCESS\r\n\r\nEndpoint 0\tDefault Control\r\n\r\nRequest\tSet Report\r\nReport Type\tOutput\r\nReport Length\t8\r\n```\r\n\r\nThe raw data (e.g., `40 23 94 84 94 84 94 27`) appears to be what I expect (the format of the data is unclear but it's not compressed and varies in a way that strongly suggests it's exactly what I'm looking for). Clearly it's going through the USBPcap driver. Neither that traffic nor that data is in the Wireshark output.\r\n\r\nThat all said, I got curious and looked at the actual PCAP file in a hex editor... _and there I see the those exact bytes_, along with other unique patterns corresponding to the other requests I so far have only been able to view in USBlyzer.\r\n\r\nAnd so I searched for that same hex data in Wireshark and *also* found... but as part of the URB_CONTROL in from the device, which is very peculiar (and apparently is not really what's happening on the wire). Here's an example that corresponds with the one above (I re-did the first test).\r\n\r\nFrame from host to 1.2.0 (device):\r\n```\r\nFrame 61: 36 bytes on wire (288 bits), 36 bytes captured (288 bits)\r\n    Encapsulation type: USB packets with USBPcap header (152)\r\n    Arrival Time: Nov  6, 2018 00:49:17.477649000 Pacific Standard Time\r\n    [Time shift for this packet: 0.000000000 seconds]\r\n    Epoch Time: 1541494157.477649000 seconds\r\n    [Time delta from previous captured frame: 0.000047000 seconds]\r\n    [Time delta from previous displayed frame: 0.000047000 seconds]\r\n    [Time since reference or first frame: 0.623433000 seconds]\r\n    Frame Number: 61\r\n    Frame Length: 36 bytes (288 bits)\r\n    Capture Length: 36 bytes (288 bits)\r\n    [Frame is marked: False]\r\n    [Frame is ignored: False]\r\n    [Protocols in frame: usb]\r\nUSB URB\r\n    [Source: host]\r\n    [Destination: 1.2.0]\r\n    USBPcap pseudoheader length: 28\r\n    IRP ID: 0xffff838d8e6aa010\r\n    IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000)\r\n    URB Function: URB_FUNCTION_CLASS_INTERFACE (0x001b)\r\n    IRP information: 0x00, Direction: FDO -> PDO\r\n        0000 000. = Reserved: 0x00\r\n        .... ...0 = Direction: FDO -> PDO (0x0)\r\n    URB bus id: 1\r\n    Device address: 2\r\n    Endpoint: 0x00, Direction: OUT\r\n        0... .... = Direction: OUT (0)\r\n        .... 0000 = Endpoint number: 0\r\n    URB transfer type: URB_CONTROL (0x02)\r\n    Packet Data Length: 8\r\n    [Response in: 62]\r\n    Control transfer stage: Setup (0)\r\n    [bInterfaceClass: Unknown (0xffff)]\r\nURB setup\r\n    bmRequestType: 0x21\r\n        0... .... = Direction: Host-to-device\r\n        .01. .... = Type: Class (0x1)\r\n        ...0 0001 = Recipient: Interface (0x01)\r\n    bRequest: 9\r\n    wValue: 0x0200\r\n    wIndex: 0 (0x0000)\r\n    wLength: 8\r\n```\r\n\r\nFrame from 1.2.0 (device) to host:\r\n```\r\nFrame 62: 36 bytes on wire (288 bits), 36 bytes captured (288 bits)\r\n    Encapsulation type: USB packets with USBPcap header (152)\r\n    Arrival Time: Nov  6, 2018 00:49:17.478230000 Pacific Standard Time\r\n    [Time shift for this packet: 0.000000000 seconds]\r\n    Epoch Time: 1541494157.478230000 seconds\r\n    [Time delta from previous captured frame: 0.000581000 seconds]\r\n    [Time delta from previous displayed frame: 0.000581000 seconds]\r\n    [Time since reference or first frame: 0.624014000 seconds]\r\n    Frame Number: 62\r\n    Frame Length: 36 bytes (288 bits)\r\n    Capture Length: 36 bytes (288 bits)\r\n    [Frame is marked: False]\r\n    [Frame is ignored: False]\r\n    [Protocols in frame: usb]\r\nUSB URB\r\n    [Source: 1.2.0]\r\n    [Destination: host]\r\n    USBPcap pseudoheader length: 28\r\n    IRP ID: 0xffff838d8e6aa010\r\n    IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000)\r\n    URB Function: URB_FUNCTION_CONTROL_TRANSFER (0x0008)\r\n    IRP information: 0x01, Direction: PDO -> FDO\r\n        0000 000. = Reserved: 0x00\r\n        .... ...1 = Direction: PDO -> FDO (0x1)\r\n    URB bus id: 1\r\n    Device address: 2\r\n    Endpoint: 0x00, Direction: OUT\r\n        0... .... = Direction: OUT (0)\r\n        .... 0000 = Endpoint number: 0\r\n    URB transfer type: URB_CONTROL (0x02)\r\n    Packet Data Length: 8\r\n    [Request in: 61]\r\n    [Time from request: 0.000581000 seconds]\r\n    Control transfer stage: Data (1)\r\n    [bInterfaceClass: Unknown (0xffff)]\r\nCONTROL response data: 40238494a4a4a467\r\n```\r\n\r\nSo, the question I have is, where's the problem? Is this a case of USBPcap not saving the data correctly? Or is Wireshark failing to properly decode said data?\r\n\r\nI've attached the PCAP of interest here (I'd include the USBlyzer file but it appears to have a lot more info buried in it than I'd want to post publicly - contact me if you're interested in that.)\r\n\r\n[Test5.zip](https://github.com/desowin/usbpcap/files/2552522/Test5.zip)\r\n\r\nI came here first because - until I was halfway through writing this - it appeared the data wasn't getting collected to begin with. Clearly it is though but I'm not sure where the problem is. I'm also not sure what the authors of USBPcap have to do with the Wireshark side of things (especially when it comes to deciphering and displaying said pcap data). I'm happy to open this ticket up there if it's preferred.\r\n\r\n(And as an aside my brief encounter here with USBlyzer - which hasn't been updated in years and which may not be accurately showing the direction of responses - reminds me why I like to use tools like Wireshark and USBPcap. At least here I have hope of getting an answer that may lead to an eventual fix if needed! **Thanks in advance for any insight you may have on this vexing problem!**)"},"comment":{"url":"https://api.github.com/repos/desowin/usbpcap/issues/comments/436222403","html_url":"https://github.com/desowin/usbpcap/issues/63#issuecomment-436222403","issue_url":"https://api.github.com/repos/desowin/usbpcap/issues/63","id":436222403,"node_id":"MDEyOklzc3VlQ29tbWVudDQzNjIyMjQwMw==","user":{"login":"MartyMacGyver","id":1078647,"node_id":"MDQ6VXNlcjEwNzg2NDc=","avatar_url":"https://avatars3.githubusercontent.com/u/1078647?v=4","gravatar_id":"","url":"https://api.github.com/users/MartyMacGyver","html_url":"https://github.com/MartyMacGyver","followers_url":"https://api.github.com/users/MartyMacGyver/followers","following_url":"https://api.github.com/users/MartyMacGyver/following{/other_user}","gists_url":"https://api.github.com/users/MartyMacGyver/gists{/gist_id}","starred_url":"https://api.github.com/users/MartyMacGyver/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/MartyMacGyver/subscriptions","organizations_url":"https://api.github.com/users/MartyMacGyver/orgs","repos_url":"https://api.github.com/users/MartyMacGyver/repos","events_url":"https://api.github.com/users/MartyMacGyver/events{/privacy}","received_events_url":"https://api.github.com/users/MartyMacGyver/received_events","type":"User","site_admin":false},"created_at":"2018-11-06T11:33:49Z","updated_at":"2018-11-06T11:33:49Z","author_association":"NONE","body":"Thanks for the quick reply! I honestly thought it was some weirdness in Wireshark itself. What's the roadmap to 1.3.0.0 (or possibly 1.2.0.5)?\r\n\r\nThe Readme is a bit confusing as far as the signing situation goes (TESTSIGNING never came up for me). Not sure how that's related to your #57."}}
{"actor":{"display_login":"MartyMacGyver"}}