0

I have a usb sniff from snoopypro for a device I'm trying to communicate with. I've found that once the device is set up I can communicate with it via bulk messages but I'm having trouble replicating the setup messages. Some of these messages are labeled 'VENDOR_DEVICE' in snoopy and I can't figure out how to send these messages as control transfer messages with pyusb; or even how to decipher what data is what. I suspect that I'm misunderstanding the sniff (or snoopy's interpretation) OR is there an issue with pyusb?

Here's a sniff. 

82    in down    n/a    13.669    VENDOR_DEVICE    -    
URB Header (length: 80)
SequenceNumber: 82
Function: 0017 (VENDOR_DEVICE)
PipeHandle: ff98e578

SetupPacket:
0000: 00 05 00 00 00 00 02 00 
bmRequestType: 00
  DIR: Host-To-Device
  TYPE: Standard
  RECIPIENT: Device
bRequest: 05  
  SET_ADDRESS


No TransferBuffer

Here are a few different lines I've tried. Every combination gives me '[errno 32] pipe error' or '[Errno None] Other error'. The pipe error appears to indicate that the device doesn't support that command. I'm not sure about the Errno None error. 

dev.ctrl_transfer(0x00, 0x05, 0x0000, 0x0000, 0x0200)

dev.ctrl_transfer(0x20, 0x05, 0x0000, 0x0000, 0x0200)

dev.ctrl_transfer(0x80, 0x05, 0x0000, 0x0000, 0x0200)

dev.ctrl_transfer(0x20, 0x05, 0x0000, 0x0000, 0x0002)

Conversely, I CAN send a get status message to 0x80 and it goes through. 

dev.ctrl_transfer(0x80, 0x00, 0x0000, 0x0000, 0x0000)
chmedly
  • 391
  • 1
  • 6
  • 16

1 Answers1

0

So, my suggestion is to avoid snoopypro if possible. It's quite old and doesn't apparently even work on Win7, 8 or 10. [I used it initially with Winxp running in a virtualbox.] I ended up using Microsoft Message Analyzer (MMA) to re-snoop while running Windows 10 and found a lot more info about what was happening.

One of the crucial issues was that snoopy was identifying the packet in question as a VENDOR_DEVICE message but was not indicating the correct HEX byte for that bRequestType. It showed simply '00' when it should have been '40' (0x40). btw, somewhere else on the interwebs I found a post about how VENDOR_DEVICE is simply a control transfer message with a request type of 0x20 so earlier on in my efforts I tried to run with that. Well, 0x2 is, I suppose, technically correct if you are looking only at bits 5,6 but when you look at the entire nibble, it would be 0x4. In hind sight, looking at the USB control packet chart, it all makes sense. This, and some other minor misunderstandings about which packets where important are what caused my issues. The set address command shown in my question isn't actually necessary with this case. I was able to initialize this device with a few simple control transfer commands directed with the correct request type. For example:

dev.ctrl_transfer(0x40, 0x03, 0x0034, 0x0000, 0x0000)

MMA is free from Microsoft and had an update in early 2017. I suspect they will continue to keep it current. It takes a little bit of work to set it up compared to snoopypro and some of the others but it has a lot of features and capabilities.
https://blogs.msdn.microsoft.com/usbcoreblog/2013/11/08/capturing-usb-etw-traces-with-microsoft-message-analyzer-mma/

chmedly
  • 391
  • 1
  • 6
  • 16