Reconnect on lost connection

kimo

unread,

Aug 18, 2011, 6:47:02 PM8/18/11

to btstack-dev

Hello,

I am trying to make my iPhone reconnect when the connection is lost.
I noticed when the iPhone looses the BT connection, it receives the
hex message 0x73 (on the console I can see "unhandled event : 73"), I
believe this is the way to detect when the connection is lost since
the iphone will not receive any data anymore (but the BT sign is still
"on"). please correct me if I am wrong.

I tried then to reconnect when receiving 0x73 by adding an new case
(let's call it case HCI_EVENT_DIDNT_RECEIVE_DATA). and tried some of
the command that we use to establish a connection, but it's not
working.

Could you please tell me what it is the right message that I should
send to reconnect?

Thank you,
Kimo

Todd Blanchard

unread,

Aug 18, 2011, 7:46:14 PM8/18/11

to btsta...@googlegroups.com

0x73 is a "heartbeat" or keepalive message - it is sent every ten seconds.

however, the question remains - what is the best way to reset the whole shebang and reconnect.

> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To post to this group, send email to btsta...@googlegroups.com.
> To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/btstack-dev?hl=en.
>

Matthias Ringwald

unread,

Aug 19, 2011, 3:28:56 AM8/19/11

to btsta...@googlegroups.com

Hi

most stuff you'll need in an application is defined in include/btstack/hci_cmd.h

(The 0x73 is actually used internally to check if there are baseband connections that don't have any l2cap connection and thus can be closed)

If you get an L2CAP/RFCOMM close event, then the stack considers this connection as gone. If you don't get that, there's a different problem around.

To be honest, I never looked at automatic reconnection. But... the state machines should be/are robust enough that you can just initiate the L2CAP or RFCOMM connection as you did the first time. If this fails, please have a look at the /tmp/hci_dump.pklg (on iOS) and browse that. If you get a valid error case, I'm happy to investigate further.

Best
Matthias

kimo

unread,

Aug 19, 2011, 7:55:25 AM8/19/11

to btstack-dev

Hello,

Thank you for your reply. Should I do something to get L2CAP/RFCOMM
close event, or is the 0x73 supposed to create this event
automatically (not the case right now).

I understood "L2CAP/RFCOMM close event" as
HCI_EVENT_DISCONNECTION_COMPLETE. do I have to wait for such event
before reconnecting ? if yes I see there is an exit(0) in the
implementation. do I have to change it with the code that I used to
initiate the L2CAP or RFCOMM connection in the first time.

is it possible to reconnect on 0x73 message?

Another thing, in my application I am using the BTstack source code (/
include and the state machine) which was released last year. Should I
update it to have a better management of this issue?

Thank you,
Karim

On Aug 19, 9:28 am, Matthias Ringwald <matthias.ringw...@gmail.com>
wrote:

> >> For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.

kimo

unread,

Aug 26, 2011, 8:05:21 AM8/26/11

to btstack-dev

Hello.

Any advices on what I have mentioned in my previous message?

Best Regards
Karim

Matthias Ringwald

unread,

Aug 28, 2011, 2:32:32 PM8/28/11

to btsta...@googlegroups.com

Hi Karim

What version of BTstack are you using. Please use the latest from Cydia together with the current SVN version for the headers.
I've provided full RFCOMM support in May. Before there was a buggy quick & dirty implementation available as example/rfcomm.c. If you're using that, there won't be a RFCOMM close event.

Please try the current examples, e.g. rfcomm-cat to see if you get a consistent connection.

With the current version, ou don't need to do anything special to receive L2CAP/RFCOMM close events.

Best
Matthias

If you don't get such an event, at least BTstack thinks that the connection is intact. How do your

kimo

unread,

Aug 31, 2011, 12:33:48 PM8/31/11

to btstack-dev

Hi Matthias,

Thank you for your reply and your great work.
I was using BTstack version of July 2010 :) . Now I updated it with
the latest version.

I was trying to simulate a bluetooth lost connection to see how it
behaves. I saw that: when it takes a while without receiving any data
packet it will receive an HCI_EVENT_PACKET 0x73 and then there is 2
scenarios:

1) It will receive new Data packets and the connection is re-
established without any code modification.
2) keep showing HCI_EVENT_PACKET 0x73 forever and could not receive
data packet anymore.

At the beginning with the previous implementation of BTstack I thought
that when receiving 0x73 it means that the connection is lost but now
it looks like sometimes I can still receive packets. Do you think this
is normal ?

Best,
Karim

On Aug 28, 8:32 pm, Matthias Ringwald <matthias.ringw...@gmail.com>

Matthias Ringwald

unread,

Sep 1, 2011, 5:58:41 PM9/1/11

to btstack-dev

Hi Karim,

please try to understand: 0x73 is L2CAP_EVENT_TIMEOUT_CHECK

It is used internally and is sent every 10 seconds when there's an active baseband connection. You will get 0x73 also WHILE you're receiving data.

If you're connection goes away, you should receive a RFCOMM_EVENT_CHANNEL_CLOSED. If you don't receive one, then the connection is probably ok, but you don't receive data for other reasons. You can look at and post /tmp/hci_dump.pklg here, which records all packets from/to the Bluetooth module.

Matthias Ringwald

Sent with Replies
http://repliesapp.com

kimo

unread,

Sep 2, 2011, 7:57:53 AM9/2/11

to btstack-dev

Hi Mathias,

Thank you for your reply. I understood now what 0x73 is used for.The
problem that I have is what you mentioned at the end. I don't receive
a RFCOMM_EVENT_CHANNEL_CLOSED. So the connection is probably ok, but I
don't receive data anymore. I will check the /tmp/hci_dump.pklg

Best,
Karim

On Sep 1, 11:58 pm, Matthias Ringwald <matthias.ringw...@gmail.com>
wrote:

> Hi Karim,
>
> please try to understand: 0x73 is L2CAP_EVENT_TIMEOUT_CHECK
> It is used internally and is sent every 10 seconds when there's an active baseband connection. You will get 0x73 also WHILE you're receiving data.
>
> If you're connection goes away, you should receive a RFCOMM_EVENT_CHANNEL_CLOSED. If you don't receive one, then the connection is probably ok, but you don't receive data for other reasons. You can look at and post /tmp/hci_dump.pklg here, which records all packets from/to the Bluetooth module.
> Matthias Ringwald
>
> Sent with Replieshttp://repliesapp.com
>
>
>
>
>
>
>

> > Hi Matthias,
>
> > Thank you for your reply and your great work. I was using BTstack version of July 2010 :) . Now I updated it with the latest version.
>
> > I was trying to simulate a bluetooth lost connection to see how it behaves. I saw that: when it takes a while without receiving any data packet it will receive an HCI_EVENT_PACKET 0x73 and then there is 2 scenarios:
>
> > 1) It will receive new Data packets and the connection is re- established without any code modification. 2) keep showing HCI_EVENT_PACKET 0x73 forever and could not receive data packet anymore.
>
> > At the beginning with the previous implementation of BTstack I thought that when receiving 0x73 it means that the connection is lost but now it looks like sometimes I can still receive packets. Do you think this is normal ?
>
> > Best, Karim
>
> > On Aug 28, 8:32 pm, Matthias Ringwald <<a href="mailto:matthias.ringw...@gmail.com">matthias.ringw...@gmail.com</a>> wrote: > Hi Karim > > What version of BTstack are you using. Please use the latest from Cydia together with the current SVN version for the headers. > I've provided full RFCOMM support in May. Before there was a buggy quick & dirty implementation available as example/rfcomm.c. If you're using that, there won't be a RFCOMM close event. > > Please try the current examples, e.g. rfcomm-cat to see if you get a consistent connection. > > With the current version, ou don't need to do anything special to receive L2CAP/RFCOMM close events. > > Best > Matthias > > If you don't get such an event, at least BTstack thinks that the connection is intact. How do your > On 26.08.2011, at 14:05, kimo wrote: > > > > > > > > > Hello. > > > Any advices on what I have mentioned in my previous message? > > > Best Regards > > Karim > > > On Aug 19, 1:55 pm, kimo <<a href="mailto:kimo...@gmail.com">kimo...@gmail.com</a>> wrote: > >> Hello, > > >> Thank you for your reply. Should I do something to get L2CAP/RFCOMM > >> close event, or is the 0x73 supposed to create this event > >> automatically (not the case right now). > > >> I understood "L2CAP/RFCOMM close event" as > >> HCI_EVENT_DISCONNECTION_COMPLETE. do I have to wait for such event > >> before reconnecting ? if yes I see there is an exit(0) in the > >> implementation. do I have to change it with the code that I used to > >> initiate the L2CAP or RFCOMM connection in the first time. > > >> is it possible to reconnect on 0x73 message? > > >> Another thing, in my application I am using the BTstack source code (/ > >> include and the state machine) which was released last year. Should I > >> update it to have a better management of this issue? > > >> Thank you, > >> Karim > > >> On Aug 19, 9:28 am, Matthias Ringwald <<a href="mailto:matthias.ringw...@gmail.com">matthias.ringw...@gmail.com</a>> > >> wrote: > > >>> Hi > > >>> most stuff you'll need in an application is defined in include/btstack/hci_cmd.h > > >>> (The 0x73 is actually used internally to check if there are baseband connections that don't have any l2cap connection and thus can be closed) > > >>> If you get an L2CAP/RFCOMM close event, then the stack considers this connection as gone. If you don't get that, there's a different problem around. > > >>> To be honest, I never looked at automatic reconnection. But... the state machines should be/are robust enough that you can just initiate the L2CAP or RFCOMM connection as you did the first time. If this fails, please have a look at the /tmp/hci_dump.pklg (on iOS) and browse that. If you get a valid error case, I'm happy to investigate further. > > >>> Best > >>> Matthias > > >>> On 19.08.2011, at 01:46, Todd Blanchard wrote: > > >>>> 0x73 is a "heartbeat" or keepalive message - it is sent every ten seconds. > > >>>> however, the question remains - what is the best way to reset the whole shebang and reconnect. > > >>>> On Aug 18, 2011, at 3:47 PM, kimo wrote: > > >>>>> Hello, > > >>>>> I am trying to make my iPhone reconnect when the connection is lost. > >>>>> I noticed when the iPhone looses the BT connection, it receives the > >>>>> hex message 0x73 (on the console I can see "unhandled event : 73"), I > >>>>> believe this is the way to detect when the connection is lost since > >>>>> the iphone will not receive any data anymore (but the BT sign is still > >>>>> "on"). please correct me if I am wrong. > > >>>>> I tried then to reconnect when receiving 0x73 by adding an new case > >>>>> (let's call it case HCI_EVENT_DIDNT_RECEIVE_DATA). and tried some of > >>>>> the command that we use to establish a connection, but it's not > >>>>> working. > > >>>>> Could you please tell me what it is the right message that I should > >>>>> send to reconnect? > > >>>>> Thank you, > >>>>> Kimo > > >>>>> -- > >>>>> You received this message because you are subscribed to the Google Groups "btstack-dev" group. > >>>>> To post to this group, send email to <a href="mailto:btsta...@googlegroups.com">btsta...@googlegroups.com</a> . > >>>>> To unsubscribe from this group, send email to <a href="mailto:btstack-dev...@googlegroups.com">btstack-dev+unsubscr i...@googlegroups.com</a>. > >>>>> For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en. > > >>>> -- > >>>> You received this message because you are subscribed to the Google Groups "btstack-dev" group. > >>>> To post to this group, send email to <a href="mailto:btsta...@googlegroups.com">btsta...@googlegroups.com</a> . > >>>> To unsubscribe from this group, send email to <a href="mailto:btstack-dev...@googlegroups.com">btstack-dev+unsubscr i...@googlegroups.com</a>. > >>>> For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups "btstack-dev" group. > > To post to this group, send email to <a href="mailto:btsta...@googlegroups.com">btsta...@googlegroups.com</a> . > > To unsubscribe from this group, send email to <a href="mailto:btstack-dev...@googlegroups.com">btstack-dev+unsubscr i...@googlegroups.com</a>. > > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> > -- You received this message because you are subscribed to the Google Groups "btstack-dev" group. To post to this group, send email to <a href="mailto:btsta...@googlegroups.com">btsta...@googlegroups.com</a> . To unsubscribe from this group, send email to <a href="mailto:btstack-dev...@googlegroups.com">btstack-dev+unsubscr i...@googlegroups.com</a>. For more options, visit this group at <a href="http://groups.google.com/group/btstack-dev?hl=en">http://groups.google.com/group/btstack-dev?hl=en</a>.
>
> >

kimo

unread,

Sep 2, 2011, 10:34:11 AM9/2/11

to btstack-dev

Hi Matthias,

sorry to bother you again but it seems that there is no /tmp/
hci_dump.pklg file on the iPhone, I used iphone explorer software to
access the iPhone and the temp folder in the application folder is
empty, am I missing something that I should enable to have the
hci_dump.pklg file created

The config file that I have used to compile all the stuff is (it
enables log info):

// config.h created by configure for BTstack Tue Aug 30 17:43:30 CEST
2011
#define HAVE_TRANSPORT_H4
#define UART_DEVICE "/dev/tty.bluetooth"
#define UART_SPEED 115200
#define USE_BLUETOOL
#define USE_POWERMANAGEMENT
#define USE_SPRINGBOARD
#define USE_COCOA_RUN_LOOP
#define USE_POSIX_RUN_LOOP
#define HAVE_SDP
#define HAVE_RFCOMM
#define REMOTE_DEVICE_DB remote_device_db_iphone
#define HAVE_SO_NOSIGPIPE
#define HAVE_TIME
#define HAVE_MALLOC
#define HAVE_BZERO
#define ENABLE_LOG_INFO
#define ENABLE_LOG_ERROR
#define HCI_ACL_PAYLOAD_SIZE 1021

Regards,
Karim

On Sep 1, 11:58 pm, Matthias Ringwald <matthias.ringw...@gmail.com>
wrote:

> Hi Karim,
>
> please try to understand: 0x73 is L2CAP_EVENT_TIMEOUT_CHECK
> It is used internally and is sent every 10 seconds when there's an active baseband connection. You will get 0x73 also WHILE you're receiving data.
>
> If you're connection goes away, you should receive a RFCOMM_EVENT_CHANNEL_CLOSED. If you don't receive one, then the connection is probably ok, but you don't receive data for other reasons. You can look at and post /tmp/hci_dump.pklg here, which records all packets from/to the Bluetooth module.
> Matthias Ringwald
>

Matthias Ringwald

unread,

Sep 2, 2011, 3:05:19 PM9/2/11

to btsta...@googlegroups.com

"/tmp/hci_dump.pklg" is written by BTdaemon, and it is an absolute path. Hint: it's not in your application sandbox.

I recommend iFile to retrieve it for non-ssh/terminal users

Best
Matthias

> --

> You received this message because you are subscribed to the Google Groups "btstack-dev" group.

> To post to this group, send email to btsta...@googlegroups.com.
> To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/btstack-dev?hl=en.
>

kimo

unread,

Sep 5, 2011, 1:12:30 PM9/5/11

to btstack-dev

Hi Matthias,

Thanks for the Hint ;)

I understood that the timeout is meant to say that the connection is
still working but didn't receive data since 10 seconds, for my, case
sometimes I can still receive data which is normal and sometime the
connection is completely lost without any channel close event. and
finally sometimes (less frequently) I can get
(RFCOMM_EVENT_CHANNEL_CLOSED Basebank connection closed)

in hci_dump there is nothig relevant (only
[19:00:24.810] [HCI EVENT] Undecoded Event Type -
Undecoded Event Type -
Parameter Length: 2 (0x02)
Event type unknown to LogHCIEvent.
[19:00:24.810] [HCI EVENT] 73 02 0C 00
)

I thought then about the HCI_disconnect as a simple channel
disconnect and reconnect doesn't work all the time. I try to
disconnect and reconnect whenever I have L2CAP_EVENT_TIMEOUT_CHECK,
since the bluetooth connection in my use case is supposed to receive
data each 0.5 second.

Fere is what I am doing to reconnect: (in hci_dump it gets stuck at
[18:21:43.692] [HCI EVENT] Connection Complete - status: 0x04 - 00-
A0-96-26-36-B8):

case HCI_EVENT_PACKET:
switch (packet[0]) {
....
case HCI_EVENT_DISCONNECTION_COMPLETE:
if (connectionStatus==2) { //I am receiving this event 2
times that's why I reconnect only in the second time
printf("connecting...\n");
bt_send_cmd(&rfcomm_create_channel, addr,1);
connectionStatus=0;
}
connectionStatus++;
break;

case L2CAP_EVENT_TIMEOUT_CHECK:
bt_send_cmd(&rfcomm_disconnect, rfcomm_channel);
connectionStatus=1;
break;

case RFCOMM_EVENT_CHANNEL_CLOSED:
bt_send_cmd(&hci_disconnect, con_handle_shared, 0x13);
break;

hci_dump (starting from L2CAP_EVENT_TIMEOUT_CHECK)

[18:21:28.103] [HCI EVENT] Undecoded Event Type -
Undecoded Event Type -
Parameter Length: 2 (0x02)
Event type unknown to LogHCIEvent.
[18:21:28.103] [HCI EVENT] 73 02 0C 00
[18:21:28.106] [HCI COMMAND] [F441] Undecoded Testing Command
[F441] Undecoded Testing Command
Opcode: 0xF441 (OGF: 0x3D OCF: 0x41)
[18:21:28.106] [HCI COMMAND] 41 F4 03 01 00 01
[18:21:28.106] [HCI EVENT] Undecoded Event Type -
Undecoded Event Type -
Parameter Length: 2 (0x02)
Event type unknown to LogHCIEvent.
[18:21:28.106] [HCI EVENT] 81 02 01 00
[18:21:28.106] [RFCOMM SEND] DISC for channel 1
DISC for channel 1
RFCOMM Address: 0x0b [EA = 1 CR = 1 D = 0 Server
Channel = 0x01]
RFCOMM Control: 0x53
P/F Bit: ON
RFCOMM Length: 0x0000 (in a 0x01 bytes format)
DISC
RFCOMM FCS: b8
[18:21:28.106] [L2CAP SEND] Data [Handle: 0x000c, Channel ID:
0x0051, Length: 0x0004 (4)]
[18:21:28.107] [HCI EVENT] Undecoded Event Type -
Undecoded Event Type -
Parameter Length: 3 (0x03)
Event type unknown to LogHCIEvent.
[18:21:28.107] [HCI EVENT] 74 03 40 00 01
[18:21:28.111] [HCI COMMAND] [0406] Disconnect - Connection Handle:
0x000C - Reason: 0x13
[0406] Disconnect - Connection Handle: 0x000C - Reason:
0x13
Disconnect
Opcode: 0x0406 (OGF: 0x01 OCF: 0x06)
Parameter Length: 3 (0x03)
Connection Handle: 0x000C
Reason: OtherEndTerminatedConnectionUserEnded (0x13)
[18:21:28.111] [HCI COMMAND] 06 04 03 0C 00 13
[18:21:28.113] [HCI EVENT] Command Status - Disconnect
Command Status - Disconnect
Parameter Length: 4 (0x04)
Status: 0x00 - Success.
Num HCI Command Packets: 0x01
Opcode: 0x0406 (OGF: 0x01 OCF: 0x06) - [Link Control
Commands OGF] Disconnect
No return values
[18:21:28.113] [HCI EVENT] 0F 04 00 01 06 04
[18:21:28.255] [HCI EVENT] Number of Completed Packets - Packets:
0x1 - Connection Handle: 0x000C
Number of Completed Packets - Packets: 0x1 - Connection
Handle: 0x000C
Parameter Length: 5 (0x05)
Number of Handles: 0x01
Connection Handles: 0x000C
Number of Packets: 0x0001
[18:21:28.255] [HCI EVENT] 13 05 01 0C 00 01 00
[18:21:28.256] [HCI EVENT] Disconnection Complete -
ConnectionTerminatedByLocalHost (0x16) - Connection Handle: 0x000C
Disconnection Complete -
ConnectionTerminatedByLocalHost (0x16) - Connection Handle: 0x000C
Parameter Length: 4 (0x04)
Status: 0x00 - Success.
Connection Handle: 0x000C
[18:21:28.256] [HCI EVENT] 05 04 00 0C 00 16
[18:21:28.257] [HCI EVENT] Disconnection Complete -
ConnectionTerminatedByLocalHost (0x16) - Connection Handle: 0x000C
Disconnection Complete -
ConnectionTerminatedByLocalHost (0x16) - Connection Handle: 0x000C
Parameter Length: 3 (0x03)
Status: 0x00 - Success.
Connection Handle: 0x000C
[18:21:28.257] [HCI EVENT] 05 03 00 0C 00 16
[18:21:28.257] [HCI EVENT] Undecoded Event Type -
Undecoded Event Type -
Parameter Length: 2 (0x02)
Event type unknown to LogHCIEvent.
[18:21:28.257] [HCI EVENT] 71 02 40 00
[18:21:28.257] [HCI EVENT] Undecoded Event Type -
Undecoded Event Type -
Parameter Length: 1 (0x01)
Event type unknown to LogHCIEvent.
[18:21:28.257] [HCI EVENT] 61 01 00
[18:21:28.325] [HCI COMMAND] [F440] Undecoded Testing Command
[F440] Undecoded Testing Command
Opcode: 0xF440 (OGF: 0x3D OCF: 0x40)
[18:21:28.325] [HCI COMMAND] 40 F4 07 B8 36 26 96 A0 00 01
[18:21:28.326] [HCI COMMAND] [0405] Create Connection: 00-
A0-96-26-36-B8
[0405] Create Connection: 00-A0-96-26-36-B8
Opcode: 0x0405 (OGF: 0x01 OCF: 0x05)
Parameter Length: 13 (0x0D)
Device Address: 00-A0-96-26-36-B8
Packet Type: 0xCC18
Page Scan Repetition Mode: 0x00
Page Scan Mode: 0x00
Clock Offset: 0x0000
Allow Role Switch: 0x01
[18:21:28.326] [HCI COMMAND] 05 04 0D B8 36 26 96 A0 00 18 CC 00 00
00 00 01
[18:21:28.328] [HCI EVENT] Command Status - Create Connection
Command Status - Create Connection
Parameter Length: 4 (0x04)
Status: 0x00 - Success.
Num HCI Command Packets: 0x01
Opcode: 0x0405 (OGF: 0x01 OCF: 0x05) - [Link Control
Commands OGF] Create Connection
No return values
[18:21:28.328] [HCI EVENT] 0F 04 00 01 05 04
[18:21:43.692] [HCI EVENT] Connection Complete - status: 0x04 - 00-
A0-96-26-36-B8
Connection Complete - status: 0x04 - 00-A0-96-26-36-B8
Parameter Length: 11 (0x0B)
Status: 0x04 - Page Timeout.
[18:21:43.692] [HCI EVENT] 03 0B 04 0D 00 B8 36 26 96 A0 00 01 00
[18:21:43.693] [HCI EVENT] Undecoded Event Type -
Undecoded Event Type -
Parameter Length: 19 (0x13)
Event type unknown to LogHCIEvent.
[18:21:43.693] [HCI EVENT] 70 13 04 B8 36 26 96 A0 00 00 00 03 00 00
00 00 00 FD 03 30 00

Finally would please advice which is the best way to terminate the
application, so that I don't have to reboot the device when the
connection is not established for any reasons?

Best,
Karim

On Sep 2, 9:05 pm, Matthias Ringwald <matthias.ringw...@gmail.com>

kimo

unread,

Sep 6, 2011, 7:39:15 AM9/6/11

to btstack-dev

Hi Matthias,

To avoid using my previous mentioned pseudo-solution for reconnecting,
I would like to better understand how the BTstack manages a
disconnection (or a link connection loss). Usually, in the Bluetooth
spec there is a fixed timeout period after which if there is no packet
between both devices the connection get disconnect (supervision
timeout period), so I am trying to reproduce this on the BTstack but
without a real success.

Here is what I did:

I connected both devices (RFCOM), Then I hide the iPhone from the
second devices for a while and then I put back the iPhone close to the
connected device. I notices 3 different scenarios:

scenario 1 : The iPhone continue to receive data even after severals
successive L2CAP_EVENT_TIMEOUT_CHECK. (depends from an execution to
another )
scenario 2 : The iPhone receive RFCOMM_EVENT_CHANNEL_CLOSED after 2
successive L2CAP_EVENT_TIMEOUT_CHECK (2*10 seconds) (seems to be the
right scenario)
scenario 3 : The iPhone will stop receive data but without a close
event, it will continue to raise L2CAP_EVENT_TIMEOUT_CHECK (The
connection is stuck here)

Based on what I have seen, I could not really find a way to detect a
connection loss since it differs from an execution to another one, Do
you have any idea why I have these different scenarios ? How the
BTstack is managing this part ? when the BTstack is supposed to raise
an RFCOMM_EVENT_CHANNEL_CLOSED event ?

Thank you very much for your help and your support ;)

Best,
Karim

> ...
>
> read more »

Matthias Ringwald

unread,

Sep 9, 2011, 2:13:49 PM9/9/11

to btsta...@googlegroups.com

Hi Karim

On 06.09.2011, at 13:39, kimo wrote:

> Hi Matthias,
>
> To avoid using my previous mentioned pseudo-solution for reconnecting,
> I would like to better understand how the BTstack manages a
> disconnection (or a link connection loss).

If the Bluetooth module detects that a link is gone, it emits a HCI_EVENT_DISCONNECTION_COMPLETE event, upon which BTstack closes all L2CAP channels on that baseband connection, which in turn also closes all RFCOMM multiplexers on that connection and finally closes all RFCOMM connections.

> Usually, in the Bluetooth
> spec there is a fixed timeout period after which if there is no packet
> between both devices the connection get disconnect (supervision
> timeout period), so I am trying to reproduce this on the BTstack but
> without a real success.
>
> Here is what I did:
>
> I connected both devices (RFCOM), Then I hide the iPhone from the
> second devices for a while and then I put back the iPhone close to the
> connected device. I notices 3 different scenarios:
>
> scenario 1 : The iPhone continue to receive data even after severals
> successive L2CAP_EVENT_TIMEOUT_CHECK. (depends from an execution to
> another )
> scenario 2 : The iPhone receive RFCOMM_EVENT_CHANNEL_CLOSED after 2
> successive L2CAP_EVENT_TIMEOUT_CHECK (2*10 seconds) (seems to be the
> right scenario)
> scenario 3 : The iPhone will stop receive data but without a close
> event, it will continue to raise L2CAP_EVENT_TIMEOUT_CHECK (The
> connection is stuck here)
>
> Based on what I have seen, I could not really find a way to detect a
> connection loss since it differs from an execution to another one, Do
> you have any idea why I have these different scenarios ? How the
> BTstack is managing this part ? when the BTstack is supposed to raise
> an RFCOMM_EVENT_CHANNEL_CLOSED event ?
>
> Thank you very much for your help and your support ;)
>

Please check if you get HCI_EVENT_DISCONNECTION_COMPLETE if you remove the remote device.
If you post hci_dump.pklg, please send the binary version. It is much easier to read than all the textual clutter.

Best
Matthias

Reply all

Reply to author

Forward