I have added 2 type of devices in Watson-Iot platform, one is Iot-Bridge and one is gateway.
When I make the API call to get device info for gateway type of device, it gives me the information but same type of call for Iot-Bridge type device says NotFound.
e.g. https://internetofthings.ibmcloud.com/api/v0002/organizations/{orgId}/device/types/gateway01/devices/{deviceId}
gives device Info but below call gives NOT FOUND, however there is a device by that name as /bulk/devices gives list of all devices.
https://internetofthings.ibmcloud.com/api/v0002/organizations/{orgId}/device/types/iot-bridge/devices/{deviceId}
Can anyone provide any idea?
Also how can I get all the information for data sent by these devices to Iot Platform? API endpoint is given but its giving Bad Request.
I am glad to hear you identified the device info endpoint was checking for cases sensitivity and resolved the problem by correcting the case of the device type name.
An application can subscribe to monitor the status of one or more devices, for example:
Subscribe to topic iot-2/type/device_type/id/device_id/mon
Note: To subscribe to updates from more than one device, use the MQTT "any" wildcard character (+) for any of the following components:
device_type
device_id
For managed devices, you can use the API to get log connection information to determine when managed devices have connected and disconnected.
You may find this recipe for displaying status of devices useful: https://developer.ibm.com/recipes/tutorials/display-status-of-registered-devices-on-watson-iot-platform/
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 need to find the applied policy status on device.
How to find if registered device on my group done factory reset, using Android Management API.
You can find it via the Key : "DeviceState" in the GET API response of a device which indicates the states that may be applied to a device. GET Device
If the STATE is DELETED then it means the device is no longer enrolled. This state will never be returned by an API call, but is used in the final status report published to Cloud Pub/Sub when the device acknowledges the deletion. DeviceStates
I have two iOS devices; one is sending beacons using peripheralManager, beaconPeripheralData, etc. The second, a receiver device, is currently scanning for regions and beacons of the same UUID using didEnterRegion, didRangeBeacons, etc.
Is there any method or callback for the -broadcaster- side to know if the scanning side has entered its region or received its beacon? Something similar to "didEnterRegion", but for the broadcaster.
Thanks.
Simple answer - no.
Not so simple answer - clients don't connect to the "broadcaster", they just listen for advertisements, so there is no way for "broadcasters" to identify who has "heard" them.
Vladimir's answer is correct. However, you can set up your "broadcaster" (advertiser, in BLE terms) to also listen for other BLE devices that are advertising services, or sending out iBeacon broadcasts.
Then you would set up the remote receiving iOS app to execute special code when it gets a didEnterRegion call. That code could start advertising a pre-defined BLE service that your "broadcaster" is already listening for, and the two devices could then enter into a 2-way BLE conversation.
More simply, your receiver could simply start sending it's own beacon signal when it gets a didEnterRegion message as a result of detecting the "broadcaster"'s beacon signal.
You can do this is you just use CoreBluetooth CBCentral and CBPeripheral rather than trying to be an iBeacon (which encourages non-connectability).
While there is no standard way for a broadcaster or peripheral to automatically know who's found it you can do this by having an service and characteristic on your iOS peripheral. You could have your central scan for a particular UUID and when it finds it, have it connect and write an attribute, and then disconnect. This would give your peripheral information about who saw it.
This avoids the issue where you try to toggle between one device being a broadcaster and a central, since you can't be both of them at the same time.
I am using code similar to this one:
Link
How do I get media status (connected or disconnected)?
How do I know if adapter is wireless type?
Prashant
There is the Native WiFi API. (For XP requires SP2/3, min server 2k8)
You can list enabled adapters with WlanEnumInterfaces.
You can fetch state with WlanQueryInterface with wlan_intf_opcode_interface_state to request the state in a WLAN_CONNECTION_ATTRIBUTES struct.
An alternative are the MSNDIS WMI Classes.