I would like to know whether the following are possible in the current windows phone 7 SDK:
Getting the device's OS version
programmatically.
Detecting programmatically
whether the data connection is
available in the device or not
Programmatically getting the type of network
connection that the device is
currently having either wifi or LAN
You can get the OS version by doing using System.Environment.OSVersion. The numbers at the end will be the current running version. You can confirm this on your phone by going to Settings...About and seeing if the numbers match.
You can use the NetworkInterface.GetIsNetworkAvailable method to determine if there is any data connection available.
To determine the type of connection, you can use NetworkInterface.GetInternetInterfaceType. This will return a valume of enum NetworkInterfaceType. If the value is Ethernet, the user is plugged into the computer and using its data connection. (Of course, you should test the values returned to confirm that they're what you expected them to be).
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 using Windows Bluetooth LE GATT library to connect to and pair with a BLE-supporting device, D. Since D has a limited amount of storage space, if more than N Clients bond with it, then it will remove the first Long Term Key pair that was created during bonding.
Let's say that the device for which this key-pair was removed was a Windows Enabled machine. Let's call this W. The next time W attempts to connect with D, when it receives the LTK_Request_Event from W, it responds with Long_Term_Key_Requested_Negative_Reply, and W terminates the connection.
But here's where things get really exasperating. Even though the Windows BLE Stack seems to be aware of this response (because it disconnects), this does not seem to be communicated downstream to applications using the Bluetooth LE GATT library. In fact, from the application's side, a pairing request will return with "Already Paired", and does not indicate that anything went wrong. Of course, once the application tries to access protected characteristics, it won't be able to, and that, so far, is the only indication that Pairing was not successful. Even worse, the errors it receives aren't consistent. Sometimes, it gets "Unreachable". Sometimes, it gets protocol errors. Other times, it receives ABORTs.
Now, as a heuristic, I could use detection of this case as criteria for attempting to re-pair. Unfortunately, this is not ideal, since none of these errors actually imply that the device no longer honored the LTKs, and could, instead, indicate other issues, like that the device is out of range.
Is there any way to detect that existing LTKs have been rejected by the device?
Let's see what the Bluetooth specification says about this.
Bluetooth Core version 5.2, Vol 3 (Host), Part C (Generic Access Profile)
Section 10.3.2 Initiating a service request:
In this section the local device is the device initiating a service request to a
remote device. In the L2CAP protocol the local device sends the connection
request and the remote device sends the connection response. In GATT, the
local device is the GATT client and the remote device is the GATT server.
When a local device initiates a service request to a remote device it shall
behave according to the following rules:
[...]
If an LTK is available and encryption is required (LE security mode 1) then
encryption shall be enabled before the service request proceeds as defined proceed. If encryption fails either the bond no longer exists on the remote
device, or the wrong device has been connected. The local device must,
after user interaction to confirm the remote device, re-bond, perform service
discovery and re-configure the remote device. [...]
If Windows's BLE stack doesn't allow for what the specification mandates, it is not specification compliant, in my eyes, so please file an issue report at Microsoft.
The reason for requiring user interaction and not blindly re-bond is to avoid a situation where a hacker can simply spoof the bluetooth device address, indicate it has lost the bond and automatically re-bond without the user noticing anything.
EDIT:
The Security Manager chapter also has a table of actions to do when encryption fails due to deleted keys. See section 2.4.4.2 of Vol 3, Part H.
It specifically says when the devices were bonded before that the action to take when enabling encryption fails is to "Notify user of security failure."
I would like to connect to a wireless miracast display which is already paired with the host. I am able to use EnumDisplayDevices to list the wireless display device. I have tried to use ChangeDisplaySettingsEx but it didn't work, I used CDS_SET_PRIMARY on the miracast display device hoping that it would automatically connect to it and set it as the primary display.
It looks like ChangeDisplaySettingsEx cannot establish a connection on it's own. There should be some kind of API which can connect to the display. I have also tried SetDisplayConfig with SDC_TOPOLOGY_CLONE to change the display configuration to "clone" thinking that it would automatically connect to the display.
Question: What is the proper way to connect to a wireless display device using Windows API?
Since I have dozens of virtual serial (COM) ports installed and the half of them are Bluetooth devices, I'd like to know what port belong to what device and whether it's connecting directly or via Bluetooth.
So in particular I'm not interested in the trivial enumeration of all serial ports, which would only reveal a list of 'COM' + the corresponding number, but the real name of that device and probably its device ID (where information can be found about whether this is connecting via USB or Bluetooth.
While I could get these information via WMI, there are a plenty of problems related to this method. In particular it's bloody slow, but also it does only list connected devices (except for Bluetooth devices, that can potentially be connected and are shown regardless of a real connection)
I'd prefer a solution written in Delphi / Object Pascal, but any other language is also fine for me (the WMI access code was copied from C#).
If you use a programming language/API that can read the registry, check the subtree HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum.
This has subkeys containing device type, device class, instance ID. Each Instance ID has a subkey Device Parameters\PortName that has the COM name.
For example, on my system
ACPI\PNP0501\1\Device Parameters\PortName = COM1
BTHENUM\{GUID}{ID}\Device Parameters\PortName = COM4
The keys in the ID Part have additional information, for example
ACPI\PNP0501\1\FriendlyName = Kommunikationsanschluss (COM1) (german windows)
ACPI\PNP0501\1\Service = Serial
BTHENUM\{GUID}{ID}\Service = BTHMODEM
Use regedit to check for yourself which parts are interesting to you. But this should give you all information you need.
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