In the Advertising section of a BLE, The Bluetooth SIG Define the "Flags"
which has these plus a few more.
BR/EDR Not Supported
Simultaneous LE and BR/EDR to Same Device Capable (Controller)
Simultaneous LE and BR/EDR to Same Device Capable (Host)
I am having an issue on a CSR chipset design that does not support GATT over BR/EDR.
Apple works great, as it always connects to LE.
..but android devices persistently try to connect GATT over BR/EDR if the audio is already up; therefore fail because CSR cant handle BR/EDR transport for GATT.
I am thinking these flags are at the core of the problem.
In CSR's demo code they do not set "any" of the above flags. I have had limited success with my problem on some handsets by setting the "Not Supported" flag.
The issue is the other two flags. How does Controller/ Host relate to other LE terms. For example Central/Peripheral or later Master/Slave.
I dont know what flags to set for my use case. Any suggestions welcome?
You can use a Static Random address for all LE operations. That way the Android device thinks it's a different device than when talking over Bluetooth Classic since that uses the public BD_ADDR.
Or, one variant of the connectGatt takes a transport parameter which you can set to TRANSPORT_LE to force communication over BLE.
If your device supports BLE and BR/EDR at the same time you should set these flags:
BR/EDR Not Supported=0
Simultaneous LE and BR/EDR to Same Device Capable (Controller)=1
Simultaneous LE and BR/EDR to Same Device Capable (Host)=1
If the flag data is missing completely, it's the same as if all fields are zero.
Related
Many BLE devices have BR/EDR Controller Mode - LE + BR/EDR Host Mode in their Flags. Does this mean that this Device is also a classic Bluetooth device?
BR/EDR is the technical term for what you call bluetooth classic.
With "in their Flags" you probably mean in the advertisement? This would mean that the device at least reports, that it also implements bluetooth classic, yes.
I am programming a device which uses BR/EDR and BLE. BR/EDR is mostly used for audio data while BLE should work as control channel. Access to the used BLE characteristic returns a gatt_status_insufficient_authentication if and only if the central (smart phone) is not bonded. At least, that is what I want.
Moreover, if BLE bonding is triggered, I also get a BR/EDR bonding by Cross Transport Key Derivation (CTKD). Ok.
IF I do BR/EDR pairing from the phones pairing menu, this CTKD does not work. How could this work?
Or is there a way to enforce BLE pairing instead BR/EDR pairing?
Regards
My question is very basic.I need to know where does all Bluetooth profile such HID, HFP or HSP loaded in Bluetooth stack? Is it in Host layer or in Bluetooth Hardware Chipset such as USB dongle/module or in both Host and Chipset Side?
According to my understanding, we can implement Bluetooth profiles on Host side using packages like BlueZ but at same time Bluetooth chipset which is connected to Host should need some sort of firmware and logic(like CSVD, A-law ) inside its chipset.
A quote found in BlueZ Android package doc: "Wideband Speech support in HFP it is required that BT chip assumes mSBC codec". This means Host layer can implement that Profile only if BT chipset provides the low-level support like mSBC.
My Answer is like this: " We can build any Bluetooth Profile say 'X' on Host layer if BT chipset is equipped with underlining Low-level firmware which support the Profile 'X'".Please agree or disagree with my understanding.
PFA diagram of my understanding
Position of profile and its low-level firmware
I need to select a USB Bluetooth dongle compatible to Raspberry Pi and customize the HID and HFP using BlueZ.
Advance Thanks to all Bright minds!
There are multiple ways how Bluetooth functionality is implemented in a system based on how much is implemented in the controller and host.
Everything in the controller - App, Upper stack, may or may not HCI(lower and upper stacks communicate through HCI commands and events), Lower stack. Example: Most of Bluetooth Mouse, Keyboard etc, where a single controller is responsible for everything (Bluetooth, RTOS/scheduler, Controlling LED's in the device, etc)
App in Host and lower and upper part of stack in controller. May or may not implement HCI in controller.
Example: Where we use a dedicated Bluetooth chip and integrate it with the Device. Here device will transmit application data to the Dedicated Bluetooth chip. All the Bluetooth protocol related things will be done from BT controller/chip. If you are using an HC-05 module with Arduino module, Arduino will transfer the serial data to the HC-05 module.
App and upper stack in host and lower stack in the controller. Bluez, Bluedroid and all other stacks in Operating systems are of this type. This will communicate with the controller with HCI commands and events.
Example: Mobile phones, Computers, TV with Bluetooth etc (Devices having a powerful Application processor)
So lets assume you are asking about the 3rd type. In this case your assumption is correct. Here all profiles are implemented in the host only. But protocols/codec needed to support them will be implemented in the controller(either firmware or hardware block). For example GAP(For BR-EDR) is implemented in the host but encryption and decryption algorithms are implemented in the controller as Firmware or hardware blocks. For A2DP profiles audio codec/decoders will be implemented in the controller. BT chip then transfers this audio data to host with I2S or other protocols. For BLE Security manager profile, encryption/decryption algorithm is implemented in the host itself, But whitelist, auto connection etc, will be implemented in the controller.
My Answer is like this: " We can build any Bluetooth Profile say 'X' on Host layer if BT chipset is equipped with underlining Low-level firmware which supports the Profile 'X'".Please agree or disagree with my understanding.
For BlueZ use case this is correct. You need to use the controller with the required hardware capabilities(Firmware + hardware resources).
For the scenarios 1 and 2 the profiles and supporting protocols will be implemented in the controller.
The scenario:
I have one device (Android Phone) that I can control and I want to analyse the Bluetooth capabilities of a different device of which I have limited control/ information - I can only accept/ reject pairing, but I don't known what versions or features are supported (this is that I want to find out).
Question:
From the recorded HCI logs (in the Android Phone), can you determine what version/ technology was actually used in a successful pairing?
In other words, how can you tell whether Bluetooth low energy was used or the Classic Bluetooth (BR/EDR)?
Note: I am not looking for:
the LMP advertisement of the "remote host" as this will only tell
which Bluetooth version is supported (e.g. 4.1) but will not tell
which technology is actually used
also, not looking for the remote extended features telling what
technologies are supported (such as BR/EDR and LE) but without giving
details about which technology is actually used
Thanks :)
If the LE link is set up, HCI LE Meta Event 0x3E with sub event LE Connection Complete 0x01 will be seen in the logs. See core spec v5 Vol 2, part E.
If pairing occurs over the LE link, then SMP PDUs related to pairing will be seen in the HCI logs as pairing occurs on the host. See core spec Vol 3, Part H.
In LE, GATT is used to discover services of the remote device.
If the BR/EDR link is up, HCI Connection Complete event 0x03 will be seen in the logs. In BR/EDR, SDP is used to discover services of the remote device.
Is there any (big) technial difference between pairing 'normal' Bluetooth devices and pairing Bluetooth LE devices?
I found a lot of information for Bluetooth LE pairing, but not for normal? For example
Info 1.
So is this information for normal Bluetooth correct too?
If you mean Bluetooth Classic or BR/EDR by 'normal',the difference depends on the version of Bluetooth in use.
Bluetooth Classic or BR/EDR 2.1 - 4.1 Vs BLE 4.0-4.1
BR/EDR pairing procedures are handled by the LMP layer of the Bluetooth Controller.
BLE Pairing procedures are handled by SMP in the host stack.
BR/EDR uses ECDH Key generation which prevents passive eavesdropping.
BLE legacy pairing does not use ECDH Key generation and so it is susceptible to passive eavesdropping
BR/EDR defines 4 association models; OOB, Passkey entry, Just works, Numeric Comparison
BLE Legacy Pairing defines 3 association models ; OOB, Passkey entry, Just works.
Although they appear similar from the user perspective, they do not provide the same level of security. See #2
BR/EDR generates the Link Key on both devices.
BLE legacy pairing, generates the STK. The Link Key i.e. LTK in use is distributed by the slave
BR/EDR v4.2 Secure Connection vs BLE v4.2 Secure Connection
BLE 4.2 secure connections added ECDH key generation and the Numeric Comparison association model. It also did away with the STK. The LTK is now generated on both slave and master.
Secure connection association models on the BLE link, are equivalent to BR/EDR secure connection association models, in terms of protection against MITM attacks and Passive eavesdropping.
When two BR/EDR/LE devices support Secure Connections over both transports, keys for both transports may be generated during a single pairing procedure. The ability to convert keys from one transport to the other eliminates the need to pair twice.
There are still some differences.
BR/EDR pairing procedures are handled by the LMP layer of the Bluetooth Controller.
BLE Pairing procedures are handled by SMP in the host stack.
BR/EDR cryptographic functions use HMAC-SHA-256.
BLE cyrptographic functions use AES-CMAC.
More information can be found in the Bluetooth core specification here