How to get USB device descriptor by doing DeviceIoControl() directly on the device? - windows

I want to get the Device descriptor of USB devices on my system. I am creating a userspace application in Windows(un-managed, native c++ ). From these descriptors, I want to identify billboard devices and parse billboard capability descriptor (parsing bos descriptor).
Here is my approach.
Get USB devices on a system by SetupDiGetClassDevs(&GUID_CLASS_USB_DEVICE,...)
Get device path of each device using SetupDiGetDeviceInterfaceDetail()
Use CreateFile() on device path to get handle to the device.
Issue IOCTL_USB_GET_DESCRIPTOR_FROM_NODE_CONNECTION IOCTL using DeviceIoControl(), and the handle, to get the device descriptor.
I am stuck on the 4th step (getLastError() - Invalid Function).
Other projects (like this sample code from Intel), enumerate all USB controllers on the system, root hubs, ports, and interfaces, and issue IOCTL on the root hub's handle, specifying the port number to which a device is connected.
I do not want to concern myself with the USB hierarchy of the system.
It is less error-prone and easier to get USB devices in the system using setup API. However, nowhere I can see IOCTL being issued to them directly.
Update1
From learn.microsoft.com:
IOCTL_USB_GET_DESCRIPTOR_FROM_NODE_CONNECTION I/O control request retrieves one or more descriptors for the device that is associated with the indicated port index. This request targets the USB hub device (GUID_DEVINTERFACE_USB_HUB). Thus this ioctl which can give me device descriptor of a USB device is meant to be handled by USB Hub, and NOT by a USB device.
Therefore the other solutions pass handle of hub to DeviceIoControl(), as can be seen on Line 68 of the source code from Intel (Linked here).
I instead want to use the handle obtained in step 3 (handle of the device) above to get the device descriptor. So, the IOCTL could be different, or possibly there is a way to get handle of the hub, and index of port to which the device is connected using the handle of the USB device.
The way I see it, device descriptor is an intrinsic property of a USB device, and therefore there must be a way to get it directly from the USB device.

Assuming you already have USB device handle first you need to get DEVPKEY_Device_Driver property string from it (by means of CM_Get_DevNode_PropertyW or SetupDiGetDevicePropertyW).
You'll receive string like {36fc9e60-c465-11cf-8056-444553540000}\0010.
Next you need to iterate over each USB hub in system (devices that have GUID_DEVINTERFACE_USB_HUB interface) and for each:
Open it via CreateFile() call
Call DeviceIoControl(hubInterfaceHandle, IOCTL_USB_GET_NODE_INFORMATION, ...) to get USB_NODE_INFORMATION structure that contains number of USB ports in its hubInfo.u.HubInformation.HubDescriptor.bNumberOfPorts
For each port from 1 (they are one based!!!) to bNumberOfPorts call DeviceIoControl(hubInterfaceHandle, IOCTL_USB_GET_NODE_CONNECTION_DRIVERKEY_NAME, ...) to get unique DriverKey of device connected to this port.
Compare DriverKey string you have on previous step with string you have from DEVPKEY_Device_Driver call. If they are same - congratulations you have found USB hub and port that have your USB device connected!
Now you can call DeviceIoControl(usbHubInterfaceHandle, IOCTL_USB_GET_NODE_CONNECTION_INFORMATION, ...) to get USB_NODE_CONNECTION_INFORMATION structure that contains USB_DEVICE_DESCRIPTOR!
Also you can additionally call DeviceIoControl(usbHubInterfaceHandle, IOCTL_USB_GET_DESCRIPTOR_FROM_NODE_CONNECTION, ...) with USB_DESCRIPTOR_REQUEST to get other USB descriptors in addition to basic USB_DEVICE_DESCRIPTOR.
For example code see EnumerateHubPorts() and GetDriverKeyName() in official USBView sample.
Also I just did that in my RawInputDemo repo here.
UPDATE: There is easier way to get USB device number in a parent USB HUB - just get DEVPKEY_Device_Address property from a USB devnode.

Related

How do I pass SCSI (CDB) commands through a USB connection

I am trying to talk to a MSC USB device (interface class 8, subclass 6, protocol 0x50) via a plain USB API with endpoints (all set up for me).
Provided I have a valid CDB, such as for "Test Unit Ready", how to I send that over the USB interface?
Where can I find examples or docs for how this is done?
Background: The actual platform is macOS, which doesn't provide SCSI-passthrough for block devices, and the native SCSI API is also not available in this case.
I have, however, been able to initiate communication on the USB level with the device, and am now trying to circumvent the blocked SCSI device level access by talking thru USB directly.
Most such devices implement the so-called “Bulk Only” protocol, which is specified here: https://usb.org/document-library/mass-storage-bulk-only-10
Essentially, you send a 31-byte “Command Block Wrapper”, which includes the CDB and is specified in section 5.1 of the spec, to the device via the bulk out endpoint. You then read or write the data to be transferred from the input bulk endpoint or to the output bulk endpoint and finally read the 13-byte command status wrapper from the bulk in pipe.
However, note that you’ll need to make sure the OS hasn’t already loaded a driver for the device - from user space, the system won’t give you access to the endpoints when a kernel driver has claimed them anyway, but if you were to attempt to use the same pipes as the default driver from a kext, you’d get unpredictable results.

How to find serial number of USB serial adapter, given the COM port?

I want to get from a Windows COM port name (COM11) to the serial number of the USB device that provides that COM port (I'm presently working with FTDI adapters, if that matters).
I can use SetupDiGetClassDevs(&GUID_DEVCLASS_PORTS, NULL, NULL, DIGCF_PRESENT) to enumerate the ports on the system, then I can use SetupDiEnumDeviceInfo and SetupDiGetDeviceRegistryProperty to get the vid/pid out of the Hardware ID.
But I can't seem to figure out a way to get hold of the serial number.
The objective is to program the serial adapters with serial numbers that identify their usage for a simulator program we've got (so the user doesn't have to figure out which adapter is which COM port).
You can try using SetupDiGetDeviceInstanceId to get the Device Instance ID of USB device, which should be a string of the form USB\VID_xxxx&PID_xxxx\[ID]. If your USB device is not composite, then [ID] would be the serial number. This is how libusbp obtains the serial number of a USB device.
If your device is composite, the serial port would be a child device and you would have to go up one level to find the parent that represents the actual USB device, which should have the device instance ID that you care about.
Before writing any code, I'd recommend checking the Device Instance ID in your Device Manager, where it is known as "Device Instance Path".
To make you feel somewhat better about extracting the serial number from a string that has other information, the Device Instance ID is documented by Microsoft here:
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/device-instance-ids

Windows 10 FT_OpenEx() API open error when insert/remove other USB device

We have device ""FT245R USB FIFO" USB to Seriel for communication from Windows 10 using D2xx driver.
FT_OpenEx() API works without any issue. But whenever user unplug/plug new USB device(Mass storage device) , during that time FT_OpenEx() API failed to execute, so handle invalid and our data communication interepted. Could you let us know what can I do further to resolve this issue ?
Note: I have opened handle using following command FT_OpenEx("FT245R USB FIFO", FT_OPEN_BY_DESCRIPTION, &handle), I open it everytime, whenever I need to talk with communication device. tried with seriel number of the device , but still communication fails when unplug/plug other USB device.

How to find the device is connected to whether USB port 2.0 or USB port 3.00 ?

I just want to know how to find a usb device is connected to USB3.0 or USB2.0 port in window . I am using c++ and win32 API. please let me know your thoughts.
Based on how your question is phrased, I assume that you know when a device is connected, and need to know if the port it's connected is capable of USB 3.0 speeds.
Take a look at the USB_NODE_CONNECTION_INFORMATION_EX structure, and specifically the field Speed in it, which could correspond to a value defined in the enum USB_DEVICE_SPEED. For USB 3.0, the value of Speed would be UsbSuperSpeed.
The documentation page says that you could use IOCTL_USB_GET_NODE_CONNECTION_INFORMATION_EX request to obtain information about the connection associated with the indicated USB port.
You may also find the following remarks from the documentation helpful:
If there is no device connected, IOCTL_USB_GET_NODE_CONNECTION_INFORMATION_EX just returns information about the port.
If a device is connected to the port IOCTL_USB_GET_NODE_CONNECTION_INFORMATION_EX returns information about both the port and the connected device.
The USB_NODE_CONNECTION_INFORMATION_EX structure is an extended version of USB_NODE_CONNECTION_INFORMATION. The two structures are identical, except for one member. In the extended structure, the Speed member indicates the device speed.
I'd also encourage you to single-step through the usbview project which is part of the windows driver samples available in Github.

How does windows identify a USB device uniquely?

How does windows identify a USB device uniquely, even though the device data supplied from the USB device is common to all devices of that make ?
To state this alternatively, Windows can distinguish between two instances of Dell keyboards of same model, without the keyboard supplying any unique serial number. What is the exclusive data field windows searches for when initializing the USB device ?
Windows uses Device Instance ID for identification. As you can see in the documentation it contains a device part and an instance part.
The device part is taken from a USB device.
It is up to a bus driver how to generate the instance part. The bus driver cannot solely rely on the information returned from the usb device. Because two identical devices will break the system - Device Instance IDs must be unique! So usually it appends additional info - port number and etc (the exact algorithms is unknown and depends on driver manufacturer). Also PNP manager can add more uniqueness to the Instance ID.
When we connect a device to the host the device, enumeration process will happen, At the end of this process, the host will supply a unique address to the newly connected device. So each device connected to the system will have a unique Id which is supplied by the system, using this id devices can be identified and the communication happens

Resources