I am trying to create some scripts to discover and pair bluetooth devices on a embedded arch linux platform and seem unable to get any replies to dbus-send commands.
The error message is pretty much always the same (method does not exist), however the syntax of the send appears to be correct.
I have googled and searched here for the correct syntax and the errors, but have been unable to find any solutions.
[root#alarmpi ~]# dbus-send --system --dest=org.bluez --print-reply / org.bluez.Manager.GetProperties
Error org.freedesktop.DBus.Error.UnknownMethod: Method "GetProperties" with signature "" on interface "org.bluez.Manager" doesn't exist
[root#alarmpi ~]# dbus-send --system --print-reply --dest=org.bluez /org/bluez/134/hci0 org.bluez.Adapter.GetProperties
Error org.freedesktop.DBus.Error.UnknownObject: Method "GetProperties" with signature "" on interface "org.bluez.Adapter" doesn't exist
Bluez is installed, and I can use the hcitool and bluetoothctl utilities to manually discover and pair devices, however that method is not workable for an end-user and I need to create a web interface for them to perform the discovery and pairing.
It seems that dbus is the preferred method for doing this, as bluetoothctl does not accept command line arguments to allow it to pair a device address.
Any help / suggestions would be much appreciated.
Verify that bluetoothd is running,
Install a program called d-feet which is a D-Bus debugger and see if the org.bluez is present on the system bus tab,
If it is navigate to the destination Object, Interface and Method which is "/", "org.bluez.Manager" and "GetProperties" respectively,
Double click the method name (GetProperties) and click execute without any arguments
The output should be something like {u'Adapters': ['/org/bluez/709/hci0']}, if it's not - you have a problem with your bluetoothd,
Btw. your command is correct.
Related
I'm creating a tool on an embedded system and I wanted to inhibit the screensaver using the DBus mechanism.
This works perfectly when I test my app. on my computer. I can check with the following command:
dbus-send --print-reply --dest=org.gnome.SessionManager \
/org/gnome/SessionManager org.gnome.SessionManager.GetInhibitors
and I can see my app. in the array.
However, when I run the exact same application as a daemon, it connects to the DBus session properly, but when I try to send the message to inhibit the screensaver, I don't get a reply at all. DBus generates an error like so:
The name org.freedesktop.ScreenSaver was not provided by any .service files
Ultimately, the daemons will run as its own user (like Apache2 runs as www under Ubuntu).
Is that just not possible? Can only the currently logged in user tweak the ScreenSaver in this way? Or could I somehow authorize the daemon user who then could access the ScreenSaver parameter?
I am running a BLE beacon in bluez5.52 on a linux machine(ubuntu 14.04) using the default gatt-service and the beacon using the btmgmt provided in the tools folder. Following are the commands I run to setup the beacon:
Terminal 1:
./gatt-service
Terminal 2
sudo ./btmgmt
add-adv -u 180d -u 180f -d 080954657374204C45 1
I am easily able to connect and disconnect with the beacon using BLE scanner app in android.
What I would like to do is setup a password for the beacon so that I am the only one who can connect to it. So far I have been unable to find any resources online that could help set that up. I have a decent understanding of the btmgmt and gatt-service code. I am looking for direction on what part of bluez code to look for to set up the password protection. Any leads, pseudo-code or partial code would help a lot.
Emil already mentioned pairing and bonding in the comments. This would definetly serve your purpose as you would be able to control who could connect to your peripheral.
A BLE characteristic can ask a connected device to authenticate before reading or writing which would result in a 'insufficient authentication error' if the device is not paired to your peripheral. A Android app is able to handle this error by displaying a pairing popup depending on the used pairing method.
So it is possible to have characteristics without security right next to one's that require pairing.
In case you still want to implement something like your mentioned password safety you should look into a 'authorized read'.
A characteristic which requires authorization first receives a read request and you can allow or deny it based on your own requirements. That means you can authorize yourself by sending a password to one characteristic and afterwards allow a read request on another characteristic. This would be even easier if you only accept one connection at a time.
I'm trying to get a GATT client working on a Linux system that's running BlueZ 5.19. Unfortunately, neither Python or glib are available on this system, so my only choice is using libdbus. And did I mention that I've never used D-Bus before? I have a GATT server on another system that provides and advertises a custom service by its 16-byte UUID. I'm trying to get my BlueZ-based system to access this service. I've verified that I can discover the server by the UUID that it advertises, and I can get BlueZ to connect to it. My client app has successfully called Bluez's RegisterProfile method, passing the UUID advertised by the server, but BlueZ never calls my NewConnection method. In the options of the RegisterProfile call, I'm setting "Role" to "client", "AutoConnect" to TRUE, and both "RequireAuthorization" and "RequireAuthentication" to FALSE. I am running bluetoothd with the -E (experimental) option.
If I run bluetoothd in the foreground with both the -E and debug option, this is what I see when I start my client app:
bluetoothd[2126]: src/profile.c:register_profile() sender :1.20
bluetoothd[2126]: src/profile.c:create_ext() Created "myRemoteControlProfile"
bluetoothd[2126]: src/profile.c:ext_device_probe() myRemoteControlProfile probed with UUID 119649b6-b656-22ae-e611-ba85a04effc5
bluetoothd[2126]: src/service.c:change_state() 0x950d0: device 24:71:89:09:AD:09 profile myRemoteControlProfile state changed: unavailable -> disconnected (0)
"myRemoteControlProfile" is the name of the profile I registered with Bluez, "119649b6-b656-22ae-e611-ba85a04effc5" is the UUID that I passed in the RegisterProfile call and 24:71:89:09:AD:09 is the GATT server I'm trying to interact with, so BlueZ seems to know that this remote device provides the service I'm looking for. When I watch on the server device, I never see BlueZ connecting to it. Isn't BlueZ supposed to connect to a device when it sees that the device offers the service that I passed in RegisterProfile? Why don't I get a NewConnection method call? What does it mean that my registered profile never gets past the "disconnected" state? I know that the GATT API was still considered experimental in BlueZ 5.19; should I even expect this to work? Thanks!
BTW, this problem is nearly identical to the one described in https://stackoverflow.com/questions/36480516/bluez5-37-org-bluez-profilemanager1-registerprofile-cant-detect-green-throttle . Unfortunately, no answers were offered there.
I've been able to work around this problem by upgrading to BlueZ 5.43. I still don't get a NewConnection method call, but if I detect the remote device by the UUID of the service it advertises and connect to it manually, all of the characteristics of the service now appear when I do GetManagedObjects on org.bluez, which didn't happen in BlueZ 5.19.
I need to develop an application with a bluetooth dongle that makes use of the thermometer profile. The thing is that, after succesfully pair and connect with the remote device, whenever I try to run the test-therometer file, I obtain the following error:
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method "RegisterWatcher" with signature "s" on interface "org.bluez.ThermometerManager1" doesn't exist
I have also tested the test-heartrate, and I obtain something similar:
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method "RegisterWatcher" with signature "s" on interface "org.bluez.HeartRateManager1" doesn't exist
I have successfully tested the dongle with bluetoothctl, so I can discard hardware compatibility issues. I'd like to know if I'm missing something while running the tests.
I'm working under ArchLinux x86_64.
I have connected Huawei USB UMTS modem (E220) to my Linux box, i.e. RaspberryPi.
Now I get 2 ttyUSB port available to communicate to it, where I use ttyUSB0 to establish mobile Internet connection and ttyUSB1 for other tasks, like sending and receiving SMSes, checking status and error codes, make modem configurations, etc.
At regular intervals (2secs) I get this AT command on port ttyUSB1:
^DSFLOWRPT:n,n,n,n,n,n,n
which I fully understand (link: thanks to the user user ginggs from http://mybroadband.co.za). Less frequently I also get ^BOOT command, looking like this:
^BOOT:12659389,0,0,0,58
Can someone explain what those numbers in ^BOOT mean? Can I make notifications/warnings in ^DSFLOWRPT and ^BOOT be less/more verbose (something like "errors on/off")?
[edit]
Added link for understanding the ^DSFLOWRPT command.
In AT Command Interface Specification, Huawei mention that ^BOOT unsolicited command only for the Huawei specified client, nothing specific.
You can disable all unsolicited result by the following AT command:
AT^CURC=0
To enable it back just change 0 to 1:
AT^CURC=1