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.
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.
Actually I'm using D-Feet (D-Feet can be used to inspect D-Bus interfaces of running programs and invoke methods on those interfaces) to connect to a BLE peripheral that advertises proximity profile.
When I try the Connect() method on the remote object /org/bluez/hci0/dev_88_6B_0F_00_C4_3A every thing is fine and the connection succeed but when I try to connect only the proximity profile using ConnectProfile("0x1802") method an error occurs saying that the host is down:
g-io-error-quark: GDBus.Error:org.bluez.Error.Failed: Host is down
(36)
Can anyone help me solving this problem (I'm blocked for 2 weeks and there still to much to deal with in the project :/)
ConnectProfile("0x1802")
ConnectProfile (and the Bluez API in general) does not deal with handles, only UUIDs. Your input argument does not look like a UUID: I suggest you find the remote service UUID that matches the handle (I'm assuming your current input argument is a handle).
I believe you can find the UUID with d-feet (after Connect() the service objects should be there) or with bluez command line tools.
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.
I am trying to use the low level c-api of DBUS to implement a server-client over sockets. My question is .. is it necessary that a bus should be used always for dbus communication. And does a BUS just means an extra instance of dbus-daemon.
Yes, you need a bus for DBus communication. The bus is a communication channel, nothing more. More buses do not mean more instances of the Dbus daemon, it only means more communication channels.
In a system, you usually have one DBus daemon with one or more buses. Each bus is used for some class of messages (defined in your application).
2 applications can communicate via DBus, bypassing the daemon, by specifying the name of the client to which you want to send the signal/method (the DBus standard allows it). However, I don't think there is a DBus binding that offers this feature. But if you want to use the raw C API of the DBus, you can implement it yourself. You can check this discussion for more information on the topic.
Not sure about C API, but you can have client and server connecting directly using my node.js dbus implementation. Here is an example