From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
To: linux-bluetooth@vger.kernel.org
Subject: detecting dead link
Date: Wed, 14 Apr 2010 11:10:48 +0300 [thread overview]
Message-ID: <k2i2d5a2c101004140110s5834b2e6u86290c6466baa723@mail.gmail.com> (raw)
Hi,
It seems that most of the chips take a lot of time to detect that a
link in dead, due to out of range or power off (no hci disconnect),
the most common problem regarding this is when we try to connect SCO:
2010-03-31 18:40:19.975128 < HCI Command: Setup Synchronous Connection
(0x01|0x0028) plen 17
handle 11 voice setting 0x0060
2010-03-31 18:40:19.981780 > HCI Event: Command Status (0x0f) plen 4
Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
2010-03-31 18:40:33.318023 < ACL data: handle 11 flags 0x02 dlen 22
L2CAP(d): cid 0x0073 len 18 [psm 0]
0000: 69 ef 1d 0d 0a 2b 43 49 45 56 3a 20 32 2c 33 0d i....+CIEV: 2,3.
0010: 0a 3e .>
2010-03-31 18:40:33.318145 < HCI Command: Exit Sniff Mode (0x02|0x0004) plen 2
handle 11
2010-03-31 18:40:33.324615 > HCI Event: Command Status (0x0f) plen 4
Exit Sniff Mode (0x02|0x0004) status 0x00 ncmd 1
2010-03-31 18:40:51.207885 < ACL data: handle 11 flags 0x02 dlen 22
L2CAP(d): cid 0x0073 len 18 [psm 0]
0000: 69 ef 1d 0d 0a 2b 43 49 45 56 3a 20 32 2c 32 0d i....+CIEV: 2,2.
0010: 0a 3e .>
2010-03-31 18:40:54.965362 > HCI Event: Max Slots Change (0x1b) plen 3
handle 11 slots 5
2010-03-31 18:40:54.966094 > HCI Event: Synchronous Connect Complete (0x2c)
plen 17
status 0x08 handle 0 bdaddr 00:1E:DC:B3:40:9D type eSCO
Error: Connection Timeout
2010-03-31 18:40:54.968353 > HCI Event: Number of Completed Packets (0x13) plen
5
handle 11 packets 2
2010-03-31 18:40:54.968658 > HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 11 reason 0x08
Reason: Connection Timeout
It took 35 sec to timeout where connections attempt normally only take
5 sec due to page timeout (configurable in main.conf), it is probably
due to being in sniff mode but even after exiting it takes another 20
sec to timeout (probably lmp timeout).
So I was wondering why this timeout is not derived from page timeout,
to me it seems quite obvious that if the connection doesn't complete
within page timeout there is something wrong since that is supposed to
be much faster on an active link, also if that assumption is correct
what would be the impact to have such a logic that takes page timeout
as timeout for any connection attempt in active/dead links dropping
them if the timeout is reached, of course this has to take into
account the user authorization framework/defer setup so it only
timeout if there is no activity in the link.
--
Luiz Augusto von Dentz
Computer Engineer
next reply other threads:[~2010-04-14 8:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-14 8:10 Luiz Augusto von Dentz [this message]
2010-04-14 16:31 ` detecting dead link Mike Tsai
2010-04-14 19:29 ` Luiz Augusto von Dentz
2010-04-14 19:49 ` Mike Tsai
2010-04-14 20:34 ` Luiz Augusto von Dentz
2010-04-14 21:09 ` Mike Tsai
2010-04-16 13:19 ` Luiz Augusto von Dentz
2010-04-15 7:54 ` Andrei Emeltchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=k2i2d5a2c101004140110s5834b2e6u86290c6466baa723@mail.gmail.com \
--to=luiz.dentz@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).