By attaching a mouse over a network and using a TCP tunnel to sniff the usbip packets and wireshark to sniff the corresponding urb's, I was able to collect the following:
What's confusing is that the seqnum = 2 packet has a setup.bmRequestType.rType of "Standard" (0x00), but the wireshark capture clearly shows "Class" (0x01)
The value for SET_IDLE happens to be 0x0a which coincidentally lines up with the value of the Standard GET_INTERFACE request
By attaching a mouse over a network and using a TCP tunnel to sniff the usbip packets and wireshark to sniff the corresponding urb's, I was able to collect the following:
URB capture:![image](https://user-images.githubusercontent.com/16297868/129276078-8c210e63-ec22-49e9-9cb0-e61b72a1473e.png)
raw USBIP capture (decimal):
parsed USBIP capture:
What's confusing is that the
seqnum = 2
packet has asetup.bmRequestType.rType
of "Standard" (0x00), but the wireshark capture clearly shows "Class" (0x01)The value for SET_IDLE happens to be![image](https://user-images.githubusercontent.com/16297868/129278438-16897d65-90ed-4ccc-9491-39fb2390a193.png)
0x0a
which coincidentally lines up with the value of the Standard GET_INTERFACE requestbut....
process_standard_request
doesn't accept GET_INTERFACEhttps://github.com/cezanne/usbip-win/blob/692ccb5f28acbebcf2488e7e8a79492ed8d44574/driver/stub/stub_write.c#L175-L200
The daemon must be processing the data somehow because I am able to capture the response (both usbip and urb).