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:
noble/noble#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.