i want to learn about bluetooth programming in C.
After some research i found this linked on the Bluez official website. https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/
since iam not familiar with this linux type of documentation i cant really get much out of it but i made some assumptions.
my first try was to look at the first function in doc/adapter-api.txt and there is no mention where the functions are located.
so i searched for it in every /lib file and could not find anything.
so where can i find all the definitions documented in /doc?
BlueZ is the Bluetooth stack for Linux and it has a few API's for people to use. Below is a list of the possible API’s starting from lowest level and going to the highest. For most people, the higher the better.
Raw HCI
This bypasses the BlueZ bluetoothd that is running on a Linux system that is used to coordinate interactions with the Bluetooth hardware. This API is outside of the BlueZ infrastructure so is not documented by the BlueZ project. All the information is available in the Bluetooth Core Specification which runs to about 3,256 pages for the 5.2 version of the spec.
If using this level it is a good idea to stop the Bluetooth service from starting the Bluetooth daemon so they are not conflicting. There is no safety net with HCI so you really, really need to know what you are doing.
MGMT Socket
The BlueZ Bluetooth Mamagement API is the next step up and the lowest level that the BlueZ developers recommend. This looks quite "HCI" in its API but it commnicates with the bluetoothd which issues HCI commands to the hardware.
This is documented at:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/mgmt-api.txt
D-Bus API
This should be the go to level for most people wanting to interact with the BlueZ API’s. The commands interact with the bluetoothd which issues HCI commands to the hardware.
The good point of a D-Bus API is that it is language agnostic. However, it seems the number of people that are familiar with D-Bus is a relatively small and so it is another level of indirection to learn before using the API.
Most popular programming languages appear to have bindings to D-Bus. Some of the bindings are listed at:
https://www.freedesktop.org/wiki/Software/DBusBindings/
The BlueZ D-Bus API is split across multiple documents depending what piece of functionality is required. For interacting with the Bluetooth Adapter it is documented at:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/adapter-api.txt
And the device API is at:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/device-api.txt
etc...
Before diving in to coding it might be useful to experiment with interacting with the BlueZ bluetoothd through the D-Bus API. This can be done with various command line tools. I'm going to assume that you will be using the gdbus library for your C code so that seems like a good choice to experiment with on the command line.
The BlueZ D-Bus API for the Linux Bluetooth adapter is probably the easiest to get started with.
The documentation for this API is at:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/adapter-api.txt
At the top of the document it says what the D-Bus Service and Interface is. And that the object path can be variable.
Service org.bluez
Interface org.bluez.Adapter1
The bluetoothd is communicating on the D-Bus System bus.
D-Bus has a GetManagedObjects method that we can use to report all the things BlueZ knows about. To list all this information about BlueZ use:
$ gdbus call --system --dest org.bluez --object-path / --method org.freedesktop.DBus.ObjectManager.GetManagedObjects
This is usually a lot of information so let's use grep to find the object path for the adapter:
$ gdbus call --system --dest org.bluez --object-path / --method org.freedesktop.DBus.ObjectManager.GetManagedObjects | grep -Pio "/org/bluez/hci.*Adapter1"
/org/bluez/hci0': {'org.freedesktop.DBus.Introspectable': {}, 'org.bluez.Adapter1
So we can now see that (for me) the D-Bus object path is /org/bluez/hci0. I can introspect this now:
$ gdbus introspect --system --dest org.bluez --object-path /org/bluez/hci0
Now I have the Service, Interface and Object Path I can call methods as documented by BlueZ. For example to find what available filters that can be given to SetDiscoveryFilter:
$ gdbus call --system --dest org.bluez --object-path /org/bluez/hci0 --method org.bluez.Adapter1.GetDiscoveryFilters
(['UUIDs', 'RSSI', 'Pathloss', 'Transport', 'DuplicateData'],)
To get all the properties on the Adapter then we can use the GetAll method (that we can see from the introspection) is on the org.freedesktop.DBus.Properties interface. A call example:
$ gdbus call --system --dest org.bluez --object-path /org/bluez/hci0 --method org.freedesktop.DBus.Properties.GetAll "org.bluez.Adapter1"
To get the value of one property we use Get:
$ gdbus call --system --dest org.bluez --object-path /org/bluez/hci0 --method org.freedesktop.DBus.Properties.Get "org.bluez.Adapter1" "Powered"
To set the value of a property we use Set:
$ gdbus call --system --dest org.bluez --object-path /org/bluez/hci0 --method org.freedesktop.DBus.Properties.Set "org.bluez.Adapter1" "Powered" "<boolean true>"
The following looks like a useful introduction to doing some of this in C:
https://www.linumiz.com/bluetooth-list-devices-using-gdbus/
There is a talk "Doing Bluetooth Low Energy on Linux" by Szymon Janc that may also be useful background. It is available on YouTube:
https://youtu.be/VMDyebKT5c4
And a PDF of the slides:
https://elinux.org/images/3/32/Doing_Bluetooth_Low_Energy_on_Linux.pdf
Related
I'm currently making a Bluetooth app with BlueZ
I need to get a Pairing request.
Using BlueZ DBus API, i've made my Agent into NoInputOutput mode, and i succeed the first pairing with my phone.
However, if i delete the linux device(which uses my bluetooth app that i am developing) from my phone and try to re-connect, i can't pair it together.
I searched Python code examples that...
From BlueZ's DBus API, calling RequestAuthorization method to pair and successes it, then deleting the device and re-pairing works fine.
But in case of smartphone's pairing request, i think i should call RequestAuthorization method WHEN SOME EVENT(S) is received. And i have no idea for that.
Conclusion: How can i get a pairing request event using dbus and glib loop?
I've already checked
bluez pairing before exchange
apparently, gdbus is a combination of dbus and glib.
However, i'm using dbus and glib separated since i can sorted some codes that i do not need.
More, now i think it doesn't have any relations with deleting devices from the list.
We are currently using the dbus API to connect with specific devices. We are using the classic method which is the subscription on the PropertiesChanged, but because of the tremendous number of bluetooth advertiser devices around, we decided to try to use the whitelist just like hcitool provides :
hcitool lewladd <MAC>
hcitool lescan --whitelist
We want to connect BR/EDR and LE devices but only LE devices that are in the whitelist.
I wrote a small C spike program that adds a device calling the following methods :
hci_le_add_white_list(...) // To add devices to the WL
hci_le_set_scan_parameters(...) // With "whitelist only" policy
However, as soon as I call the StartDiscovery() dbus method :
busctl call org.bluez /org/bluez/hci0 org.bluez.Adapter1 StartDiscovery
I see in the HCI events, that the "LESetScanParameters" is called again with an "Accept All" Policy (even if I already set it before to "Ignore not in whitelist". We are using bluez 5.50.
So my question is,
Is it possible to set the LE Scan parameters and then call the StartDiscovery() dbus call without resetting the former ?
NB: I know that it's possible to directly interact with the hci lib provided in bluez but it would require a complete refacto of the soft we are developping.
Thank you
EDIT : I forgot to mention that I want to use the whitelist because I want to filter by MAC addr and not by UUID.
hcitool is a legacy tool/command. With BlueZ D-Bus the Adapter API contains a SetDiscoveryFilter() method, which allows you to install a corresponding filter.
I'm developing a C application on C.H.I.P. board (Debian Jessie on it) ; while I was able to scan for classic and BLE devices using the source code of hcitool scan and hcitool lescan that we can find in /tools/hcitool.c of bluez package, I can't pair with devices without interact with the prompt given by hcitool auth XX:XX:XX:XX:XX:XX or rfcomm bind "MY DEVICE" XX:XX:XX:XX:XX:XX. I need to bypass the prompt given by these function without having interaction with it. I tried to find which function call the prompt and it seems to be the IOCTL, but i can't understand how to avoid this step. Can anyone could help me?
I am trying to develop a bluetooth LE peripheral in intel-edison, by using C library. The device should be able to :
advertise (GAP)
accept connection (GAP)
support custom GATT service, simply read/write value of characteristic.
I try to use HCI and bluez to implement this. bluez-experiments, intel-edison-playground, which demonstrate how to advertise and scan, can be compiled and run on edison. BLE advertising and scanning do work.
But I have hard time to figure out how to accept connection and support GATT service. I try to search on goolge about the HCI document but have no luck. Can someone provide a snippet of code (c or pseudo or a description)?
Thank you so much!
Andrew
If you download the bluez source you'll find documentation on the hci protocol in /doc/mgmt-api.txt. I'm not using the hci interface myself, and I'm not sure if the developers intend for implementors to use this interface to implement peripherals, so I'm not sure how well this will work.
I went with the DBus API approach for my project, which is outlined in /doc/gatt-api.txt and /doc/advertising-api.txt. This approach involves writing a program which creates DBus objects which support specific org.bluez DBus interfaces (GattService1 which contains GattCharacteristic1 and GattDescriptor1) and the ObjectManager interface to expose everything to bluez. You then use LEAdvertisment1 to define what is advertised and register the advertisement using the LEAdvertisingManger1 interface on the adapter.
I used Qt to simplify the DBus communication parts.
The DBus API for BLE on bluez is still in heavy development, and not all features are supported (I still haven't found a way to start and stop advertising, for example). 5.31 contains a lot of added supported and some critical bug fixes for descriptors, but requires a newer kernel.
how can i check weather the given device is connected. using org.bluez.AudioSource GetProperty
I am using c and DBus,can anybody help me to get out of this...
I assume you've been looking into the BlueZ D-BUS API which is a precious documentation for everything related to listening on BlueZ's signals and query information. You can find it in any BlueZ source in the doc/ folder.
To check if a device is connected, you first need to get all the Bluetooth devices on your computer and their paths using D-BUS, I will not provide any C documentation as you can easily find plenty of examples about this using Google. I will instead show you what D-BUS calls you can make via dbus-send to get such an information.
Get Devices list:
dbus-send --system \
--dest=org.bluez \
--print-reply / \
org.bluez.Manager.GetProperties
This returns an array of adapters with their paths.
Once you have these path(s) you can retrieve the list of all the Bluetooth devices paired with your adapter(s).
Get paired devices:
dbus-send --system \
--print-reply \
--dest=org.bluez \
/org/bluez/{pid}/hci0 \
org.bluez.Adapter.GetProperties
This gives you the list of paired devices within the Devices array field.
Once you have the list of devices paired to your Bluetooth Adapter, you can know if it is connected to the AudioSource interface.
Get the devices connected to the AudioSource interface :
dbus-send --system \
--print-reply \
--dest=org.bluez \
/org/bluez/{pid}/hci0/dev_XX_XX_XX_XX_XX_XX \
org.bluez.AudioSource.GetProperties
I find it more to convenient to first try d-bus calls using dbus-send because the D-BUS C API is a bit confusing and inconvenient to use.