6

I am extending plugin/gatt_example.c in Bluez sources to try the BLE Notification function without success. I am using the included sample Battery Service in Bluez source. It has 1 characteristic with READ and NOTIFY properties. I add dbus method to call attrib_db_update() to update the characteristic value from outside the bluetooth daemon.

Now, I can connect which client (Nexus4 with Android 4.3 and iPhone (LightBlue free apps)) and start notification (setting descriptor CCC notify flags). (note: ccc descriptor char has default auth permission, so from iPhone modifying CCC (start notify) will make bluez to return error: not authorize permission. Since I'm planning to deal with authorization later, I temporary change the default permission to none, and iPhone is able to set CCC notification flags).

The problem is even the client (both Android or iOS) has start notify, calling attrib_db_update() is not making bluez to send any notification to client (monitor with hcidump, no packet send to client).

Question: Is there any step required beside attrib_db_update() to make bluez sending notification to client? I appreciate any link to sample source. PS. I use bluez as peripheral + gatt server configuration (just as battery service in plugin/gatt_example.c) not vice-versa.

Thanks.

=== Update (I don't know how comment formatting work... so I add update here.)
About profile/alert sample:
Yes I already check on profile/alert prior asking the question. Another problem is that I could not run those sample (That one reason I ask the question at the first place).
profile/alert/server.c: attio_connected_cb() is a callback function, registered by filter_devices_notify() in server.c. It use btd_device_add_attio_callback() (from src/device.c). Further checking src/device.c, it look like that it check device->attrib if it exist to exec (insert to queue first then exec callback) the callback or just insert in queue until device connected?.
Debugging it, it look like device->attrib is empty even if I already connected the device.

For those interested to run/debug sample alert profile (Since there's no doc :( ).
Comment out the following if (around line 564), we don't interested in those check... 


    /*
        if (!g_str_equal(alert->srv, sender)) {
            DBG("Sender %s is not registered in category %s", sender,
                                    category);
            return btd_error_invalid_args(msg);
        }
    */

Run bluetoothd: ex. bluetoothd -n -d -p alert
Connect your device until startNotify

Register alert from other console: 


    dbus-send --system --dest=org.bluez --type=method_call "/org/bluez" "org.bluez.Alert1.RegisterAlert" string:"simple" objpath:"/org/bluez/AlertAgent1"

Create new alert: 


    dbus-send --system --dest=org.bluez --type=method_call "/org/bluez" "org.bluez.Alert1.NewAlert" string:"simple" uint16:"1" string:"test"

I got the following bluetoothd's log:


    bluetoothd[1928]: src/attrib-server.c:attrib_db_update() handle=0x001c
    bluetoothd[1928]: src/attrib-server.c:attrib_db_update() handle=0x0021
    bluetoothd[1928]: profiles/alert/server.c:register_alert() RegisterAlert("simple", "/org/bluez/AlertAgent1")
    bluetoothd[1928]: src/attrib-server.c:attrib_db_update() handle=0x001e
    bluetoothd[1928]: src/device.c:btd_device_add_attio_callback() 0x1b6e718 registered ATT connection callback
    bluetoothd[1928]: src/device.c:device_set_auto_connect() 10:68:3F:E1:4E:F2 auto connect: 1
    bluetoothd[1928]: src/adapter.c:adapter_connect_list_add() /org/bluez/hci0/dev_10_68_3F_E1_4E_F2 added to BlueZ 5.14's connect_list
    bluetoothd[1928]: src/adapter.c:trigger_passive_scanning()
    bluetoothd[1928]: src/device.c:btd_device_add_attio_callback() device->attrib = false
    bluetoothd[1928]: src/device.c:btd_device_add_attio_callback() cfunc = true
    bluetoothd[1928]: src/device.c:btd_device_add_attio_callback() no idle
    bluetoothd[1928]: profiles/alert/server.c:new_alert() NewAlert("simple", 1, "simple")
    bluetoothd[1928]: src/adapter.c:passive_scanning_complete() status 0x03
    bluetoothd[1928]: Wrong size of start scanning return parameters

Memo: adding some debug output in device.c. It seem that device->attrib is empty. And autoconnect (why gatt server/peripheral has to connect to central?) is failed for unknown reason.

user1012131
  • 139
  • 1
  • 2
  • 6

1 Answers1

3

Edit: I have succeeded running alert sample using the test-alert python script in the code.

I contacted the developer directly and asked. Turned out that there was a bug when running bluez as peripheral, so he created several patches on the mailing list.

http://marc.info/?l=linux-bluetooth&m=139092431515560&w=2

After applying patch, run the server and try using test-alert :

  1. Connect and write to the right ccc handle for notification on client side
  2. On server side, run test-alert such as (-w is to keep the test-alert persistent, -r for registering email alert, -u for unread email, 30 is the number of unread email):

    test-alert -w -r email -u email 30

Isa A
  • 1,342
  • 13
  • 31
  • Thanks for the info Isa. Look like the patch is not in the latest release (5.14) yet. I'll fetch the latest source from git, to find out. But like Anderson said, it might not fully working. (I'm feeling to understand why Android switch the bluetooth stack from 4.3 and on...). I also looking to another solution, like bleno. Last time I check it not have notification yet, but as I just check it already implemented it. – user1012131 Feb 20 '14 at 04:40
  • Bad news. Unfortunatelly it not working (using test-alert). I use iOS7 BlueLight to connect, the log is as the same as my update (device->attrib is nil, Wrong size...) Also test with Nexus 4 (need 4.4.2 for BLE, there are many bug fix you can't connect to bluez with 4.3 or 4.4) This time the log is differ. But still I got no notification send to nexus nor hcidump sending the notify packet. Will try bleno. – user1012131 Feb 20 '14 at 07:54