I've worked with WPD API for a while now, and I seem to run in to problem after problem.
Once I fix one problem, something else pops up. But hey, that's life.
I've been trying to determine if a WPD device is a storage device or a phone or whatever.
Turns out, devices such as iPhone are not set to be recognized as a phone, but instead as a generic device in terms of WPD_DEVICE_TYPE.
But, it is presented to Windows as a storage device.
When connecting external harddrives, SD memory card readers and other more conventional storage devices, they are recognized by the WPD API as well, but ehy that also get a dedicated mount point in Windows.
If I connect an external harddrive, it will have one functional category object, and the value of that object will be the path of that drive, say E:.
Nice. Great!
So my question is: How can I somehow read if the WPD device has a mountpoint?
Sure the functional object indicates that it has one, but is it possible that there could be an indicational value which states that a mount point is available?
Check the device Ids, here's an example how they differ:
\\?\swd#wpdbusenum#_??_usbstor#disk&ven_usb&prod_flash_disk&rev_1100#aa04012700007404&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}#{6ac27878-a6fa-4155-ba85-f98f491d4f33
vs.
USBSTOR\DISK&VEN_USB&PROD_FLASH_DISK&REV_1100\AA04012700007404&0
The upper one is the Id gathered from PortableDeviceManagerClass (first step to create an PortableDevice object), the lower one I've just read from the Device Manager, but it should be easily retrievable with one of these solutions:
How do I get a Unique Identifier for a Device within Windows 10 Universal?
https://sourceforge.net/projects/sharpdevelop/files/SharpUSBLib/
Related
In a Windows 8 Store App I would like to read Data from a SmartCard. After installing the SmartCard reader (USB Device) I can read its device path and connection state via the Windows.Devices.Enumeration namespace. Even the device interface id is retrievable (50dd5230-ba8a-11d1-bf5d-0000f805f530) and I put this as a required capability in the App's manifest file.
For the interaction with the device I use a C++ Component calling the CreateDeviceAccessInstance Method. But this call always results in an ACCESS_DENIED exception.
Further research taught me, that interacting with a custom hardware device (everything that is not a printer, microphone, mouse, ...) would need several adjustments in the device driver published to the windows 8 driver store.
I'd be glad to do so, but I am no IHV and would like to use the generic driver and the generic interface.
Could anyone give me a hint how to proceed from here and use the generic interface for USB SmartCard devices?
This is not a real answer, but I have the same problem and I have spent quite some time looking for the hard-to-find bits of information on this subject around the internet, and I'd like to share my results.
Windows 8.1 has some specific APIs for (virtual) SmartCards (API reference, sample), but it seems like they can only be used for authentication and there is no way to send APDU commands to a card at the moment (see this comment by Himanshu Soni). I guess one could use the new USB APIs to talk to the reader directly, but then you'd have to implement the whole protocol yourself.
We want to use a unique device identifier in a Windows 8 Metro app and the recommendation is an ASHWID, documented here:
http://msdn.microsoft.com/en-us/library/windows/apps/jj553431.aspx
I'm struggling to see how this can possibly be guaranteed unique. The format includes two bytes per hardware component, of which the most uniquely identifiable are MAC address and hard disk serial number. But just two bytes for those values really doesn't seem like enough.
If the bytes used are anything other than the least significant digits (the rightmost, as a human reads them) are taken, then two identical laptops adjacent on the production line would probably have the same ASHWIDs. The MACs and drive serials would likely be adjacent.
So, I guess the crux of my question really is how many devices have to be produced with the same CPU type and memory configuration before you're likely hit a duplicate. Seems like the same sort of problem as the Birthday Paradox, so I found a calculator for that and plugged in the numbers :)
With one MAC address and one hard disk with a two-byte identifier each, you have about 4 billion permutations. Once you've allocated just 6,000 of them, it's roughly 50/50 that you've got two the same.
(go to http://jeff.aaron.ca/cgi-bin/birthday and plug in "6563" and "4294967296" for the actual calculation).
So this really doesn't seem very unique at all. Am I right in being ultra-sceptical of this identifier, or am I missing something really significant?
No, the ASHWID is not guaranteed to uniquely identify a device. At work, I've seen dozens of daily collisions where one monthly is our tolerance.
Further, the ASHWID might frequently change for the same device -- since Windows 8 will often run on laptops that might add a docking station, USB thumb-drive, or a plug-in Bluetooth adapter. The best use of the ASHWID is for verifying that a user has only installed your app to a limited number of devices, and you do that by parsing the ASHWID and selectively comparing it to previously-seen ASHWIDs from that user.
As for a unique hardware identifier, I suggest an MD5 digest of a string containing multiple components, of which some components of the ASHWID can play a part.
You might randomly generate a large number (64+ bits) and store that (eg in the registry). And of course the user's login name/ID should be unique to that user, if you want something else to include in a hash. You also need to consider what you want to do if the user clones an OS install, or replaces the HD after a drive failure.
Back in the Windows Desktop world, I used the MachineGuid registry key and the serial number of the boot device, but I'm fighting to get access to that info in a Windows Store app. If you have access, MachineGuid is in HKLM\SOFTWARE\Microsoft\Cryptography, which MS guarantees to be unique. The serial number of the boot device ::GetVolumeInformationW(::SHGetFolderPathW(~),~) will be fairly unique but only 32 bits.
From the article:
The ASHWID provides a strong binding between the app/package and the
device by representing several individual hardware characteristics. In
order to protect user privacy, the ASHWID varies from app to app.
Unless the underlying hardware has changed, two calls from the same
app will result in identical ASHWIDs. However, the ASHWID changes if
the hardware profile of the device changes, such as when the user
unplugs a USB Bluetooth adapter. The back-end cloud service can verify
the ASHWID and compare it with previously reported values. Though the
ASHWID varies, it can be parsed to detect if the variance was simply
due to a minor change such as an addition of memory to the system. The
level of tolerance for variance is up to the implementation of the
back-end cloud service.
The ASHWID is made up of 9 components:
CPU ID of the processor
Size of the memory
Serial number of the disk device
Network adapter (NIC MAC address - first instance)
Audio adapter
Docking station
Bluetooth address
Mobile broadband device ID
BIOS
CPU ID is only unique to processor model, but NIC MAC Address should be very unique. Having said that, MAC addresses can be cloned and USB NICs can be moved from device to device. So, while I guess it's possible for two devices to have the same ASHWID, it's very unlikely. What's most challenging in using this ID is the fact that hardware can change. It's up to the service to decide which parts of the ASHWID they allow to change and which parts the do not (acceptable variance). The article itself provides guidance on that.
I am trying to access an USB HID device under Ubuntu(kernel-3.0). I want to write a program which could notify me whenever an USB device is attached to the bus i.e is there any event generated whenever an USB device is plugged in which I can monitor. I have looked into DBus and HAL without any success. But I don't want linux to load its current modules(USBHID and HID) when the device is plugged in. I also want to ask if the mentioned modules are also the device drivers used for HID devices.
My sole purpose is to run a script whenever an USB device is plugged into the bus which will indirectly call the above mentioned modules.
I am writing my code in C. I am quite new to linux. So it would be of great help if anyone could point me in the right direction.
Thanks..
The UDisks deamon will send the D-Bus signal "DeviceAdded" when a USB drive is inserted, and probably another "DeviceAdded" for each partition on the drive. If you have automount you would also get a "DeviceChanged" signal when the partition(s) are mounted. You can then query the UDisks interface, as well as individual devices about their properties, for example. You can find more info on the UDisks interface here: http://hal.freedesktop.org/docs/udisks/UDisks.html
One way to get more familiar with what goes on with block devices (or whatever) on D-Bus, is to install and use D-Feet to inspect the bus. UDisks appear on the System bus. You can see what is there and inspect the properties for individual devices as well as the UDisks interface itself.
Another way, which would also allow you to see what signals are transmitted on the bus, is to run dbus-monitor from the command line.
Over the past two days, I am doing some reading on how to get data over USB from an external device which has no device driver installed. I have to read data from a WT500 Yokogawa Power Meter (basically I want to read just one of the parameter that the meter shows, just the power values) over USB. I am aware that a device driver for WT500 is available, but it has some dependencies and I do not want to install a software or change anything majorly in our node to cater to that.
I have found that libusb could be used to perform what I would want, and I have a C program that sniffs the USB device and returns some information. I have looked into usb-robot as well, which also uses libusb. The server node that I am probing has OpenSUSE Linux kernel 2.6.30. I have usbfs mounted.
Question:
I am expecting that using libusb, I would be able to get data dumps from the power meter whenever I request, via usb device. Can I request the meter something like - send 25k of data, and then upon parsing it, I get the parameter value that I am looking for? Considering that I have zero knowledge about the device, can I get some meaningful values out of it? An example code would help.
--
There are some standard messages like ?IDN with which a USBTMC device could be queried. However, specific queries need to be sent to a meter (the syntax should be there in the technical doc/manual/communication interface) if one needs to get whatever is showing up on screen.
I guess there are no easier ways of doing what I want - like just reading a file using something like fread ??
--
Yes, almost. If USBTMC module is installed (the default one in our kernel did not work, detailed explanation of installing and querying a device is here - http://code.google.com/p/scte/wiki/USBTMC), then one just needs to send some queries and read the response via cat or something from the specific files under /dev.
From the meter technical document, I see that the driver communication interface that is described is Windows specific, so I reckon I might need to do some reverse engineering.
--
Yes, but only a tiny bit or may be not at all.
Thank you.
EDIT: After a bit of googling I think I have the answers, I have added them next to the questions I asked.
We have developed an application on Windows.net mobile framework and it is used on a Windows 6.5 Smartphone. for our location based application. Our application is real time and tracks our employees. We are finding that the device loses its GPS signal.
Has anyone managed to restart the GPS receiver so that it starts giving the GPS signal again. I would be ever so gratefull if someone can help. We are using GeoFramework2.0 to deliver the geographic information that you need.
Regards
Sandy
The GPS is "shut down" when no application is using it. Just close your handles and re-open them.
If the GPS on your device is part of the WWAN radio (i.e. cellular phone) it may get put in to a low power state rather than being actually shut off. In that case, you can try restarting the radio.
If that doesn't work, some GPS's will allow you to send proprietary commands to them to force a reset or clear the memory. These commands are not standard and will differ significantly by manufacturer. If you have a SiRF GPS, take a look at the SiRF Binary Protocol Reference.