Hey there! Let's walk through your questions clearly since you're new to BlueZ and building a custom GATT server via D-Bus in C. I've worked with BlueZ 5.x quite a bit, so here's what you need to know:

1. How to detect if a central device sent a scan request via D-Bus? #

First, a quick reality check: BlueZ 5.49 doesn't expose a direct D-Bus signal or method to notify you when a scan request is received. Scan requests are low-level HCI events that BlueZ handles internally, and the D-Bus API doesn't surface this specific event by default.

That said, you have a couple of practical workarounds:

• Monitor connection attempts: If a central device scans and then connects, you'll get a Connected signal from the org.bluez.Device1 interface for that central device. This tells you the device found your advertisement and initiated a connection.
• Use HCI raw sockets: If you absolutely need to detect raw scan requests, you can open an HCI raw socket in your C code and listen for HCI_SCAN_REQUEST events. This bypasses D-Bus but gives you direct access to low-level BLE events.
• Debug with btmon: While not part of your application, running btmon in the background will show you all HCI events (including scan requests) which is super helpful for testing and validation.

2. Which D-Bus method to use to read BLE events? #

Most BLE-related events in BlueZ are delivered via D-Bus signals, not by calling a method to "read" them. You'll need to subscribe to these signals in your C code to react to events like:

• Device connection/disconnection: Listen to the PropertiesChanged signal on org.bluez.Device1 (watching for the Connected property change)
• GATT characteristic reads/writes: Implement the ReadValue and WriteValue methods in your custom org.bluez.GattCharacteristic1 interface, and BlueZ will call these when a central device interacts with your characteristics.
• Advertisement state changes: Subscribe to PropertiesChanged on org.bluez.Adapter1 to check if your advertisement is active.

If you need to fetch current state information (like whether the adapter is advertising), you can call the GetAll() method on org.bluez.Adapter1 or org.bluez.LEAdvertisingManager1 to retrieve properties.

3. Next steps for your development #

Here's a structured path to get your GATT server up and running without command-line intervention:

Step 1: Set up your D-Bus GATT service skeleton #

• Use GDBus (recommended for C, part of GLib) or dbus-glib to create the D-Bus objects for your GATT service and two characteristics. You'll need to implement the required interfaces:
  • org.bluez.GattService1 (with UUID, Primary properties)
  • org.bluez.GattCharacteristic1 (with UUID, Flags, Value properties, plus ReadValue/WriteValue methods)
• Register these objects with BlueZ's org.bluez.GattManager1 interface using the RegisterService method.

Step 2: Configure and start advertising programmatically #

• Create an advertisement object implementing org.bluez.LEAdvertisement1 with your desired parameters:
  • Set Type to "peripheral"
  • Add your GATT service UUID to ServiceUUIDs
  • Set LocalName if you want a discoverable name
• Register this advertisement with org.bluez.LEAdvertisingManager1 via the RegisterAdvertisement method. This will start broadcasting automatically—no bluetoothctl commands needed.

Step 3: Implement characteristic logic #

• For your two characteristics, write the ReadValue method to return data when a central device reads it.
• Implement WriteValue to handle incoming data from the central device (e.g., store it, trigger an action).
• Make sure to set the correct Flags for each characteristic (e.g., "read", "write", "notify" if you need to send updates).

Step 4: Subscribe to key signals #

• Set up signal handlers for:
  • org.bluez.Device1.PropertiesChanged (to detect when a central connects/disconnects)
  • Any custom signals you might want to emit from your characteristics (like notifications if you support them)

Step 5: Test and debug #

• Use tools like bluetoothctl (run scan on to find your device) or mobile apps like nRF Connect to scan, connect, and interact with your GATT server.
• Use dbus-monitor to watch D-Bus traffic and verify your service/characteristics are registered correctly.
• Use btmon to check for low-level BLE events (like scan requests) during testing.

Step 6: Handle errors #

• Add error checking to all D-Bus method calls (e.g., registration failures, invalid parameters)
• Handle cases where the adapter is powered off or unavailable

内容的提问来源于stack exchange，提问作者Ganesh Kumar