Hi Claudio, For the last mail issue, I found the root cause is that bluetoothd is not default enable LE connectable undirected advertising in the Gatt server side, so we have to use command manually as: hciconfig hci0 leadv 0, then the gatttool -I can work. And thanks for your advice. For bluez user, finally we hope to call the DBus interface connect method to connect LE device. However, There is still one issue in LE connection in the bluetoothd which can always reproduced in bluez mater branch. We have tried two different ways to connect Gatt server side. One case, we enable LE connectable undirected advertising before the scanning: When we pair the Gatt Client with Gatt server, the bluetoothd thought it is LE device , it will bypass the pairing process just to call device_connect_le device. This will result in connect command in gattool and bluetoothctrl all fail to connect. The other case, we enable LE connectable undirected advertising after the scanning: When we pair the same two devices, the bluetoothd didn't know this is Gatt server is LE device , so it will go throught the normal pairing process. And then enable LE connectable undirected advertising, gattool -I can connect gatt server side successfully. However, One problem is , when we use Bluetoothctrl connect command to connect gatt server, the result is always failed. Because bdaddr_type is BDADDR_BREDR in the dev_connect, so bluetoothd cannot call the device_connect_le function to connect. I think the right scenario is enable LE connectable undirected advertising before the scanning, let the client knows the other side is LE device. So my question is why bluetoothd bypass the pairing process just to call device_connect_le device when enabling LE connectable undirected advertising? And what is the final solution for this issue if user need to call bluez DBus interface connect method in the device-api doc? Thanks a lot Chaojie Gu -b----Original Message----- From: Claudio Takahasi [mailto:claudio.takahasi@xxxxxxxxxxxxx] Sent: Wednesday, April 16, 2014 8:21 PM To: Gu, Chao Jie Cc: linux-bluetooth@xxxxxxxxxxxxxxx; Johan Hedberg Subject: Re: For Gatt feature question. Hi Chaojie Gu, On Wed, Apr 16, 2014 at 5:17 AM, Gu, Chao Jie <chao.jie.gu@xxxxxxxxx> wrote: > Hi, Claudio: > > Sorry for taking your time to ask you question about GATT again. > Recently we have implemented the part of Gatt feature in the > Bluetooth-frwk in Tizen according to the Gatt-API doc in the bluez > 5.18. We hope we can do some test for Gatt Client operation to > contribute Gatt Client DBus API related development. However, now we > have encountered the some issues about how to test GATT operation. > > Firstly, we have to familiar with the test steps about it. Now we > setup two environment for testing. One acts as Gatt Server, the other > acts as Gatt Client. > > For Gatt Server, I've checked out the latest tag (5.18) from git and > have built it and gatt-example.c is compiled into a static plugin that > is loaded at runtime. Through the bluetoothd running, I've confirmed > that the plugin is compiled and is loaded at runtime. When I use > gattool to do some test, connection is failed. > > Gatt server Bluetooth status: > > hci0: Type: BR/EDR Bus: USB > > BD Address: 00:15:83:65:01:90 ACL MTU: 310:10 SCO MTU: 64:8 > > UP RUNNING PSCAN ISCAN > > RX bytes:4394 acl:29 sco:0 events:197 errors:0 > > TX bytes:11856 acl:35 sco:0 commands:139 errors:0 > > > > Gatt client Bluetooth status: > > hci0: Type: BR/EDR Bus: USB > > BD Address: 00:1A:7D:DA:71:0C ACL MTU: 310:10 SCO MTU: 64:8 > > UP RUNNING PSCAN > > RX bytes:104760 acl:34 sco:0 events:619 errors:0 > > TX bytes:5704 acl:31 sco:0 commands:160 errors:0 > > > > My operation step is: > > 1. Scan and Pair the gatt client with gatt server , it pair > successfully. > > 2. In the server side, furthermore to register external gatt service > by gatt-service. > > 3. In the client side, use command line : gatttool -i hci0 -b > 00:15:83:65:01:90 --primary > > To do primary service discovery. > > Command line feedback: Connection refused (111) > > > > The client bluetoothd fail log : > > bluetoothd[29734]: src/adapter.c:connect_failed_callback() hci0 > 00:15:83:65:01:90 status 2 > > bluetoothd[29734]: src/adapter.c:bonding_attempt_complete() hci0 > bdaddr > 00:15:83:65:01:90 type 1 status 0x2 > > bluetoothd[29734]: src/adapter.c:resume_discovery() > > > > gatt_connect function has failed in the gatt tool, any option need to > set in the command line ? Please share the btmon log (of both sides). Check if this problem also happens in BlueZ master. > > Which steps is right method to use gattool to test the gatt operation > or lack other configuration for bluez in the sever side? I recommend to use the interactive mode "-I" and specify the remote address type. > > > > Secondly, there are a lot of patchset about Gatt Client DBus API > implementation. Should we add all the patches into the latest tag > (5.18) to test Gatt Client DBus API? Do you mean re-base your patches to send upstream? First make sure that your implementation is aligned with the requirements that are being discussed in the ML: bt_att_* and shared attribute database. Regards, Claudio ��.n��������+%������w��{.n�����{��� �^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
