I'm curious how the windows device manager obtains the hardware IDs for a device, even though no device driver may be loaded for the device yet. Anybody have a clue on how Windows goes on about this?
On a related note, I am interested in supporting language localization for the software we are writing; is it possible for a device and/or driver to report back its friendly name and description in a localized fashion? Is there a common practice for this already?
Thanks for your time.
First, to understand the order of drivers being loaded, you're recommended to switch the Device Manager into View | Devices by Connection mode.
As you would notice, the devices are located below their bus driver. For PCI devices, it'll be "PCI bus". For USB devices, it would be their USB hub. Each bus driver has its own idea about how the identifier strings should be formatted:
Device Instance Id
Hardware Ids
Compatible Ids
Location, etc.
It returns them in response to IRP_MN_QUERY_ID (BusQueryInstanceID, BusQueryHardwareIDs, BusQueryCompatibleIDs) and IRP_MN_QUERY_DEVICE_TEXT (DeviceTextDescription, DeviceTextLocationInformation etc.)
Of course, since the bus driver enumerated the devices (i.e. created the child devices you're seeing) in the first place (through whatever standard interface appropriate for the bus; e.g. 'Get Device/String Descriptor' on USB), it knows their vendor ID, product ID etc.
The device's driver does not have to be loaded at this time. In fact, it can't be loaded. The device IDs are precisely what instructs the PnP system as to which driver matches the device.
As to localization:
Unlike IRP_MN_QUERY_ID, which provides opaque strings intended for device matching, the IRP_MN_QUERY_DEVICE_TEXT information was indeed intended to be localized. For that purpose, you receive the requested Locale ID (LCID) in the input data (Parameters.QueryDeviceText.LocaleId).
[As Alphaneo noted, a USB hub driver might pass this LCID onwards to the USB device (within a Get String Descriptor request), hoping that the USB device itself has localized strings.]
The top level process is called enumeration. Most modern device buses support a mechanism that lets the OS query the buss and determine what devices are connected to the bus.
The PCI family of buses all support enumeration. The PCI bus has a special enumeration space just for this. This is where "Plug-n-Play" ID's come from.
The device id's uniquely identify a device on the bus and enable the OS to find the correct driver for that device.
Other buses, including USB and FireWire have enumeration strategies
Device ID, is a combination of information given from the device. For example, for a USB device, the string is based on the VID and PID (Vendor ID and Product ID). Now, this cannot happen if no driver is loaded. Atleast some driver, bus driver would have to be loaded for the OS to get the Device ID.
Now, for language support, I guess for WDM driver, there is a QUERY_LANG or something, I dont remember properly, alternatively some devices like USB, have Language ID support. This language ID determines the language of the Product descriptor string.
Please note that there is a difference between the hardware identifier/serial number and the true unique hardware ID. Maybe this will explain it better:
http://www.soft.tahionic.com/download-hdd_id/hardware%20ID%20programmer%27s%20DLL.html
Related
I'm writing some code (C++) for ESP32, to act as a BLE beacon. The problem is this: the iPhone doesn't send out its real MAC address, but does a random-generated MAC address, for security. The thing I'm confused about is how do you know if it's a device you've previously paired with?
So let's say I detect a new BLE MAC address, and looking at the manufacturer data I can determine it's an Apple device (first 2 bytes are "4C").
Now I need to know if I've previously paired with that device, so that I can allow the ESP32 to initiate an action (for simplicity let's just say turn on an LED). If that MAC address is in a list of known devices, then I can continue, and if not, I ignore it.
The problem is, if the iPhone is not giving up the real MAC address, the detected MAC address will never match anything. As this is a security situation I'm sure the algorithm for generating those MAC addresses is not known.
To be clear: this code is being written for the ESP32, not the iPhone.
It is in fact not possible to tell if a device has been previously seen, unless you pair and establish a bond with it. Once you pair with the device, long-term keys are exchanged and are used to quickly re-establish the connection.
This is by design. MAC addresses were originally unique, but this allowed tracking people and devices without their consent. You can read more about this in the following ESP-IDF guides:
GATT security server walkthrough
GATT security client walkthrough
So are you using esp32 as a beacon? This dose not involve any pairing or iOS MAC addresses. iOS will just be able to listen and the esp32 will not even know someone is "listening" to its broadcast.
Probably iOS application can store which services it is interested to hear to; may looks like pairing.. but it is a high level application managed technique and not any related to what BT standard calls pairing.
I'm trying to troubleshoot a wireless modem that contains a Sierra MC73xx module. Also, my SIM is from an MVNO that says it has enabled roaming on Verizon.
I run AT+COPS=? and can see the Verizon network:
+COPS: (0,"T-Mobile","T-Mobile","310260",2),(0,"Verizon","Verizon","311480",7),(0,"T-Mobile","T-Mobile","310260",0),(0,"AT&T","AT&T","310410",7),(0,"AT&T","AT&T","310410",2),(0,"T-Mobile","T-Mobile","310260",7),,(0,1,2,3,4),(0,1,2)
However when I run AT+COPS=1,2,311480 I can't seem to register on the network.
Are there other AT commands required to register a roaming SIM on the Verizon network? BTW through testing I've been able to register on T-Mobile and AT&T.
In the PLMN scan result, there is only one Verizon network,
(0,"Verizon","Verizon","311480",7). "7" indicates the radio access technology(RAT) and I remember 7 is LTE.
On the other hand, both AT&T and T-Mobile has 2G/3G coverage, i.e. RAT 0 and 2. In your successful registration, you probably see the RAT is 0 or 2. You can use at!gstatus to check RAT.
I suspect your SIM card cannot roaming in Verizon LTE network. Usually international roaming agreement does not cover LTE.
The other thing you can check is if this carrier is in your SIM's forbidden list. This can happen if your device tries to connect to a network and is denied.
For clearing this list, see here for instructions.
Verizon (nowadays, as of this response) is very particular about which modems may register to its towers. Verizon certifies cellular modules before they're allowed to register and maintains a list of authorized IMEIs.
If your module's IMEI isn't on that list, it's not going to work.
Even using a Verizon SIM card on a Verizon-certified device, I couldn't connect one time. I had to call Verizon and give them the expected IMEI for that SIM's ICCID so the tower knew what to expect ahead of time. Then it worked.
I suppose that trying to connect through an agreement with an MVNO they wouldn't have you call Verizon and explicitly tell them the IMEI, but it would still need to be in an expected range of IMEIs that Verizon expects.
Verizon does this to assure that customers will have a consistent experience on their network as their LTE system uses frequencies (bands) that other carriers do not; they "certify" modules submitted to them by the manufacturers - give them a stamp of approval - the module has demonstrated the ability to operate according to Verizon's specifications.
I know that an OS provides an api for a device driver to access the configuration space so that the device driver knows the memory addresses assigned to the device and can control the device. However, my question is how does an OS communicate with device drivers? For example, let's say the OS wants a document to be printed. How does it tell that it wants a document to be printed to the printers device driver and provide the driver with the text to print? Device drivers are developed by different developers, so wouldn't the drivers expect different types or formats of data from an OS. For example, printer A's driver may expect the command byte before the text data but printer B's driver may expect the text data before the command byte.
My current project use bluetooth printer and i use EAAccessory framework for connect with the external device(printer). the problem is when i discover the bluetooth device, i get the all the devices paired with the iOS device. i need filter printers from the paired devices.
I really do not think this is possible. If you want exact information on the actual type of the bluetooth device connected, such as whether it is a printer or a wireless headset, the EAAccessory framework will not be able to deduce this for you nor is it really EAAccessory's job. All the EAAccessory framework will give you is very basic metadata information on the currently connected devices, generally speaking you can use some combination of the meta data, such as [name, protocol string] OR [manufacturer, name] to identify what you have connected to.
If you need any richer metadata like what you are asking, you need to directly ask the device yourself, which means the device should have some API's available for you to communicate with it. From my personal experience though, the information returned and boxed into an EAAccessory framework is more than enough for me to understand the device I am connecting to, specific type information will than be deduced off of that in code. If you want dynamic reader type info, that is tough and you will need to query the device for that info yourself once establishing a logical session.
I am looking for a unique id accessible for a bluetooth low energy device from iOS.
I have 10 devices and i placed it in 10 different places. I exactly need to know to which device i am communicating irrespective of the iOS device i am using to connect.
In the iOS core bluetooth, a new UUID is assigned by iOS for my device. I am not able to uniquely identify the device.
I have used the MAC address of the peripheral to generate a unique name in SCAN RESP. I guess you could also use this approach and maybe also put it in the advertisement data or in a message. (My peripheral was based on TI's 2540 SoC.)
To my knowledge MAC/BDADDR is not accessible via CoreBluetooth, but I noticed that the "Device Information Service" profile (0x180A) contains a "System ID" attribute (0x2A23) which encodes the device's unique MAC/BDADDR address. I don't know if it is mandatory for a BLE device to expose this service, however.
Use Major and Minor properties in CLBeacon. Both are 4 char hex values.
They are located in advertisement data with UUID.
More info:
https://developer.apple.com/library/ios/documentation/CoreLocation/Reference/CLBeacon_class/Reference/Reference.html#//apple_ref/occ/instp/CLBeacon/major