Agent1 Interface does not work as desired

[olir]

An Agent1 object can be successfully been registered with BlueZ's AgentManager1, but during pairing it is expected that the Agent1 call-back method is invoked. That does not happen. Instead the desktop's agent popup is displayed. Something wents wrong. I need to find out why AgentManager1's registerAgent() and requestDefaultAgent() do fail, but cause no exception.

TestClient attached: TestClient.java.txt

[olir]

Bluetoothctl output:

[CHG] Controller B8:27:EB:84:FF:E4 Discovering: yes [NEW] Device A0:E6:F8:AE:F1:83 CC2650 SensorTag ... [CHG] Device A0:E6:F8:AE:F1:83 Connected: yes ... [CHG] Device A0:E6:F8:AE:F1:83 ServicesResolved: yes [CHG] Device A0:E6:F8:AE:F1:83 Paired: yes [CHG] Device A0:E6:F8:AE:F1:83 Name: SensorTag 2.0 [CHG] Device A0:E6:F8:AE:F1:83 Alias: SensorTag 2.0 [CHG] Device A0:E6:F8:AE:F1:83 Modalias: bluetooth:v000Dp0000d0110 ---> Now the Desktop Popup appears ---> After application timeouts and exists: [CHG] Controller B8:27:EB:84:FF:E4 Discovering: no ---> After I reject the popup: [CHG] Device A0:E6:F8:AE:F1:83 ServicesResolved: no [CHG] Device A0:E6:F8:AE:F1:83 Connected: no ... [DEL] Device A0:E6:F8:AE:F1:83 SensorTag 2.0

[olir]

The things are going to happen in Agent1.c (generated from skeletion_c.txt). In handle_method_call it never prints '++ handle_method_call '. Ignore the rest of the method, it is not finished yet.

The call g_bus_own_name (...) takes a name that must be different to the Agent1 object path. This object is registered with g_dbus_connection_register_object (...)

Gnome suggests to use somting different for the "server side": https://developer.gnome.org/gio/stable/gdbus-codegen.html But this doesn't seem to work in this case, i was not successful with this.

[olir]

enabling debug mode on bluez reveals an error logged:

Sep 30 16:52:57 raspberrypi kernel: [ 907.784014] Bluetooth: SMP security requested but not available Sep 30 16:52:57 raspberrypi bluetoothd[720]: src/agent.c:agent_ref() 0x1196310: ref=2 Sep 30 16:52:57 raspberrypi bluetoothd[720]: src/device.c:bonding_request_new() Requesting bonding for A0:E6:F8:AE:F1:83 Sep 30 16:52:57 raspberrypi bluetoothd[720]: src/agent.c:agent_ref() 0x1196310: ref=3 Sep 30 16:52:57 raspberrypi bluetoothd[720]: src/agent.c:agent_unref() 0x1196310: ref=2 Sep 30 16:52:57 raspberrypi bluetoothd[720]: src/adapter.c:suspend_discovery() Sep 30 16:52:57 raspberrypi bluetoothd[720]: src/adapter.c:adapter_bonding_attempt() hci0 bdaddr A0:E6:F8:AE:F1:83 type 1 io_cap 0x04 Sep 30 16:52:57 raspberrypi bluetoothd[720]: src/adapter.c:pair_device_complete() Success (0x00) Sep 30 16:52:57 raspberrypi bluetoothd[720]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr A0:E6:F8:AE:F1:83 type 1 status 0x0 Sep 30 16:52:57 raspberrypi bluetoothd[720]: src/device.c:device_bonding_complete() bonding 0x11472d0 status 0x00 Sep 30 16:52:57 raspberrypi bluetoothd[720]: src/device.c:device_bonding_complete() Proceeding with service discovery Sep 30 16:52:57 raspberrypi bluetoothd[720]: src/agent.c:agent_unref() 0x1196310: ref=1 Sep 30 16:52:57 raspberrypi bluetoothd[720]: src/adapter.c:resume_discovery()

i guess this may cause the trouble,

cat /proc/version Linux version 4.4.11-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #888 SMP Mon May 23 20:10:33 BST 2016

BlueZ version is 5.41

I found this issue is known as Linux kernel bug: https://github.com/sandeepmistry/noble/issues/242

[olir]

Upgraded to kernel 4.4.22-v7+ but does not fix.

[olir]

Upgrade to Bluez-5.42. Problem still exists. kernel message "Bluetooth: SMP security requested but not available" still occurs before the (unwanted) pairing popup "Paring Requested" is displayed.

Remark Bluez 5.42 still needs patch https://gist.github.com/pelwell/c8230c48ea24698527cd/archive/3b07a1eb296862da889609a84f8e10b299b7442d.zip to recognize the devices.