Hello Guys,
I am using pandaboard with USB BLE dongle and an apps in iPhone that
do the advertising. I was able to connect to the said device from my
pandaboard using the following commands:
gatttool -i hci1 -m 27 -I -b 74:xx:xx:xx:xx:xx
connect
But, I've noticed that after 30 secs, the iPhone dropped off the
connection. I am just wondering if anyone here have tried playing with
the iPhone using the ble connection?.
Regards,
John
Hi Anderson,
Thanks for the info., we will be going to snip what the iOS is sending
to understand the scenario. I think iOS stack has some handshaking
procedure or required in order to maintain the connection. I used
gatttool to connect to the CC2540 demo board and it did not disconnect
like the iOS does.
Regards,
John
On Mon, Sep 17, 2012 at 1:30 PM, Anderson Lizardo
<[email protected]> wrote:
> Hi John,
>
> On Fri, Sep 14, 2012 at 3:04 PM, John Tobias <[email protected]> wrote:
>> Hi Anderson,
>>
>> Could you give me some bit of information on how to respond to the
>> handle 0x0039?. I'm digging the bluez sources but I'm kind a lost
>> right now and I don't know exactly what library/function should I use
>> in order to configure it.
>
> I suggest you take a look on GATT Procedures on the Core spec (see
> "Discover All Characteristics of a Service" on pages 1916 and the
> Figure 4.5 on page 1917). You will see that "Attribute not found" is
> used to inform the client that there are no more characteristics to
> discover.
>
> Also see channel_handler() in src/attrib-server.c (and the functions
> called by it) to understand how BlueZ's GATT server work.
>
> To avoid the GATT disconnection after 30 sec. you really need to
> figure out what the iPhone app is trying to do, it is clear from your
> hcidump logs that iPhone is disconnecting, not the Linux "client"
> side.
>
> Regards,
> --
> Anderson Lizardo
> Instituto Nokia de Tecnologia - INdT
> Manaus - Brazil
Hi John,
On Fri, Sep 14, 2012 at 3:04 PM, John Tobias <[email protected]> wrote:
> Hi Anderson,
>
> Could you give me some bit of information on how to respond to the
> handle 0x0039?. I'm digging the bluez sources but I'm kind a lost
> right now and I don't know exactly what library/function should I use
> in order to configure it.
I suggest you take a look on GATT Procedures on the Core spec (see
"Discover All Characteristics of a Service" on pages 1916 and the
Figure 4.5 on page 1917). You will see that "Attribute not found" is
used to inform the client that there are no more characteristics to
discover.
Also see channel_handler() in src/attrib-server.c (and the functions
called by it) to understand how BlueZ's GATT server work.
To avoid the GATT disconnection after 30 sec. you really need to
figure out what the iPhone app is trying to do, it is clear from your
hcidump logs that iPhone is disconnecting, not the Linux "client"
side.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
Hi Anderson,
Could you give me some bit of information on how to respond to the
handle 0x0039?. I'm digging the bluez sources but I'm kind a lost
right now and I don't know exactly what library/function should I use
in order to configure it.
Regards,
John
On Thu, Sep 13, 2012 at 2:59 PM, John Tobias <[email protected]> wrote:
> Hi Anderson,
>
> I added these line of codes in gatttool:
>
> listen_start:
> g_attrib_register(attrib, ATT_OP_READ_BY_TYPE_RESP, events_handler,
> attrib, NULL);
>
> Then, in events_handler I dumped the handles for
> ATT_OP_READ_BY_TYPE_REQ and ATT_OP_READ_BY_TYPE_RESP:
>
> ATT_OP_READ_BY_TYPE_REQ: handle = 0x1 value: ff ff 00 2a
> ATT_OP_READ_BY_TYPE_RESP: handle = 0x207 value: 00 02 03 00 00 2a 04
> 00 02 05 00 01 2a 07 00 20 08 00 05 2a
> ATT_OP_READ_BY_TYPE_RESP: handle = 0xb15 value: 00 02 0c 00 31 3d 35
> 06 1e 60 70 a3 8d 4e 58 9c 2d 6a 3c 16
> ATT_OP_READ_BY_TYPE_RESP: handle = 0xd15 value: 00 8a 0e 00 32 3d 35
> 06 1e 60 70 a3 8d 4e 58 9c 2d 6a 3c 16
> ATT_OP_READ_BY_TYPE_RESP: handle = 0x1015 value: 00 88 11 00 33 3d
> 35 06 1e 60 70 a3 8d 4e 58 9c 2d 6a 3c 16
> ATT_OP_READ_BY_TYPE_RESP: handle = 0x1315 value: 00 9a 14 00 52 72
> 3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
> ATT_OP_READ_BY_TYPE_RESP: handle = 0x1715 value: 00 9a 18 00 36 72
> 3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
> ATT_OP_READ_BY_TYPE_RESP: handle = 0x1b15 value: 00 9a 1c 00 37 72
> 3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
> ATT_OP_READ_BY_TYPE_RESP: handle = 0x1f15 value: 00 8a 20 00 38 72
> 3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
> ATT_OP_READ_BY_TYPE_RESP: handle = 0x2215 value: 00 98 23 00 40 72
> 3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
> ATT_OP_READ_BY_TYPE_RESP: handle = 0x2615 value: 00 9a 27 00 41 72
> 3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
> ATT_OP_READ_BY_TYPE_RESP: handle = 0x2a15 value: 00 98 2b 00 42 72
> 3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
> ATT_OP_READ_BY_TYPE_RESP: handle = 0x2e15 value: 00 88 2f 00 60 72
> 3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
> ATT_OP_READ_BY_TYPE_RESP: handle = 0x3115 value: 00 88 32 00 61 72
> 3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
> ATT_OP_READ_BY_TYPE_RESP: handle = 0x3415 value: 00 12 35 00 62 72
> 3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
> ATT_OP_READ_BY_TYPE_RESP: handle = 0x3715 value: 00 8a 38 00 39 72
> 3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
>
> In hcidump:
>
> ACL data: handle 76 flags 0x02 dlen 9
> ATT: Error (0x01)
> Error: Attribute not found (10)
> Read By Type req (0x08) on handle 0x0039
>
>
> In hcidump, the error was the attribute for handle 0x0039. How I can
> respond to that request if the I did not receive the said handle?
>
>
> Regards,
>
> John
>
>
>
> On Thu, Sep 13, 2012 at 1:18 PM, Anderson Lizardo
> <[email protected]> wrote:
>> Hi John,
>>
>> On Thu, Sep 13, 2012 at 4:11 PM, John Tobias <[email protected]> wrote:
>>> Hi Anderson,
>>>
>>> If I add a simple GATT/GAP server on gatttool, should I still use the
>>> DBUS to listen or I can communicate directly to the kernel?.
>>
>> You either talk to bluetoothd (using D-Bus, like those test-* python
>> scripts do), which will handle connections for you, or you talk
>> directly to kernel using bluetooth socket (like gatttool does). You
>> have more flexibility talking to the kernel directly, but your app
>> will not be interoperable with other apps running at the same time,
>> specially if they try to call connect() at the same time (one of them
>> will get a EBUSY error).
>>
>> Using D-Bus, on the other hand, bluetoothd queues the connections properly.
>>
>> So you should use what is more appropriate for your use case.
>>
>> Best Regards,
>> --
>> Anderson Lizardo
>> Instituto Nokia de Tecnologia - INdT
>> Manaus - Brazil
Hi Anderson,
I added these line of codes in gatttool:
listen_start:
g_attrib_register(attrib, ATT_OP_READ_BY_TYPE_RESP, events_handler,
attrib, NULL);
Then, in events_handler I dumped the handles for
ATT_OP_READ_BY_TYPE_REQ and ATT_OP_READ_BY_TYPE_RESP:
ATT_OP_READ_BY_TYPE_REQ: handle = 0x1 value: ff ff 00 2a
ATT_OP_READ_BY_TYPE_RESP: handle = 0x207 value: 00 02 03 00 00 2a 04
00 02 05 00 01 2a 07 00 20 08 00 05 2a
ATT_OP_READ_BY_TYPE_RESP: handle = 0xb15 value: 00 02 0c 00 31 3d 35
06 1e 60 70 a3 8d 4e 58 9c 2d 6a 3c 16
ATT_OP_READ_BY_TYPE_RESP: handle = 0xd15 value: 00 8a 0e 00 32 3d 35
06 1e 60 70 a3 8d 4e 58 9c 2d 6a 3c 16
ATT_OP_READ_BY_TYPE_RESP: handle = 0x1015 value: 00 88 11 00 33 3d
35 06 1e 60 70 a3 8d 4e 58 9c 2d 6a 3c 16
ATT_OP_READ_BY_TYPE_RESP: handle = 0x1315 value: 00 9a 14 00 52 72
3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
ATT_OP_READ_BY_TYPE_RESP: handle = 0x1715 value: 00 9a 18 00 36 72
3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
ATT_OP_READ_BY_TYPE_RESP: handle = 0x1b15 value: 00 9a 1c 00 37 72
3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
ATT_OP_READ_BY_TYPE_RESP: handle = 0x1f15 value: 00 8a 20 00 38 72
3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
ATT_OP_READ_BY_TYPE_RESP: handle = 0x2215 value: 00 98 23 00 40 72
3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
ATT_OP_READ_BY_TYPE_RESP: handle = 0x2615 value: 00 9a 27 00 41 72
3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
ATT_OP_READ_BY_TYPE_RESP: handle = 0x2a15 value: 00 98 2b 00 42 72
3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
ATT_OP_READ_BY_TYPE_RESP: handle = 0x2e15 value: 00 88 2f 00 60 72
3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
ATT_OP_READ_BY_TYPE_RESP: handle = 0x3115 value: 00 88 32 00 61 72
3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
ATT_OP_READ_BY_TYPE_RESP: handle = 0x3415 value: 00 12 35 00 62 72
3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
ATT_OP_READ_BY_TYPE_RESP: handle = 0x3715 value: 00 8a 38 00 39 72
3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
In hcidump:
ACL data: handle 76 flags 0x02 dlen 9
ATT: Error (0x01)
Error: Attribute not found (10)
Read By Type req (0x08) on handle 0x0039
In hcidump, the error was the attribute for handle 0x0039. How I can
respond to that request if the I did not receive the said handle?
Regards,
John
On Thu, Sep 13, 2012 at 1:18 PM, Anderson Lizardo
<[email protected]> wrote:
> Hi John,
>
> On Thu, Sep 13, 2012 at 4:11 PM, John Tobias <[email protected]> wrote:
>> Hi Anderson,
>>
>> If I add a simple GATT/GAP server on gatttool, should I still use the
>> DBUS to listen or I can communicate directly to the kernel?.
>
> You either talk to bluetoothd (using D-Bus, like those test-* python
> scripts do), which will handle connections for you, or you talk
> directly to kernel using bluetooth socket (like gatttool does). You
> have more flexibility talking to the kernel directly, but your app
> will not be interoperable with other apps running at the same time,
> specially if they try to call connect() at the same time (one of them
> will get a EBUSY error).
>
> Using D-Bus, on the other hand, bluetoothd queues the connections properly.
>
> So you should use what is more appropriate for your use case.
>
> Best Regards,
> --
> Anderson Lizardo
> Instituto Nokia de Tecnologia - INdT
> Manaus - Brazil
Hi John,
On Thu, Sep 13, 2012 at 4:11 PM, John Tobias <[email protected]> wrote:
> Hi Anderson,
>
> If I add a simple GATT/GAP server on gatttool, should I still use the
> DBUS to listen or I can communicate directly to the kernel?.
You either talk to bluetoothd (using D-Bus, like those test-* python
scripts do), which will handle connections for you, or you talk
directly to kernel using bluetooth socket (like gatttool does). You
have more flexibility talking to the kernel directly, but your app
will not be interoperable with other apps running at the same time,
specially if they try to call connect() at the same time (one of them
will get a EBUSY error).
Using D-Bus, on the other hand, bluetoothd queues the connections properly.
So you should use what is more appropriate for your use case.
Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
Hi John,
On Thu, Sep 13, 2012 at 2:44 PM, John Tobias <[email protected]> wrote:
>> Which messages did you see?
>
> The ran the bluetoothd with debug message:
>
> [snip]
This log just shows the temporary device being created due to the
connection made by gatttool. bluetoothd does not have any open socket
where the ATT requests could be handled (unless the connection was
created by bluetoothd itself and not gatttool).
If bluetoothd GATT server processed the ATT request sent by your
phone, you would see this:
bluetoothd[NNNN]: src/attrib-server.c:channel_handler() op 0x10
Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
Hi Anderson,
If I add a simple GATT/GAP server on gatttool, should I still use the
DBUS to listen or I can communicate directly to the kernel?.
Regards,
John
On Thu, Sep 13, 2012 at 11:44 AM, John Tobias <[email protected]> wrote:
> Hi Anderson,
>
>
>
> On Thu, Sep 13, 2012 at 11:36 AM, Anderson Lizardo
> <[email protected]> wrote:
>> Hi John,
>>
>> On Thu, Sep 13, 2012 at 2:18 PM, John Tobias <[email protected]> wrote:
>>> Hi Anderson,
>>>
>>> Here's what I did:
>>>
>>> I set the EnableGatt=true and executed my bluetoothd. The debug
>>> messages of bluetoothd confirmed that it was responding to the request
>>> of my iPhone.
>>
>> Which messages did you see?
>
> The ran the bluetoothd with debug message:
>
> bluetoothd[14762]: plugins/mgmtops.c:mgmt_event() cond 1
> bluetoothd[14762]: plugins/mgmtops.c:mgmt_event() Received 19 bytes
> from management socket
> bluetoothd[14762]: plugins/mgmtops.c:mgmt_device_connected() hci0
> device 6E:FA:41:C4:DA:AD connected eir_len 0
> bluetoothd[14762]: src/event.c:btd_event_conn_complete() Entry:
> btd_event_conn_complete
> bluetoothd[14762]: src/adapter.c:adapter_get_device() 6E:FA:41:C4:DA:AD
> bluetoothd[14762]: src/adapter.c:adapter_create_device() 6E:FA:41:C4:DA:AD
> bluetoothd[14762]: src/device.c:device_create() Creating device
> /org/bluez/14762/hci0/dev_6E_FA_41_C4_DA_AD
> bluetoothd[14762]: src/device.c:btd_device_ref() 0xb8600018: ref=1
> bluetoothd[14762]: src/device.c:device_set_temporary() temporary 1
> bluetoothd[14762]: plugins/mgmtops.c:mgmt_event() cond 1
> bluetoothd[14762]: plugins/mgmtops.c:mgmt_event() Received 13 bytes
> from management socket
> bluetoothd[14762]: plugins/mgmtops.c:mgmt_device_disconnected() hci0
> device 6E:FA:41:C4:DA:AD disconnected
> bluetoothd[14762]: src/event.c:btd_event_disconn_complete()
> bluetoothd[14762]: src/adapter.c:adapter_remove_connection()
> bluetoothd[14762]: src/adapter.c:adapter_remove_connection() Removing
> temporary device /org/bluez/14762/hci0/dev_6E_FA_41_C4_DA_AD
> bluetoothd[14762]: src/device.c:device_remove() Removing device
> /org/bluez/14762/hci0/dev_6E_FA_41_C4_DA_AD
> bluetoothd[14762]: src/device.c:btd_device_unref() 0xb8600018: ref=0
> bluetoothd[14762]: src/device.c:device_free() 0xb8600018
>
>
>
> I will look at the code you mention and will start from there.
>
> Regards,
>
> john
>
>>
>>>
>>> I used gatttool to connect to the device and read the characteristic..
>>
>> gatttool is only for testing. It will open a bluetooth socket and talk
>> directly with the kernel (without bluetoothd help). In fact, it runs
>> just fine without any bluetoothd running (you need to do a "hciconfig
>> hciX up" though).
>>
>> If you want your app to properly integrate with bluetoothd, you need
>> to create connections using BlueZ's D-Bus APIs.
>>
>> Take a look at some example code:
>>
>> test/test-device (if you need to do the pairing from your application)
>> test/test-attrib (if you want to talk to some profile not supported by
>> BlueZ yet)
>> test/test-thermometer (for GATT Health Thermometer)
>> test/test-proximity (for GATT Proximity)
>> ...
>>
>> if the profile you want to use is one of the official ones, we
>> encourage you implement them as a BlueZ plugin, and provide some D-Bus
>> API that your app (or other apps) can use. That way we avoid
>> duplicating profile implementations. See for example the thermometer
>> (HTP) and proximity (PXP) implementations in BlueZ.
>>
>> Some others are in process of being implemented upstream: Battery,
>> Heart Rate, and Server profiles (Time, Alert Notification, Phone Alert
>> Status).
>>
>> Best Regards,
>> --
>> Anderson Lizardo
>> Instituto Nokia de Tecnologia - INdT
>> Manaus - Brazil
Hi Anderson,
On Thu, Sep 13, 2012 at 11:36 AM, Anderson Lizardo
<[email protected]> wrote:
> Hi John,
>
> On Thu, Sep 13, 2012 at 2:18 PM, John Tobias <[email protected]> wrote:
>> Hi Anderson,
>>
>> Here's what I did:
>>
>> I set the EnableGatt=true and executed my bluetoothd. The debug
>> messages of bluetoothd confirmed that it was responding to the request
>> of my iPhone.
>
> Which messages did you see?
The ran the bluetoothd with debug message:
bluetoothd[14762]: plugins/mgmtops.c:mgmt_event() cond 1
bluetoothd[14762]: plugins/mgmtops.c:mgmt_event() Received 19 bytes
from management socket
bluetoothd[14762]: plugins/mgmtops.c:mgmt_device_connected() hci0
device 6E:FA:41:C4:DA:AD connected eir_len 0
bluetoothd[14762]: src/event.c:btd_event_conn_complete() Entry:
btd_event_conn_complete
bluetoothd[14762]: src/adapter.c:adapter_get_device() 6E:FA:41:C4:DA:AD
bluetoothd[14762]: src/adapter.c:adapter_create_device() 6E:FA:41:C4:DA:AD
bluetoothd[14762]: src/device.c:device_create() Creating device
/org/bluez/14762/hci0/dev_6E_FA_41_C4_DA_AD
bluetoothd[14762]: src/device.c:btd_device_ref() 0xb8600018: ref=1
bluetoothd[14762]: src/device.c:device_set_temporary() temporary 1
bluetoothd[14762]: plugins/mgmtops.c:mgmt_event() cond 1
bluetoothd[14762]: plugins/mgmtops.c:mgmt_event() Received 13 bytes
from management socket
bluetoothd[14762]: plugins/mgmtops.c:mgmt_device_disconnected() hci0
device 6E:FA:41:C4:DA:AD disconnected
bluetoothd[14762]: src/event.c:btd_event_disconn_complete()
bluetoothd[14762]: src/adapter.c:adapter_remove_connection()
bluetoothd[14762]: src/adapter.c:adapter_remove_connection() Removing
temporary device /org/bluez/14762/hci0/dev_6E_FA_41_C4_DA_AD
bluetoothd[14762]: src/device.c:device_remove() Removing device
/org/bluez/14762/hci0/dev_6E_FA_41_C4_DA_AD
bluetoothd[14762]: src/device.c:btd_device_unref() 0xb8600018: ref=0
bluetoothd[14762]: src/device.c:device_free() 0xb8600018
I will look at the code you mention and will start from there.
Regards,
john
>
>>
>> I used gatttool to connect to the device and read the characteristic..
>
> gatttool is only for testing. It will open a bluetooth socket and talk
> directly with the kernel (without bluetoothd help). In fact, it runs
> just fine without any bluetoothd running (you need to do a "hciconfig
> hciX up" though).
>
> If you want your app to properly integrate with bluetoothd, you need
> to create connections using BlueZ's D-Bus APIs.
>
> Take a look at some example code:
>
> test/test-device (if you need to do the pairing from your application)
> test/test-attrib (if you want to talk to some profile not supported by
> BlueZ yet)
> test/test-thermometer (for GATT Health Thermometer)
> test/test-proximity (for GATT Proximity)
> ...
>
> if the profile you want to use is one of the official ones, we
> encourage you implement them as a BlueZ plugin, and provide some D-Bus
> API that your app (or other apps) can use. That way we avoid
> duplicating profile implementations. See for example the thermometer
> (HTP) and proximity (PXP) implementations in BlueZ.
>
> Some others are in process of being implemented upstream: Battery,
> Heart Rate, and Server profiles (Time, Alert Notification, Phone Alert
> Status).
>
> Best Regards,
> --
> Anderson Lizardo
> Instituto Nokia de Tecnologia - INdT
> Manaus - Brazil
Hi John,
On Thu, Sep 13, 2012 at 2:18 PM, John Tobias <[email protected]> wrote:
> Hi Anderson,
>
> Here's what I did:
>
> I set the EnableGatt=true and executed my bluetoothd. The debug
> messages of bluetoothd confirmed that it was responding to the request
> of my iPhone.
Which messages did you see?
>
> I used gatttool to connect to the device and read the characteristic..
gatttool is only for testing. It will open a bluetooth socket and talk
directly with the kernel (without bluetoothd help). In fact, it runs
just fine without any bluetoothd running (you need to do a "hciconfig
hciX up" though).
If you want your app to properly integrate with bluetoothd, you need
to create connections using BlueZ's D-Bus APIs.
Take a look at some example code:
test/test-device (if you need to do the pairing from your application)
test/test-attrib (if you want to talk to some profile not supported by
BlueZ yet)
test/test-thermometer (for GATT Health Thermometer)
test/test-proximity (for GATT Proximity)
...
if the profile you want to use is one of the official ones, we
encourage you implement them as a BlueZ plugin, and provide some D-Bus
API that your app (or other apps) can use. That way we avoid
duplicating profile implementations. See for example the thermometer
(HTP) and proximity (PXP) implementations in BlueZ.
Some others are in process of being implemented upstream: Battery,
Heart Rate, and Server profiles (Time, Alert Notification, Phone Alert
Status).
Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
Hi Anderson,
Here's what I did:
I set the EnableGatt=true and executed my bluetoothd. The debug
messages of bluetoothd confirmed that it was responding to the request
of my iPhone.
I used gatttool to connect to the device and read the characteristic..
Is this scenario should work or not?.
Regards,
john
On Thu, Sep 13, 2012 at 11:07 AM, Anderson Lizardo
<[email protected]> wrote:
> Hi John,
>
> On Thu, Sep 13, 2012 at 1:50 PM, John Tobias <[email protected]> wrote:
>> Hi Anderson,
>>
>> Here are the logs after reading the characteristic from my iPad apps
>> that do the advertising.
>
> I can just confirm what Vinicius said, the disconnection after 30s
> happens because the IPad sent a "Read By Type req" that gatttool does
> not answer because it does not run a GATT server.
>
> Are you planning to implement any client (or server) profile for these
> apps? If so, you should look at how to implement them as BlueZ
> plugins.
>
> You could also try to implement a simple GATT/GAP server on gatttool,
> so you could use it for testing without any disconnections.
>
>
> PS: interestingly, it seems IPad apps are able to send connectable
> advertising over LE channel from a dual mode controller... which is
> against Core spec 4.0... odd.
>
> Regards,
> --
> Anderson Lizardo
> Instituto Nokia de Tecnologia - INdT
> Manaus - Brazil
Hi John,
On Thu, Sep 13, 2012 at 1:50 PM, John Tobias <[email protected]> wrote:
> Hi Anderson,
>
> Here are the logs after reading the characteristic from my iPad apps
> that do the advertising.
I can just confirm what Vinicius said, the disconnection after 30s
happens because the IPad sent a "Read By Type req" that gatttool does
not answer because it does not run a GATT server.
Are you planning to implement any client (or server) profile for these
apps? If so, you should look at how to implement them as BlueZ
plugins.
You could also try to implement a simple GATT/GAP server on gatttool,
so you could use it for testing without any disconnections.
PS: interestingly, it seems IPad apps are able to send connectable
advertising over LE channel from a dual mode controller... which is
against Core spec 4.0... odd.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
Hi Anderson,
Here are the logs after reading the characteristic from my iPad apps
that do the advertising.
HCI sniffer - Bluetooth packet analyzer ver 2.2
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
type 0x01 (active)
interval 10.000ms window 10.000ms
own address: 0x00 (Public) policy: All
> HCI Event: Command Complete (0x0e) plen 4
LE Set Scan Parameters (0x08|0x000b) ncmd 1
status 0x00
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
value 0x01 (scanning enabled)
filter duplicates 0x01 (enabled)
> HCI Event: Command Complete (0x0e) plen 4
LE Set Scan Enable (0x08|0x000c) ncmd 1
status 0x00
> HCI Event: LE Meta Event (0x3e) plen 43
LE Advertising Report
ADV_IND - Connectable undirected advertising (0)
bdaddr 60:36:25:4A:6B:75 (Random)
Flags: 0x1a
Unknown type 0x07 with 16 bytes data
Complete local name: 'Appl0001'
RSSI: -62
> HCI Event: LE Meta Event (0x3e) plen 12
LE Advertising Report
SCAN_RSP - Scan Response (4)
bdaddr 60:36:25:4A:6B:75 (Random)
RSSI: -62
> HCI Event: LE Meta Event (0x3e) plen 43
LE Advertising Report
ADV_IND - Connectable undirected advertising (0)
bdaddr 60:36:25:4A:6B:75 (Random)
Flags: 0x1a
Unknown type 0x07 with 16 bytes data
Complete local name: 'Appl0001'
RSSI: -60
> HCI Event: LE Meta Event (0x3e) plen 12
LE Advertising Report
SCAN_RSP - Scan Response (4)
bdaddr 60:36:25:4A:6B:75 (Random)
RSSI: -60
> HCI Event: LE Meta Event (0x3e) plen 43
LE Advertising Report
ADV_IND - Connectable undirected advertising (0)
bdaddr 60:36:25:4A:6B:75 (Random)
Flags: 0x1a
Unknown type 0x07 with 16 bytes data
Complete local name: 'Appl0001'
RSSI: -62
> HCI Event: LE Meta Event (0x3e) plen 12
LE Advertising Report
SCAN_RSP - Scan Response (4)
bdaddr 60:36:25:4A:6B:75 (Random)
RSSI: -62
> HCI Event: LE Meta Event (0x3e) plen 43
LE Advertising Report
ADV_IND - Connectable undirected advertising (0)
bdaddr 60:36:25:4A:6B:75 (Random)
Flags: 0x1a
Unknown type 0x07 with 16 bytes data
Complete local name: 'Appl0001'
RSSI: -69
> HCI Event: LE Meta Event (0x3e) plen 12
LE Advertising Report
SCAN_RSP - Scan Response (4)
bdaddr 60:36:25:4A:6B:75 (Random)
RSSI: -69
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
value 0x00 (scanning disabled)
filter duplicates 0x01 (enabled)
> HCI Event: Command Complete (0x0e) plen 4
LE Set Scan Enable (0x08|0x000c) ncmd 1
status 0x00
< HCI Command: LE Create Connection (0x08|0x000d) plen 25
bdaddr 60:36:25:4A:6B:75 type 1
> HCI Event: Command Status (0x0f) plen 4
LE Create Connection (0x08|0x000d) status 0x00 ncmd 1
> HCI Event: LE Meta Event (0x3e) plen 19
LE Connection Complete
status 0x00 handle 76, role master
bdaddr 60:36:25:4A:6B:75 (Random)
> ACL data: handle 76 flags 0x02 dlen 11
ATT: Read By Type req (0x08)
start 0x0001, end 0xffff
type-uuid 0x2a00
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x0001, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 7
handle 0x0002, value 0x02 0x03 0x00 0x00 0x2a
handle 0x0004, value 0x02 0x05 0x00 0x01 0x2a
handle 0x0007, value 0x20 0x08 0x00 0x05 0x2a
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x0008, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x000b, value 0x02 0x0c 0x00 0x31 0x3d 0x35 0x06 0x1e
0x60 0x70 0xa3 0x8d 0x4e 0x58 0x9c 0x2d 0x6a 0x3c 0x16
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x000c, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x000d, value 0x8a 0x0e 0x00 0x32 0x3d 0x35 0x06 0x1e
0x60 0x70 0xa3 0x8d 0x4e 0x58 0x9c 0x2d 0x6a 0x3c 0x16
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x000e, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x0010, value 0x88 0x11 0x00 0x33 0x3d 0x35 0x06 0x1e
0x60 0x70 0xa3 0x8d 0x4e 0x58 0x9c 0x2d 0x6a 0x3c 0x16
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x0011, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x0013, value 0x9a 0x14 0x00 0x52 0x72 0x3a 0x71 0xae
0x82 0x0c 0xae 0xe0 0x49 0x1d 0x18 0xc2 0xb4 0xd8 0x37
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x0014, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x0017, value 0x9a 0x18 0x00 0x36 0x72 0x3a 0x71 0xae
0x82 0x0c 0xae 0xe0 0x49 0x1d 0x18 0xc2 0xb4 0xd8 0x37
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x0018, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x001b, value 0x9a 0x1c 0x00 0x37 0x72 0x3a 0x71 0xae
0x82 0x0c 0xae 0xe0 0x49 0x1d 0x18 0xc2 0xb4 0xd8 0x37
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x001c, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x001f, value 0x8a 0x20 0x00 0x38 0x72 0x3a 0x71 0xae
0x82 0x0c 0xae 0xe0 0x49 0x1d 0x18 0xc2 0xb4 0xd8 0x37
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x0020, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x0022, value 0x98 0x23 0x00 0x40 0x72 0x3a 0x71 0xae
0x82 0x0c 0xae 0xe0 0x49 0x1d 0x18 0xc2 0xb4 0xd8 0x37
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x0023, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x0026, value 0x9a 0x27 0x00 0x41 0x72 0x3a 0x71 0xae
0x82 0x0c 0xae 0xe0 0x49 0x1d 0x18 0xc2 0xb4 0xd8 0x37
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x0027, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x002a, value 0x98 0x2b 0x00 0x42 0x72 0x3a 0x71 0xae
0x82 0x0c 0xae 0xe0 0x49 0x1d 0x18 0xc2 0xb4 0xd8 0x37
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x002b, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x002e, value 0x88 0x2f 0x00 0x60 0x72 0x3a 0x71 0xae
0x82 0x0c 0xae 0xe0 0x49 0x1d 0x18 0xc2 0xb4 0xd8 0x37
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x002f, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x0031, value 0x88 0x32 0x00 0x61 0x72 0x3a 0x71 0xae
0x82 0x0c 0xae 0xe0 0x49 0x1d 0x18 0xc2 0xb4 0xd8 0x37
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x0032, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x0034, value 0x12 0x35 0x00 0x62 0x72 0x3a 0x71 0xae
0x82 0x0c 0xae 0xe0 0x49 0x1d 0x18 0xc2 0xb4 0xd8 0x37
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x0035, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x0037, value 0x8a 0x38 0x00 0x39 0x72 0x3a 0x71 0xae
0x82 0x0c 0xae 0xe0 0x49 0x1d 0x18 0xc2 0xb4 0xd8 0x37
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x0038, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 9
ATT: Error (0x01)
Error: Attribute not found (10)
Read By Type req (0x08) on handle 0x0039
> HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 76 reason 0x13
Reason: Remote User Terminated Connection
Regards,
John
On Thu, Sep 13, 2012 at 3:53 AM, Anderson Lizardo
<[email protected]> wrote:
> Hi John,
>
> On Wed, Sep 12, 2012 at 10:52 PM, John Tobias <[email protected]> wrote:
>> Hello again,
>>
>> I enabled the GATT in my bluetoothd and found out that there was an
>> unimplemented attribute (below) and might be the reason why the iPhone
>> connection got disconnected after 30 secs.
>>
>> 2012-09-12 15:36:55.419980 > ACL data: handle 76 flags 0x02 dlen 9
>> ATT: Error (0x01)
>> Error: Attribute not found (10)
>> Read By Type req (0x08) on handle 0x0039
>>
>> I would like to know if anyone here has a patch?.
>
> Just this snippet does not say much. "Attribute not found" errors are
> common during service/characteristic discovery because they indicate
> that the discovery has finished.
>
> Could you post the whole hcidump since the connection establishment up
> to the disconnection? That should help detecting the problem.
>
> Best Regards,
> --
> Anderson Lizardo
> Instituto Nokia de Tecnologia - INdT
> Manaus - Brazil
Hi John,
On Wed, Sep 12, 2012 at 10:52 PM, John Tobias <[email protected]> wrote:
> Hello again,
>
> I enabled the GATT in my bluetoothd and found out that there was an
> unimplemented attribute (below) and might be the reason why the iPhone
> connection got disconnected after 30 secs.
>
> 2012-09-12 15:36:55.419980 > ACL data: handle 76 flags 0x02 dlen 9
> ATT: Error (0x01)
> Error: Attribute not found (10)
> Read By Type req (0x08) on handle 0x0039
>
> I would like to know if anyone here has a patch?.
Just this snippet does not say much. "Attribute not found" errors are
common during service/characteristic discovery because they indicate
that the discovery has finished.
Could you post the whole hcidump since the connection establishment up
to the disconnection? That should help detecting the problem.
Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
Hello again,
I enabled the GATT in my bluetoothd and found out that there was an
unimplemented attribute (below) and might be the reason why the iPhone
connection got disconnected after 30 secs.
2012-09-12 15:36:55.419980 > ACL data: handle 76 flags 0x02 dlen 9
ATT: Error (0x01)
Error: Attribute not found (10)
Read By Type req (0x08) on handle 0x0039
I would like to know if anyone here has a patch?.
Regards,
john
On Mon, Sep 10, 2012 at 5:45 PM, John Tobias <[email protected]> wrote:
> thanks for the info.
>
> Regards,
>
> john
>
> On Mon, Sep 10, 2012 at 4:58 PM, Vinicius Costa Gomes
> <[email protected]> wrote:
>> Hi John,
>>
>> On 16:34 Mon 10 Sep, John Tobias wrote:
>>> Just to follow up, I used hcidump and found out an interesting info:
>>>
>>> bdaddr 5C:35:3C:72:B2:AF type 1
>>> > HCI Event: Command Status (0x0f) plen 4
>>> LE Create Connection (0x08|0x000d) status 0x00 ncmd 1
>>> > HCI Event: LE Meta Event (0x3e) plen 19
>>> LE Connection Complete
>>> status 0x00 handle 77, role master
>>> bdaddr 5C:35:3C:72:B2:AF (Random)
>>> > ACL data: handle 77 flags 0x02 dlen 11
>>> ATT: Read By Type req (0x08)
>>> start 0x0001, end 0xffff
>>> type-uuid 0x2a00
>>> > HCI Event: Disconn Complete (0x05) plen 4
>>> status 0x00 handle 77 reason 0x13
>>> Reason: Remote User Terminated Connection
>>>
>>>
>>> The iPhone was requesting for "ATT: Read By Type req (0x08)" and the
>>> gatttool seems not reponding. So, after 30 secs the iPhone dropped the
>>> connection.
>>>
>>> Any idea how the gatttool could respond to the said request?.
>>
>> The problem is that gatttool still hasn't any support for sending
>> responses. bluetoothd has, if you enable GATT support, 'EnableGatt' in
>> '/etc/bluetooth/main.conf' (usual location).
>>
>> But using 'bluetoothd' means that will need to use the D-Bus API, which
>> makes me wonder that having a simple GATT server inside gatttool makes
>> some sense, for some use cases.
>>
>>>
>>> Regards,
>>>
>>> john
>>>
>>>
>>> On Mon, Sep 10, 2012 at 2:35 PM, John Tobias <[email protected]> wrote:
>>> > Hello Guys,
>>> >
>>> > I am using pandaboard with USB BLE dongle and an apps in iPhone that
>>> > do the advertising. I was able to connect to the said device from my
>>> > pandaboard using the following commands:
>>> >
>>> > gatttool -i hci1 -m 27 -I -b 74:xx:xx:xx:xx:xx
>>> > connect
>>> >
>>> > But, I've noticed that after 30 secs, the iPhone dropped off the
>>> > connection. I am just wondering if anyone here have tried playing with
>>> > the iPhone using the ble connection?.
>>> >
>>> > Regards,
>>> >
>>> > John
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>> Cheers,
>> --
>> Vinicius
thanks for the info.
Regards,
john
On Mon, Sep 10, 2012 at 4:58 PM, Vinicius Costa Gomes
<[email protected]> wrote:
> Hi John,
>
> On 16:34 Mon 10 Sep, John Tobias wrote:
>> Just to follow up, I used hcidump and found out an interesting info:
>>
>> bdaddr 5C:35:3C:72:B2:AF type 1
>> > HCI Event: Command Status (0x0f) plen 4
>> LE Create Connection (0x08|0x000d) status 0x00 ncmd 1
>> > HCI Event: LE Meta Event (0x3e) plen 19
>> LE Connection Complete
>> status 0x00 handle 77, role master
>> bdaddr 5C:35:3C:72:B2:AF (Random)
>> > ACL data: handle 77 flags 0x02 dlen 11
>> ATT: Read By Type req (0x08)
>> start 0x0001, end 0xffff
>> type-uuid 0x2a00
>> > HCI Event: Disconn Complete (0x05) plen 4
>> status 0x00 handle 77 reason 0x13
>> Reason: Remote User Terminated Connection
>>
>>
>> The iPhone was requesting for "ATT: Read By Type req (0x08)" and the
>> gatttool seems not reponding. So, after 30 secs the iPhone dropped the
>> connection.
>>
>> Any idea how the gatttool could respond to the said request?.
>
> The problem is that gatttool still hasn't any support for sending
> responses. bluetoothd has, if you enable GATT support, 'EnableGatt' in
> '/etc/bluetooth/main.conf' (usual location).
>
> But using 'bluetoothd' means that will need to use the D-Bus API, which
> makes me wonder that having a simple GATT server inside gatttool makes
> some sense, for some use cases.
>
>>
>> Regards,
>>
>> john
>>
>>
>> On Mon, Sep 10, 2012 at 2:35 PM, John Tobias <[email protected]> wrote:
>> > Hello Guys,
>> >
>> > I am using pandaboard with USB BLE dongle and an apps in iPhone that
>> > do the advertising. I was able to connect to the said device from my
>> > pandaboard using the following commands:
>> >
>> > gatttool -i hci1 -m 27 -I -b 74:xx:xx:xx:xx:xx
>> > connect
>> >
>> > But, I've noticed that after 30 secs, the iPhone dropped off the
>> > connection. I am just wondering if anyone here have tried playing with
>> > the iPhone using the ble connection?.
>> >
>> > Regards,
>> >
>> > John
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> Cheers,
> --
> Vinicius
Hi John,
On 16:34 Mon 10 Sep, John Tobias wrote:
> Just to follow up, I used hcidump and found out an interesting info:
>
> bdaddr 5C:35:3C:72:B2:AF type 1
> > HCI Event: Command Status (0x0f) plen 4
> LE Create Connection (0x08|0x000d) status 0x00 ncmd 1
> > HCI Event: LE Meta Event (0x3e) plen 19
> LE Connection Complete
> status 0x00 handle 77, role master
> bdaddr 5C:35:3C:72:B2:AF (Random)
> > ACL data: handle 77 flags 0x02 dlen 11
> ATT: Read By Type req (0x08)
> start 0x0001, end 0xffff
> type-uuid 0x2a00
> > HCI Event: Disconn Complete (0x05) plen 4
> status 0x00 handle 77 reason 0x13
> Reason: Remote User Terminated Connection
>
>
> The iPhone was requesting for "ATT: Read By Type req (0x08)" and the
> gatttool seems not reponding. So, after 30 secs the iPhone dropped the
> connection.
>
> Any idea how the gatttool could respond to the said request?.
The problem is that gatttool still hasn't any support for sending
responses. bluetoothd has, if you enable GATT support, 'EnableGatt' in
'/etc/bluetooth/main.conf' (usual location).
But using 'bluetoothd' means that will need to use the D-Bus API, which
makes me wonder that having a simple GATT server inside gatttool makes
some sense, for some use cases.
>
> Regards,
>
> john
>
>
> On Mon, Sep 10, 2012 at 2:35 PM, John Tobias <[email protected]> wrote:
> > Hello Guys,
> >
> > I am using pandaboard with USB BLE dongle and an apps in iPhone that
> > do the advertising. I was able to connect to the said device from my
> > pandaboard using the following commands:
> >
> > gatttool -i hci1 -m 27 -I -b 74:xx:xx:xx:xx:xx
> > connect
> >
> > But, I've noticed that after 30 secs, the iPhone dropped off the
> > connection. I am just wondering if anyone here have tried playing with
> > the iPhone using the ble connection?.
> >
> > Regards,
> >
> > John
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers,
--
Vinicius
Just to follow up, I used hcidump and found out an interesting info:
bdaddr 5C:35:3C:72:B2:AF type 1
> HCI Event: Command Status (0x0f) plen 4
LE Create Connection (0x08|0x000d) status 0x00 ncmd 1
> HCI Event: LE Meta Event (0x3e) plen 19
LE Connection Complete
status 0x00 handle 77, role master
bdaddr 5C:35:3C:72:B2:AF (Random)
> ACL data: handle 77 flags 0x02 dlen 11
ATT: Read By Type req (0x08)
start 0x0001, end 0xffff
type-uuid 0x2a00
> HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 77 reason 0x13
Reason: Remote User Terminated Connection
The iPhone was requesting for "ATT: Read By Type req (0x08)" and the
gatttool seems not reponding. So, after 30 secs the iPhone dropped the
connection.
Any idea how the gatttool could respond to the said request?.
Regards,
john
On Mon, Sep 10, 2012 at 2:35 PM, John Tobias <[email protected]> wrote:
> Hello Guys,
>
> I am using pandaboard with USB BLE dongle and an apps in iPhone that
> do the advertising. I was able to connect to the said device from my
> pandaboard using the following commands:
>
> gatttool -i hci1 -m 27 -I -b 74:xx:xx:xx:xx:xx
> connect
>
> But, I've noticed that after 30 secs, the iPhone dropped off the
> connection. I am just wondering if anyone here have tried playing with
> the iPhone using the ble connection?.
>
> Regards,
>
> John
Addition to that, if iPhone to iPhone bluetooth le connection, it
won't drop the connectivity.
Regards,
John
On Mon, Sep 10, 2012 at 2:35 PM, John Tobias <[email protected]> wrote:
> Hello Guys,
>
> I am using pandaboard with USB BLE dongle and an apps in iPhone that
> do the advertising. I was able to connect to the said device from my
> pandaboard using the following commands:
>
> gatttool -i hci1 -m 27 -I -b 74:xx:xx:xx:xx:xx
> connect
>
> But, I've noticed that after 30 secs, the iPhone dropped off the
> connection. I am just wondering if anyone here have tried playing with
> the iPhone using the ble connection?.
>
> Regards,
>
> John