The recent BlueZ 5.46 release has a new feature to "let an application get a dedicated file descriptor to read/write data from/to a GATT characteristic". Looking at bluetoothctl command help, It looks like this should work using the new acquire-write or acquire-notify commands, but so far I am not able to get these to work. An example trying to connect Fedora 26 with bluez.x86_64 version 5.46-1.fc26 with the --experimental flag on the bluetoothd service to an HM-10 Bluetooth Low Energy module:

bluetoothctl -v
sudo bluetoothctl
[bluetooth]# scan on
Discovery started
[CHG] Controller 28:B2:BD:07:04:49 Discovering: yes
[NEW] Device D4:36:39:DE:61:6B KeyDuino
[bluetooth]# scan off
[bluetooth]# connect D4:36:39:DE:61:6B
Attempting to connect to D4:36:39:DE:61:6B
[CHG] Device D4:36:39:DE:61:6B Connected: yes
[KeyDuino]# select-attribute 0000ffe1-0000-1000-8000-00805f9b34fb
[KeyDuino:/service0010/char0011]# acquire-write
Failed to acquire write: org.freedesktop.DBus.Error.UnknownMethod
[KeyDuino:/service0010/char0011]# acquire-notify
Failed to acquire notify: org.freedesktop.DBus.Error.UnknownMethod

I keep getting the Failed to acquire write: org.freedesktop.DBus.Error.UnknownMethod error message when I try to use the new commands. How can I get a file descriptor for a BLE characteristic?

The connection is otherwise working using the notify and write commands:

[KeyDuino:/service0010/char0011]# notify on
[CHG] Attribute /org/bluez/hci0/dev_D4_36_39_DE_61_6B/service0010/char0011 Notifying: yes
Notify started
[CHG] Attribute /org/bluez/hci0/dev_D4_36_39_DE_61_6B/service0010/char0011 Value: 0x33
[CHG] Attribute /org/bluez/hci0/dev_D4_36_39_DE_61_6B/service0010/char0011 Value: 0x32
[CHG] Attribute /org/bluez/hci0/dev_D4_36_39_DE_61_6B/service0010/char0011 Value: 0x31
[KeyDuino:/service0010/char0011]# write 0x30 0x31 0x32
Attempting to write /org/bluez/hci0/dev_D4_36_39_DE_61_6B/service0010/char0011

1 Answer 1


Hmm... so while I though I was running bluetoothd with the --experimental flag I must have not saved the changes. To start the daemon with experimental features:

  1. Edit the .service file to include --experimental or -E on the startup command
  2. systemctl daemon-reload
  3. systemctl restart bluetooth

Next make sure the daemon is running with the correct flags:

systemctl status bluetooth

Then when I tried to use acquire-write or acquire-notify I got a new error message and the daemon seemed to crash:

[KeyDuino:/service0010/char0011]# acquire-write
Agent unregistered
[DEL] Controller 28:B2:BD:07:04:49 GBFedora01 [default]
[DEL] Primary Service0/char0011]# 
    Generic Attribute Profile
[DEL] Characteristic
    Service Changed
[DEL] Descriptor
    Client Characteristic Configuration
[DEL] Primary Service
[DEL] Characteristic
[DEL] Descriptor
    Client Characteristic Configuration
[DEL] Descriptor
    Characteristic User Description
Failed to acquire write: org.freedesktop.DBus.Error.NoReply
Waiting to connect to bluetoothd...

I also got a popup indicating there were two SELinux issues detected:

SELinux issue write-acquire

The troubleshooting step provided commands to enable the requested permissions:

ausearch -c 'dbus-daemon' --raw | audit2allow -M my-dbusdaemon
semodule -X 300 -i my-dbusdaemon.pp

after restarting the bluetooth service, I can successfully acquire file read/write descriptors:

[KeyDuino:/service0010/char0011]# acquire-write
[CHG] Attribute /org/bluez/hci0/dev_D4_36_39_DE_61_6B/service0010/char0011 WriteAcquired: yes
AcquireWrite success: fd 7 MTU 23
[KeyDuino:/service0010/char0011]# acquire-notify
[CHG] Attribute /org/bluez/hci0/dev_D4_36_39_DE_61_6B/service0010/char0011 NotifyAcquired: yes
AcquireNotify success: fd 8 MTU 23

You can then find these file descriptors in the /proc/(pid)/fd/ folder for bluetoothctl.

#Use cat to read output
sudo cat /proc/$(pgrep bluetoothctl)/fd/8
#In another root shell use cat to write to BLE characteristic
sudo -sE
cat > /proc/$(pgrep bluetoothctl)/fd/7
  • I'm using version 5.55 on Debian, which no longer has the selinux issue, but the file descriptors point to unix sockets for some reason, so sudo cat no longer works. Jun 17, 2023 at 8:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .