I have a device driver with misc_register() API being called to create a serial device. Now, I want to call misc_deregister() because the device does not function any more due to hardware change (for example removal of cable of the serial port). Now the application has opened this device and performing operations on it, so there is an open file descriptor for this device.
I want to know if the driver wait for the application to call release (or close() API) on the device before calling misc_deregister()? Or can the driver call misc_deregister() and then it can still receive a (last) release callback?
Related
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.
I am developing a Win32 application for a Windows 10 tablet that shall connect to a embedded device via Bluetooth. The embedded device uses the Telit BlueMod+SR as bluetooth module.
In Windows, I use the interface from "bluetoothapis.h" for Connection and Pairing and winsock2 for communication.
I have to implement pairing using passkey entry between the devices, initiated by the Windows tablet. The tablet provides passkey entry, the embedded device is display-only.
The way it works at the moment is that:
Windows creats a non-blocking socket and configures it as requiring authentication by setting SO_BTH_AUTHENTICATE.
Windows passes my Authentication Callback to BluetoothRegisterForAuthenticationEx().
Windows calls ConnectEx() on the remote BT device.
If successful, the Authentication Callback is executed, giving me the passkey (which is displayed by the embedded device).
The user is asked to input the passkey on the tablet which then compares the input with the passkey from the Authentication callback.
My problem is, although it works, I think that this is not the way the passkey entry is intended. It doesn't feel like a valid way to establish a secure connection since the embedded device seems to transmit the passkey via Bluetooth to the tablet.
Should the passkey be openly transmitted via Bluetooth from the remote device to the initiating device?
Or should the user be the only one that gives the passkey to the tablet?
If the way it is implemented is wrong:
Does somebody have an idea why the passkey is available through the Authentication Callback on Windows? I guess there is something wrong with the configuration of the BlueMod module, but I haven't been able to change the behavior.
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.
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.
I am using the 32feet bluetooth library to connect to a device that supports Serial Port Profile (SPP). I try to connect like this:
using (BluetoothClient client = new BluetoothClient())
{
var address = new BluetoothAddress(0xecfe7e11c3af);
BluetoothEndPoint endPoint = new BluetoothEndPoint(address, BluetoothService.SerialPort);
client.Connect(endPoint);
var stream = client.GetStream();
System.Threading.Thread.Sleep(10000);
}
Everything is great until the Connect method is called. At this point, Windows interrupts the program flow with a bubble alert that says
"A bluetooth device is trying to connect -- click to allow this"
At which point the user is led through a wizard that ends up installing drivers and a Bluetooth virtual COM port shows up in Device Manager. I don't want this to happen -- I want to simply access the stream and communicate directly with the device without windows intervening. Is this possible? What can be done to tell Windows to keep out of my business?
I'm attempting to connect to a Bluetooth 4.0 device. I've done something similar in the past with a 2.0 device and Windows does not interfere in this case.
Have a look at http://SimpleBluetooth4Win.SourceForge.net
It's a small wrapper library that uses the windows bluetooth networking API that could help you.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa362932%28v=vs.85%29.aspx
In particular if your bluetooth USB dongle or bluetooth device has been correctly recognized by the appropriate drivers and the remote bluetooth device is already paired with the PC, you don't need to install a bluetooth virtual COM port that shows up in Device Manager but you simply use the write or read calls to access directly the stream for communicating with the paired device.