You can reduce this by ignoring URBs without any data_fragment or capdata, since only in a few cases these are useful in understanding the protocol. Wireshark actually works one level of abstraction bellow what I called a transfer, with USB request blocks (URBs), so there's a lot of uninteresting entries in the captured data. Next, I would add a few custom columns: usb.data_fragment for data sent in control transfers, and usb.capdata for data exchanged in the other types of transfers. You should know that the address on the bus can change, from OS to OS, from boot to boot or if the device is reconnected. I usually save these results into a new file, and only use it from that point forward.Īnother way to find the device address, which can be useful when dealing with old captures or captures made in another OS or machine, it to look in the various GET DESCRIPTOR DEVICE responses for the one that matches the idVendor you're interested in.
If you know the device address in the bus you can filter with usb.device_address =, and in Linux it's easy to find the device address with lsusb. How do you approach that data?įirst, I would filter the packets to only those coming from or being sent to the device you're interested at. So, you have captured some USB traffic to your device with Wireshark. The distinction does matter in a few places, most notability around the "report ID", but I'll get to that later. Working with HID protocols is almost identical to working with other classes of USB devices: they use control transfers and interrupt transfers, and we capture them with Wireshark. USB HIDs are a special type of USB device specified by a corresponding "interface class".¹ In fact, it's rather common that we need to work on a layer further up the abstraction chain, on a Human Interface Device (HID). I'll skip over the purposes of each type since we'll merely use whichever ones the protocol mandates.īut our devices at not necessarily always manipulated as USB devices. Transfers can be of a few different types, but for the most part we're only interested in control transfers, interrupt transfers and, very occasionally, bulk transfers. Since that "proper" post isn't happening any time soon, I'll just go over the main ideas here, and we can explore more details as needed.īut before anything else: as far as I know the H100i GT does indeed use a different protocol.Īt a basic level you can view USB traffic as a collection of transfers. I've been meaning to write a blog post about some of the techniques I use, but I always get stuck on the least interesting (even if probably as important) parts about dealing with the tools.
#Corsair h110i gtx drivers drivers#
This comment became Techniques for analyzing USB protocols.Īccompanying document: Porting drivers from OpenCorsairLink.
0 kommentar(er)
