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 have probably a very simple question.
When I initialize the port in Windows 10 the control message sent to USB device is incomplete. Windows sends the speed, but all other parameters are zeros (ie parity, nbits etc). I have checked the raw data received by the endpoint, I have also sniffed the communication on the cable - and Windows does not send this data.
Is this the standard virtual serial windows driver issue?
I have problem with communication via USB CDC with Windows. On Linux or Mac everything work good.
So, when I try to connect to my COM port I get notification from PUTTY "Unable to open communication to COM2. Unable to configure port.
It is my own device based on Rx63n uC, I transmit in FullSpeed standard, packet in size less than 64 bytes. I'm used 2 endpoints for bulk transfer IN/OUT.
In USBLyzer I got information thatSTALL packet is received from my device after error (USBD_STATUS_CANCELED).
I used driver from Windows 10 usbser.sys.
Any ideas what is wrong?
I forgot to add that in USBLyzer I see a lot of my packets, and after transferred some data it generate error as above.
I am trying to use IOBluetooth framework on OS X 10.8.2 to connect with the bluetooth enabled phones emulating computer as a hands free device. I can successfully make a connection with the phone and phone can recognise the connection as a HandsFree connected to the phone.
But when I try to make a call with the phone and want to send the audio to the mac (by selecting the source as handsfree), the audio never reaches the computer.
As at this point the bluetooth framework tries to open a SCO Audio connection with the device, but the connection establishment is never successful and I get the error code 0x0D status code in scoConnectionOpened status.
I am using IOBluetoothAddSCOAudioDevice function to attach the SCO Audio device with bluetooth device and it is always successful.
//btDevice is paired
res=IOBluetoothAddSCOAudioDevice((IOBluetoothDeviceRef) btDevice,NULL);
if(res != kIOReturnSuccess)
{
self.error.title = [NSString stringWithFormat:
#"Could not attach the Audio device. Try paring device again"];
}
The console log says
24/11/2012 4:02:13.000 PM kernel[0]: [SendHCIRequestFormatted] ###
ERROR: [0x0428] (Setup Synchronous Connection) -- Send request failed
(err = 0x000D (kBluetoothHCIErrorHostRejectedLimitedResources))
24/11/2012 4:02:13.000 PM kernel[0]: REQUIRE_NO_ERR failure: 0xd -
file:
/SourceCache/IOBluetoothFamily_kexts/IOBluetoothFamily-4090.4.33/Core/Family/Drivers/IOBluetoothSCOAudioDriver/IOBluetoothSCOAudioDevice.cpp:872
Although console log says limited resources but I have tried it with multiple phones having their batteries full.
I am stumped on this and just thinking if I need to do any thing special or different?
Thanks in advance for much appreciated help.
This error ("Connection Rejected due to Limited resource") typically happens when a T2 request is sent to a T1-only SCO listener. If you read the patch notes to version 5 you can get a discussion about this problem linux-bluetooth v5 patch notes
I am developing a custom USB HID device with both IN and OUT interrupt endpoints of 64 bytes length each. There are 2 reports (one with report ID 1 and other with report ID 2) with report count of 63 bytes each. When the PC app developed in VC++ sends a 64 byte buffer using WriteFile(), I receive the entire buffer properly at the device on the OUT interrupt endpoint. But when I send a 64 byte buffer from the device to the PC on the IN endpoint, the ReadFile() returns with a value of 4 (timeout). This happens only 2 times when the device is plugged in. After that everything works fine and the PC reads the 64 bytes sent by the device properly.
I am using USBlyzer tool to sniff the USB bus traffic. That software shows that for the first two times the device sends a 64 byte buffer on the interrupt IN endpoint, but it too is not able to show the data in it. And the 3rd time onwards, everything works magically, both PC application and USBlyzer receive and display the 64 bytes buffer contents on the screen.
I am not sure where exactly the problem lies, is it on the PC side code or in the device firmware? Please share your thoughts.