* [PATCH v11 02/10] Bluetooth: Remove unused mask parameter in sco_conn_defer_accept
From: Frédéric Dalleau @ 2013-08-19 12:23 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Frédéric Dalleau, Johan Hedberg
In-Reply-To: <1376915043-24531-1-git-send-email-frederic.dalleau@linux.intel.com>
>From Bluetooth Core v4.0 specification, 7.1.8 Accept Connection Request
Command "When accepting synchronous connection request, the Role
parameter is not used and will be ignored by the BR/EDR Controller."
Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
---
net/bluetooth/sco.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index 9e20a30..05c2fc1 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -651,7 +651,7 @@ static int sco_sock_sendmsg(struct kiocb *iocb, struct socket *sock,
return err;
}
-static void sco_conn_defer_accept(struct hci_conn *conn, int mask)
+static void sco_conn_defer_accept(struct hci_conn *conn)
{
struct hci_dev *hdev = conn->hdev;
@@ -663,11 +663,7 @@ static void sco_conn_defer_accept(struct hci_conn *conn, int mask)
struct hci_cp_accept_conn_req cp;
bacpy(&cp.bdaddr, &conn->dst);
-
- if (lmp_rswitch_capable(hdev) && (mask & HCI_LM_MASTER))
- cp.role = 0x00; /* Become master */
- else
- cp.role = 0x01; /* Remain slave */
+ cp.role = 0x00; /* Ignored */
hci_send_cmd(hdev, HCI_OP_ACCEPT_CONN_REQ, sizeof(cp), &cp);
} else {
@@ -697,7 +693,7 @@ static int sco_sock_recvmsg(struct kiocb *iocb, struct socket *sock,
if (sk->sk_state == BT_CONNECT2 &&
test_bit(BT_SK_DEFER_SETUP, &bt_sk(sk)->flags)) {
- sco_conn_defer_accept(pi->conn->hcon, 0);
+ sco_conn_defer_accept(pi->conn->hcon);
sk->sk_state = BT_CONFIG;
msg->msg_namelen = 0;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v11 01/10] Bluetooth: Use hci_connect_sco directly
From: Frédéric Dalleau @ 2013-08-19 12:23 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Frédéric Dalleau, Johan Hedberg
In-Reply-To: <1376915043-24531-1-git-send-email-frederic.dalleau@linux.intel.com>
hci_connect is a super function for connecting hci protocols. But the
voice_setting parameter (introduced in subsequent patches) is only
needed by SCO and security requirements are not needed for SCO channels.
Thus, it makes sense to have a separate function for SCO.
Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
---
include/net/bluetooth/hci_core.h | 2 ++
net/bluetooth/hci_conn.c | 8 ++------
net/bluetooth/sco.c | 3 +--
3 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index f77885e..307a192 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -584,6 +584,8 @@ struct hci_chan *hci_chan_lookup_handle(struct hci_dev *hdev, __u16 handle);
struct hci_conn *hci_connect(struct hci_dev *hdev, int type, bdaddr_t *dst,
__u8 dst_type, __u8 sec_level, __u8 auth_type);
+struct hci_conn *hci_connect_sco(struct hci_dev *hdev, int type,
+ bdaddr_t *dst);
int hci_conn_check_link_mode(struct hci_conn *conn);
int hci_conn_check_secure(struct hci_conn *conn, __u8 sec_level);
int hci_conn_security(struct hci_conn *conn, __u8 sec_level, __u8 auth_type);
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 6c7f363..5f1f448 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -560,13 +560,12 @@ static struct hci_conn *hci_connect_acl(struct hci_dev *hdev, bdaddr_t *dst,
return acl;
}
-static struct hci_conn *hci_connect_sco(struct hci_dev *hdev, int type,
- bdaddr_t *dst, u8 sec_level, u8 auth_type)
+struct hci_conn *hci_connect_sco(struct hci_dev *hdev, int type, bdaddr_t *dst)
{
struct hci_conn *acl;
struct hci_conn *sco;
- acl = hci_connect_acl(hdev, dst, sec_level, auth_type);
+ acl = hci_connect_acl(hdev, dst, BT_SECURITY_LOW, HCI_AT_NO_BONDING);
if (IS_ERR(acl))
return acl;
@@ -612,9 +611,6 @@ struct hci_conn *hci_connect(struct hci_dev *hdev, int type, bdaddr_t *dst,
return hci_connect_le(hdev, dst, dst_type, sec_level, auth_type);
case ACL_LINK:
return hci_connect_acl(hdev, dst, sec_level, auth_type);
- case SCO_LINK:
- case ESCO_LINK:
- return hci_connect_sco(hdev, type, dst, sec_level, auth_type);
}
return ERR_PTR(-EINVAL);
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index e7bd4ee..9e20a30 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -176,8 +176,7 @@ static int sco_connect(struct sock *sk)
else
type = SCO_LINK;
- hcon = hci_connect(hdev, type, dst, BDADDR_BREDR, BT_SECURITY_LOW,
- HCI_AT_NO_BONDING);
+ hcon = hci_connect_sco(hdev, type, dst);
if (IS_ERR(hcon)) {
err = PTR_ERR(hcon);
goto done;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v11 00/10] sco: SCO socket option for voice_setting
From: Frédéric Dalleau @ 2013-08-19 12:23 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Frédéric Dalleau
Hi,
v11 uses bool instead of int in hci_setup_sync
v10 include contribution from Johan, he reworks fallback handling and fixes
Marcel remarks from v9.
error 0x0d handling moved into a separate patch
v9 is mostly cosmetics. Introduces LMP_TRANSPARENT bit in patch 8/8.
v8 declares BT_VOICE_CVSD_16BIT
Merge T*, S* and D* patches in one
The last patch returns -ECONNABORTED when trying to setup a transparent data
connection if eSCO is not supported.
v7 changes defaults to BT_VOICE_CVSD
Remove mask parameter to sco_conn_defer_accept, it was always 0
check the bits for air codec instead of use constants.
Add S3, S2, S1, D1, D0 settings.
The controller default is now only used to initialize the controller or fill
in the missing information in case of using the old Add_SCO command
v6 fixes style issues
v5 changes interface to SOL_BLUETOOTH, BT_VOICE.
Rework fallback mechanism.
This is the patch version 4 of the socket option for enabling transparent SCO.
As requested by Marcel, this is now a 16-bit voice_setting.
0x0000 is the value corresponding to current behavior.
0x0003 is the value to use for enabling transparent data.
It is easy to allow all possible values from Bluetooth core spec, but I guess
results can be unexpected...
Should we filter allowed values in setsockopt ?
Let me know what you think.
Regards,
Fred
Frédéric Dalleau (10):
Bluetooth: Use hci_connect_sco directly
Bluetooth: Remove unused mask parameter in sco_conn_defer_accept
Bluetooth: Add Bluetooth socket voice option
Bluetooth: Add constants for SCO airmode
Bluetooth: Use voice setting in deferred SCO connection request
Bluetooth: Parameters for outgoing SCO connections
Bluetooth: Add constants and macro declaration for transparent data
Bluetooth: Prevent transparent SCO on older devices
Bluetooth: Handle specific error for SCO connection fallback
Bluetooth: Add SCO connection fallback
include/net/bluetooth/bluetooth.h | 8 ++++
include/net/bluetooth/hci.h | 1 +
include/net/bluetooth/hci_core.h | 10 ++++-
include/net/bluetooth/sco.h | 1 +
net/bluetooth/hci_conn.c | 62 +++++++++++++++++++++++------
net/bluetooth/hci_event.c | 7 ++--
net/bluetooth/sco.c | 77 ++++++++++++++++++++++++++++++-------
7 files changed, 137 insertions(+), 29 deletions(-)
--
1.7.9.5
^ permalink raw reply
* Re: Cannot connect to A2DP audio sink on Bluetooth headset
From: Luiz Augusto von Dentz @ 2013-08-19 10:37 UTC (permalink / raw)
To: Fabrice Delente; +Cc: Liste Linux-Bluetooth
In-Reply-To: <CAK4aCBZgH0uCGz2oaRSaHzRX8p6vK1YrOKG+X+mHAJd33WHmRQ@mail.gmail.com>
Hi Fabrice,
On Mon, Aug 19, 2013 at 12:34 PM, Fabrice Delente <delentef@gmail.com> wrote:
> Hello Luiz,
>
> Are you a gentoo developer ? Because I am stuck with the packages that
> are integrated in this distribution; I have tried with the bluez-5.7
> 'palmer' overlay ebuild, but I have the same problem (no A2DP) and
> blueman expects the bluez-4 API...
>
> The worst is that I had A2DP with bluez-4 2 days ago, and all of a
> sudden no-go... Something broke, but what ?? I just recompiled the
> kernel to hardcode some parts that were modules...
>
> Thanks for you reply anyway!
No, Im not gentoo developer in fact I use Fedora, for controlling the
Bluetooth adapter you can use bluetoothctl but for audio streaming you
really need a newer version of PulseAudio. Take a look at fedora
rawhide they just recently integrate BlueZ 5.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: Cannot connect to A2DP audio sink on Bluetooth headset
From: Fabrice Delente @ 2013-08-19 9:34 UTC (permalink / raw)
Cc: Liste Linux-Bluetooth
In-Reply-To: <CABBYNZKPwpg8=7Ehg86MkSuWxHfK62eEyJ2-XGV==ROF9K3W4w@mail.gmail.com>
Hello Luiz,
Are you a gentoo developer ? Because I am stuck with the packages that
are integrated in this distribution; I have tried with the bluez-5.7
'palmer' overlay ebuild, but I have the same problem (no A2DP) and
blueman expects the bluez-4 API...
The worst is that I had A2DP with bluez-4 2 days ago, and all of a
sudden no-go... Something broke, but what ?? I just recompiled the
kernel to hardcode some parts that were modules...
Thanks for you reply anyway!
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: Remove assignment in if
From: Valentin Ilie @ 2013-08-19 8:41 UTC (permalink / raw)
To: marcel, gustavo, johan.hedberg, Dean_Jenkins
Cc: linux-bluetooth, Valentin Ilie
In-Reply-To: <1376322360-28824-1-git-send-email-valentin.ilie@gmail.com>
On 12 August 2013 18:46, Valentin Ilie <valentin.ilie@gmail.com> wrote:
> Remove assignment in if
Hello,
Can anyone look into this patch? I've corrected it as requested.
Regards,
--
Valentin Ilie
^ permalink raw reply
* Re: Cannot connect to A2DP audio sink on Bluetooth headset
From: Luiz Augusto von Dentz @ 2013-08-19 8:04 UTC (permalink / raw)
To: Fabrice Delente; +Cc: Liste Linux-Bluetooth
In-Reply-To: <CAK4aCBbDAG82YKZLhLg_jTG_dQoDykwimO3a18fb7eGHiXgA0Q@mail.gmail.com>
Hi Fabrice,
On Mon, Aug 19, 2013 at 12:41 AM, Fabrice Delente <delentef@gmail.com> wrote:
> Hello.
>
> I have a headset that used to work with bluez-4.101 (on gentoo), but
> all of a sudden it was impossible to connect, even though I haven't
> changed anything to my configuration...
>
> Anyway, I tried bluez-5.7 through a gentoo overlay, as stock gentoo
> only carries bluez-4.101
>
> Since blueman doesn't work with bluez-5.7, I have tried to connect to
> the sink through bluetoothctl. However, as root, I get this:
>
> [bluetooth]# connect 00:18:91:D0:7A:24
> Attempting to connect to 00:18:91:D0:7A:24
> [CHG] Device 00:18:91:D0:7A:24 Connected: yes
> Failed to connect: org.bluez.Error.Failed
You probably need a newer PulseAudio with BlueZ 5 support, we are
working on a release candidate for PulseAudio 5.0 that should work
properly.
^ permalink raw reply
* Cannot connect to A2DP audio sink on Bluetooth headset
From: Fabrice Delente @ 2013-08-18 21:41 UTC (permalink / raw)
To: Liste Linux-Bluetooth
Hello.
I have a headset that used to work with bluez-4.101 (on gentoo), but
all of a sudden it was impossible to connect, even though I haven't
changed anything to my configuration...
Anyway, I tried bluez-5.7 through a gentoo overlay, as stock gentoo
only carries bluez-4.101
Since blueman doesn't work with bluez-5.7, I have tried to connect to
the sink through bluetoothctl. However, as root, I get this:
[bluetooth]# connect 00:18:91:D0:7A:24
Attempting to connect to 00:18:91:D0:7A:24
[CHG] Device 00:18:91:D0:7A:24 Connected: yes
Failed to connect: org.bluez.Error.Failed
and /var/log/messages shows
Aug 18 23:34:21 smug bluetoothd[25436]: connect error: Connection refused (111)
or
Aug 18 23:35:17 smug bluetoothd[25436]: connect error: Permission denied (13)
Why does this happen? My /etc/bluetooth/audio.conf is
# Configuration file for the audio service
# This section contains options which are not specific to any
# particular interface
[General]
Enable=Sink
#Enable=Source,Sink,Control,Media
#Disable=Headset,Gateway,Socket
# Switch to master role for incoming connections (defaults to true)
Master=true
# If we want to disable support for specific services
# Defaults to supporting all implemented services
#Disable=Gateway,Source,Socket
# SCO routing. Either PCM or HCI (in which case audio is routed to/from ALSA)
# Defaults to HCI
SCORouting=HCI
# Automatically connect both A2DP and HFP/HSP profiles for incoming
# connections. Some headsets that support both profiles will only connect the
# other one automatically so the default setting of true is usually a good
# idea.
AutoConnect=true
#AutoConnect=A2DP
# Headset interface specific options (i.e. options which affect how the audio
# service interacts with remote headset devices)
[Headset]
# Set to true to support HFP, false means only HSP is supported
# Defaults to true
HFP=true
# Maximum number of connected HSP/HFP devices per adapter. Defaults to 1
MaxConnected=1
# Set to true to enable use of fast connectable mode (faster page scanning)
# for HFP when incoming call starts. Default settings are restored after
# call is answered or rejected. Page scan interval is much shorter and page
# scan type changed to interlaced. Such allows faster connection initiated
# by a headset.
FastConnectable=false
# Just an example of potential config options for the other interfaces
#[A2DP]
#SBCSources=1
#MPEG12Sources=0
Thanks.
^ permalink raw reply
* Rfcomm connection error while connecting from android app
From: Tama @ 2013-08-17 8:35 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
In-Reply-To: <1375969749-2097-1-git-send-email-luiz.dentz@gmail.com>
Hello all,
This is my first post to this mailing list. I am new to Bluetooth, I am trying to develop an embedded application with bluetooth using bluez 4.96 stack which would be controled by an adroid application.
My embedded platfrom is IMX28 running linux with Bluex4.96. On this platfrom I have a BCM2070 bluetooth usb dongle. I am running a simple rfcomm server example from this link "http://people.csail.mit.edu/albert/bluez-intro/x502.html". I ran a rfcomm client on ubuntu pc with BCM2070 bluetooth usb dongle and I could talk between the server and client.
Now I am developing an app on android but i am unable to connect to rfcomm server. I even tried running the rfcomm server on ubuntu machine but same result. I have attached the log of hcidump.
> HCI Event: Connect Request (0x04) plen 10
bdaddr D0:E7:82:4A:26:BA class 0x5a011c type ACL
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
bdaddr D0:E7:82:4A:26:BA role 0x00
Role: Master
> HCI Event: Command Status (0x0f) plen 4
Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
> HCI Event: Role Change (0x12) plen 8
status 0x00 bdaddr D0:E7:82:4A:26:BA role 0x00
Role: Master
> HCI Event: Connect Complete (0x03) plen 11
status 0x00 handle 12 bdaddr D0:E7:82:4A:26:BA type ACL encrypt 0x00
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
handle 12
> HCI Event: Command Status (0x0f) plen 4
Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
> HCI Event: Read Remote Supported Features (0x0b) plen 11
status 0x00 handle 12
Features: 0xbf 0x3e 0x8d 0xfe 0xdb 0xff 0x5b 0x87
< HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3
handle 12 page 1
> HCI Event: Command Status (0x0f) plen 4
Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1
> ACL data: handle 12 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 1 scid 0x0040
< ACL data: handle 12 flags 0x00 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 1 status 0
Connection pending - No futher information available
< ACL data: handle 12 flags 0x00 dlen 10
L2CAP(s): Info req: type 2
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 2
> ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x02fb
Flow control mode
Retransmission mode
Enhanced Retransmission mode
Streaming mode
FCS Option
Extended Flow Specification
Fixed Channels
Unicast Connectless Data Reception
< ACL data: handle 12 flags 0x00 dlen 10
L2CAP(s): Info req: type 3
> HCI Event: Max Slots Change (0x1b) plen 3
handle 12 slots 5
> ACL data: handle 12 flags 0x02 dlen 20
L2CAP(s): Info rsp: type 3 result 0
Fixed channel list 0x00000006
L2CAP Signalling Channel
L2CAP Connless
< ACL data: handle 12 flags 0x00 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 0 status 0
Connection successful
< ACL data: handle 12 flags 0x00 dlen 23
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 11
RFC 0x00 (Basic)
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 2
> ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 1691
< ACL data: handle 12 flags 0x00 dlen 18
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4
MTU 1691
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 2
> ACL data: handle 12 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
Success
> ACL data: handle 12 flags 0x02 dlen 31
L2CAP(d): cid 0x0040 len 27 [psm 1]
SDP SS Req: tid 0x26 len 0x16
pat uuid-128 00001101-0000-1000-8000-00805f9b34fb
max 16
cont 00
< ACL data: handle 12 flags 0x00 dlen 14
L2CAP(d): cid 0x0040 len 10 [psm 1]
SDP SS Rsp: tid 0x26 len 0x5
count 0
cont 00
> HCI Event: Read Remote Extended Features (0x23) plen 13
status 0x00 handle 12 page 1 max 2
Features: 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
bdaddr D0:E7:82:4A:26:BA mode 2 clkoffset 0x0000
> ACL data: handle 12 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
< ACL data: handle 12 flags 0x00 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0040
> HCI Event: Command Status (0x0f) plen 4
Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 2
> HCI Event: Remote Name Req Complete (0x07) plen 255
status 0x00 bdaddr D0:E7:82:4A:26:BA name 'A1-810'
> HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 12 reason 0x13
Reason: Remote User Terminated Connection
What could be the reason for termination of a connection. On my host machine i just have rfcomm server running nothing else. Does my rfcomm server needs to have anything else in it.
Can some one please help me to understand what could be causing this issue.
Thanks
Tama
^ permalink raw reply
* Re: [RFC 2/2] Bluetooth: Fix SCO cancelation before ACL is established
From: Marcel Holtmann @ 2013-08-16 19:04 UTC (permalink / raw)
To: Frédéric Dalleau; +Cc: linux-bluetooth
In-Reply-To: <1376501342-30347-2-git-send-email-frederic.dalleau@linux.intel.com>
Hi Fred,
> If SCO socket is closed before ACL connection is established, it is
> possible to cancel the ongoing ACL connection setup. This happen
> automatically when the last reference to the ACL connection is dropped.
> Thus this patch simply drop the ACL connection.
>
> Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com>
> ---
> include/net/bluetooth/hci_core.h | 1 +
> net/bluetooth/hci_conn.c | 10 ++++++++++
> net/bluetooth/sco.c | 4 +++-
> 3 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> index 1000553..a09556a 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -587,6 +587,7 @@ struct hci_conn *hci_connect(struct hci_dev *hdev, int type, bdaddr_t *dst,
> __u8 dst_type, __u8 sec_level, __u8 auth_type);
> struct hci_conn *hci_connect_sco(struct hci_dev *hdev, int type, bdaddr_t *dst,
> __u16 setting);
> +void hci_cancel_sco(struct hci_conn *hconn);
> int hci_conn_check_link_mode(struct hci_conn *conn);
> int hci_conn_check_secure(struct hci_conn *conn, __u8 sec_level);
> int hci_conn_security(struct hci_conn *conn, __u8 sec_level, __u8 auth_type);
> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index d3befac..c3ef7a5 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -639,6 +639,16 @@ struct hci_conn *hci_connect_sco(struct hci_dev *hdev, int type, bdaddr_t *dst,
> return sco;
> }
>
> +void hci_cancel_sco(struct hci_conn *hcon)
> +{
> + struct hci_conn *acl = hcon->link;
> +
> + if (acl && acl->handle == 0)
wouldn't it be better to check acl->state for BT_CONNECTED.
> + hci_conn_drop(acl);
> + else
> + BT_DBG("ACL is already established");
And drop the debug here. Just write a proper comment into the code.
> +}
> +
> /* Create SCO, ACL or LE connection. */
> struct hci_conn *hci_connect(struct hci_dev *hdev, int type, bdaddr_t *dst,
> __u8 dst_type, __u8 sec_level, __u8 auth_type)
> diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
> index e94e654..89491a2 100644
> --- a/net/bluetooth/sco.c
> +++ b/net/bluetooth/sco.c
> @@ -364,8 +364,10 @@ static void __sco_sock_close(struct sock *sk)
> sco_chan_del(sk, ECONNRESET);
> break;
>
> - case BT_CONNECT2:
> case BT_CONNECT:
> + if (sco_pi(sk)->conn->hcon)
> + hci_cancel_sco(sco_pi(sk)->conn->hcon);
> + case BT_CONNECT2:
> case BT_DISCONN:
> sco_chan_del(sk, ECONNRESET);
> break;
Regards
Marcel
^ permalink raw reply
* Re: [RFC 1/2] Bluetooth: Fix SCO connection without socket
From: Marcel Holtmann @ 2013-08-16 19:01 UTC (permalink / raw)
To: Frédéric Dalleau; +Cc: linux-bluetooth
In-Reply-To: <1376501342-30347-1-git-send-email-frederic.dalleau@linux.intel.com>
Hi Fred,
> If SCO socket is closed after ACL connection is established and before
> SCO is established, it is not possible to cancel the ongoing
> synchronous connection setup. When Synchronous Connection Complete
> event is triggered, there will be no socket ready. Drop connection if
> this is the case.
>
> There is a side effect on this patch since it does not distinguish
> between outgoing and incoming sco connections. An incoming SCO
> connection with no acceptor will be dropped.
>
> Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com>
> ---
> include/net/bluetooth/hci_core.h | 10 +++++++---
> net/bluetooth/hci_event.c | 5 +++--
> net/bluetooth/sco.c | 14 +++++++++-----
> 3 files changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> index 1f95e9b..1000553 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -376,7 +376,7 @@ extern int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb,
> u16 flags);
>
> extern int sco_connect_ind(struct hci_dev *hdev, bdaddr_t *bdaddr, __u8 *flags);
> -extern void sco_connect_cfm(struct hci_conn *hcon, __u8 status);
> +extern int sco_connect_cfm(struct hci_conn *hcon, __u8 status);
> extern void sco_disconn_cfm(struct hci_conn *hcon, __u8 reason);
> extern int sco_recv_scodata(struct hci_conn *hcon, struct sk_buff *skb);
>
> @@ -843,8 +843,10 @@ static inline int hci_proto_connect_ind(struct hci_dev *hdev, bdaddr_t *bdaddr,
> }
> }
>
> -static inline void hci_proto_connect_cfm(struct hci_conn *conn, __u8 status)
> +static inline int hci_proto_connect_cfm(struct hci_conn *conn, __u8 status)
> {
> + int canceled = 0;
> +
> switch (conn->type) {
> case ACL_LINK:
> case LE_LINK:
> @@ -853,7 +855,7 @@ static inline void hci_proto_connect_cfm(struct hci_conn *conn, __u8 status)
>
> case SCO_LINK:
> case ESCO_LINK:
> - sco_connect_cfm(conn, status);
> + canceled = sco_connect_cfm(conn, status);
> break;
>
> default:
> @@ -863,6 +865,8 @@ static inline void hci_proto_connect_cfm(struct hci_conn *conn, __u8 status)
>
> if (conn->connect_cfm_cb)
> conn->connect_cfm_cb(conn, status);
> +
> + return canceled;
> }
why are we changing connect_cfm here and not just making connect_ind reject the connection.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v10 10/10] Bluetooth: Add SCO connection fallback
From: Marcel Holtmann @ 2013-08-16 18:55 UTC (permalink / raw)
To: Frédéric Dalleau; +Cc: linux-bluetooth, Johan Hedberg
In-Reply-To: <1376499814-11386-11-git-send-email-frederic.dalleau@linux.intel.com>
Hi Fred,
> When initiating a transparent eSCO connection, make use of T2 settings
> at first try. T2 is the recommended settings from HFP 1.6 WideBand
> Speech. Upon connection failure, try T1 settings.
>
> When CVSD is requested and eSCO is supported, try to establish eSCO
> connection using S3 settings. If it fails, fallback in sequence to S2,
> S1, D1, D0 settings.
>
> To know which setting should be used, conn->attempt is used. It
> indicates the currently ongoing SCO connection attempt and can be used
> as the index for the fallback settings table.
>
> These setting and the fallback order are described in Bluetooth HFP 1.6
> specification p. 101.
>
> Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> include/net/bluetooth/hci_core.h | 2 +-
> net/bluetooth/hci_conn.c | 41 ++++++++++++++++++++++++++++++--------
> net/bluetooth/hci_event.c | 6 +++---
> 3 files changed, 37 insertions(+), 12 deletions(-)
>
> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> index b2bfab8..1f95e9b 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -570,7 +570,7 @@ static inline struct hci_conn *hci_conn_hash_lookup_state(struct hci_dev *hdev,
> }
>
> void hci_disconnect(struct hci_conn *conn, __u8 reason);
> -void hci_setup_sync(struct hci_conn *conn, __u16 handle);
> +int hci_setup_sync(struct hci_conn *conn, __u16 handle);
> void hci_sco_setup(struct hci_conn *conn, __u8 status);
>
> struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst);
> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index c0e56a5..d3befac 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -31,6 +31,24 @@
> #include <net/bluetooth/a2mp.h>
> #include <net/bluetooth/smp.h>
>
> +struct sco_param {
> + u16 pkt_type;
> + u16 max_latency;
> +};
> +
> +static const struct sco_param sco_param_cvsd[] = {
> + { EDR_ESCO_MASK & ~ESCO_2EV3, 0x000a }, /* S3 */
> + { EDR_ESCO_MASK & ~ESCO_2EV3, 0x0007 }, /* S2 */
> + { EDR_ESCO_MASK | ESCO_EV3, 0x0007 }, /* S1 */
> + { EDR_ESCO_MASK | ESCO_HV3, 0xffff }, /* D1 */
> + { EDR_ESCO_MASK | ESCO_HV1, 0xffff }, /* D0 */
> +};
> +
> +static const struct sco_param sco_param_wideband[] = {
> + { EDR_ESCO_MASK & ~ESCO_2EV3, 0x000d }, /* T2 */
> + { EDR_ESCO_MASK | ESCO_EV3, 0x0008 }, /* T1 */
> +};
> +
> static void hci_le_create_connection(struct hci_conn *conn)
> {
> struct hci_dev *hdev = conn->hdev;
> @@ -172,10 +190,11 @@ static void hci_add_sco(struct hci_conn *conn, __u16 handle)
> hci_send_cmd(hdev, HCI_OP_ADD_SCO, sizeof(cp), &cp);
> }
>
> -void hci_setup_sync(struct hci_conn *conn, __u16 handle)
> +int hci_setup_sync(struct hci_conn *conn, __u16 handle)
> {
> struct hci_dev *hdev = conn->hdev;
> struct hci_cp_setup_sync_conn cp;
> + const struct sco_param *param;
>
> BT_DBG("hcon %p", conn);
>
> @@ -192,19 +211,25 @@ void hci_setup_sync(struct hci_conn *conn, __u16 handle)
>
> switch (conn->setting & SCO_AIRMODE_MASK) {
> case SCO_AIRMODE_TRANSP:
> - cp.pkt_type = __constant_cpu_to_le16(EDR_ESCO_MASK &
> - ~ESCO_2EV3);
> - cp.max_latency = __constant_cpu_to_le16(0x000d);
> + if (conn->attempt > ARRAY_SIZE(sco_param_wideband))
> + return -ECONNREFUSED;
> cp.retrans_effort = 0x02;
> + param = &sco_param_wideband[conn->attempt - 1];
> break;
> case SCO_AIRMODE_CVSD:
> - cp.pkt_type = cpu_to_le16(conn->pkt_type);
> - cp.max_latency = __constant_cpu_to_le16(0xffff);
> - cp.retrans_effort = 0xff;
> + if (conn->attempt > ARRAY_SIZE(sco_param_cvsd))
> + return -ECONNREFUSED;
> + cp.retrans_effort = 0x01;
> + param = &sco_param_cvsd[conn->attempt - 1];
> break;
> + default:
> + return -EINVAL;
> }
>
> - hci_send_cmd(hdev, HCI_OP_SETUP_SYNC_CONN, sizeof(cp), &cp);
> + cp.pkt_type = __cpu_to_le16(param->pkt_type);
> + cp.max_latency = __cpu_to_le16(param->max_latency);
> +
> + return hci_send_cmd(hdev, HCI_OP_SETUP_SYNC_CONN, sizeof(cp), &cp);
> }
since we are not using the return value for anything, I would propose that you use a bool here and just give true for success and false for failure. And since hci_send_cmd can only fail on skb allocation, you can just do this:
if (hci_send_cmd(…) < 0)
return false;
return true;
>
> void hci_le_conn_update(struct hci_conn *conn, u16 min, u16 max,
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index a8bb7bb..491c5fb 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -2909,11 +2909,11 @@ static void hci_sync_conn_complete_evt(struct hci_dev *hdev,
> case 0x1c: /* SCO interval rejected */
> case 0x1a: /* Unsupported Remote Feature */
> case 0x1f: /* Unspecified error */
> - if (conn->out && conn->attempt < 2) {
> + if (conn->out) {
> conn->pkt_type = (hdev->esco_type & SCO_ESCO_MASK) |
> (hdev->esco_type & EDR_ESCO_MASK);
> - hci_setup_sync(conn, conn->link->handle);
> - goto unlock;
> + if (hci_setup_sync(conn, conn->link->handle) == 0)
> + goto unlock;
And this one becomes this then:
if (hci_setup_sync(…))
goto unlock;
> }
> /* fall through */
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v10 09/10] Bluetooth: Handle specific error for SCO connection fallback
From: Marcel Holtmann @ 2013-08-16 18:48 UTC (permalink / raw)
To: Frédéric Dalleau; +Cc: linux-bluetooth
In-Reply-To: <1376499814-11386-10-git-send-email-frederic.dalleau@linux.intel.com>
Hi Fred,
> Synchronous Connection Complete event can return error "Connection
> Rejected due to Limited resources (0x10)".
> Handling this error is required for SCO connection fallback. This error
> happens when the server tried to accept the connection but failed to
> negotiate settings.
> This error code has been verified experimentally by sending a T2 request
> to a T1 only SCO listener.
>
> Client dump follows :
>
> < HCI Command (0x01|0x0028) plen 17 [hci0] 3.696064
> Handle: 12
> Transmit bandwidth: 8000
> Receive bandwidth: 8000
> Max latency: 13
> Setting: 0x0003
> Retransmission effort: Optimize for link quality (0x02)
> Packet type: 0x0380
>> HCI Event (0x0f) plen 4 [hci0] 3.697034
> Setup Synchronous Connection (0x01|0x0028) ncmd 1
> Status: Success (0x00)
>> HCI Event (0x2c) plen 17 [hci0] 3.736059
> Status: Connection Rejected due to Limited Resources (0x0d)
> Handle: 0
> Address: xx:xx:xx:xx:xx:AB (OUI 70-F3-95)
> Link type: eSCO (0x02)
> Transmission interval: 0x0c
> Retransmission window: 0x06
> RX packet length: 60
> TX packet length: 60
> Air mode: Transparent (0x03)
>
> Server dump follows :
>
>> HCI Event (0x04) plen 10 [hci0] 4.741513
> Address: xx:xx:xx:xx:xx:D9 (OUI 20-68-9D)
> Class: 0x620100
> Major class: Computer (desktop, notebook, PDA, organizers)
> Minor class: Uncategorized, code for device not assigned
> Networking (LAN, Ad hoc)
> Audio (Speaker, Microphone, Headset)
> Telephony (Cordless telephony, Modem, Headset)
> Link type: eSCO (0x02)
> < HCI Command (0x01|0x0029) plen 21 [hci0] 4.743269
> Address: xx:xx:xx:xx:xx:D9 (OUI 20-68-9D)
> Transmit bandwidth: 8000
> Receive bandwidth: 8000
> Max latency: 13
> Setting: 0x0003
> Retransmission effort: Optimize for link quality (0x02)
> Packet type: 0x03c1
>> HCI Event (0x0f) plen 4 [hci0] 4.745517
> Accept Synchronous Connection (0x01|0x0029) ncmd 1
> Status: Success (0x00)
>> HCI Event (0x2c) plen 17 [hci0] 4.749508
> Status: Connection Rejected due to Limited Resources (0x0d)
> Handle: 0
> Address: xx:xx:xx:xx:xx:D9 (OUI 20-68-9D)
> Link type: eSCO (0x02)
> Transmission interval: 0x0c
> Retransmission window: 0x06
> RX packet length: 60
> TX packet length: 60
> Air mode: Transparent (0x03)
>
> Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com>
> ---
> net/bluetooth/hci_event.c | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v10 06/10] Bluetooth: Parameters for outgoing SCO connections
From: Marcel Holtmann @ 2013-08-16 18:47 UTC (permalink / raw)
To: Frédéric Dalleau; +Cc: linux-bluetooth, Johan Hedberg
In-Reply-To: <1376499814-11386-7-git-send-email-frederic.dalleau@linux.intel.com>
Hi Fred,
> In order to establish a transparent SCO connection, the correct settings
> must be specified in the Setup Synchronous Connection request. For that,
> a setting field is added to ACL connection data to set up the desired
> parameters. The patch also removes usage of hdev->voice_setting in CVSD
> connection and makes use of T2 parameters for transparent data.
>
> Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> include/net/bluetooth/hci_core.h | 5 +++--
> net/bluetooth/hci_conn.c | 24 +++++++++++++++++++-----
> net/bluetooth/sco.c | 2 +-
> 3 files changed, 23 insertions(+), 8 deletions(-)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v10 05/10] Bluetooth: Use voice setting in deferred SCO connection request
From: Marcel Holtmann @ 2013-08-16 18:47 UTC (permalink / raw)
To: Frédéric Dalleau; +Cc: linux-bluetooth, Johan Hedberg
In-Reply-To: <1376499814-11386-6-git-send-email-frederic.dalleau@linux.intel.com>
Hi Fred,
> When an incoming eSCO connection is requested, check the selected voice
> setting and reply appropriately. Voice setting should have been
> negotiated previously. For example, in case of HFP, the codec is
> negotiated using AT commands on the RFCOMM channel. This patch only
> changes replies for socket with deferred setup enabled.
>
> Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> net/bluetooth/sco.c | 22 +++++++++++++++++-----
> 1 file changed, 17 insertions(+), 5 deletions(-)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v10 08/10] Bluetooth: Prevent transparent SCO on older devices
From: Marcel Holtmann @ 2013-08-16 18:45 UTC (permalink / raw)
To: Frédéric Dalleau; +Cc: linux-bluetooth, Johan Hedberg
In-Reply-To: <1376499814-11386-9-git-send-email-frederic.dalleau@linux.intel.com>
Hi Fred,
> Older Bluetooth devices may not support Setup Synchronous Connection or
> SCO transparent data. This is indicated by the corresponding LMP feature
> bits. It is not possible to know if the adapter support these features
> before setting BT_VOICE option since the socket is not bound to an
> adapter. An adapter can also be added after the socket is created. The
> socket can be bound to an address before adapter is plugged in.
>
> Thus, on a such adapters, if user request BT_VOICE_TRANSPARENT, outgoing
> connections fail on connect() and returns -EOPNOTSUPP. Incoming
> connections do not fail. However, they should only be allowed depending
> on what was specified in Write_Voice_Settings command.
>
> EOPNOTSUPP is choosen because connect() system call is failing after
> selecting route but before any connection attempt.
>
> Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> net/bluetooth/sco.c | 6 ++++++
> 1 file changed, 6 insertions(+)
lets go with EOPNOTSUPP.
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* RFCOMM Server over D-Bus
From: Christoph Reiter @ 2013-08-16 17:03 UTC (permalink / raw)
To: linux-bluetooth
Hi,
I'm trying to write a simple RFCOMM server with BlueZ5 and D-Bus. I've
registered a default agent over D-Bus to confirm any RequestAuthorization
events and a profile object for handling incoming connections.
The profile options are the following:
opts = {
"AutoConnect": True,
"Name": "FoobarService",
"Role": "server",
"Channel": dbus.UInt16(17),
"RequireAuthentication": False,
"RequireAuthorization": False,
}
The client discovers my service, connects and sends data which I can see
with btmon on the server.
My problem is now that my Profile object never gets called.
What am I doing wrong?
regards
----------------------------------
bluetoothd logs (00:02:72:3F:3F:11 is the client trying to connect):
bluetoothd[32663]: src/adapter.c:new_link_key_callback() hci1 new key
for 00:02:72:3F:3F:11 type 4 pin_len 0
bluetoothd[32663]: src/device.c:device_bonding_complete() bonding
(nil) status 0x00
bluetoothd[32663]: src/device.c:device_bonding_complete() setting
timer for reverse service discovery
bluetoothd[32663]: src/adapter.c:resume_discovery()
bluetoothd[32663]: src/device.c:device_probe_profiles() Probing
profiles for device 00:02:72:3F:3F:11
bluetoothd[32663]: FoobarService service not found for device 00:02:72:3F:3F:11
bluetoothd[32663]: src/device.c:device_probe_profiles() Probing
profiles for device 00:02:72:3F:3F:11
The stack trace at "service not found":
#4 0x000000000045f6e7 in create_conn (server=server@entry=0x6d2bf0,
io=io@entry=0x6cf2d0, dst=dst@entry=0x7fffffffe310,
src=0x7fffffffe300) at src/profile.c:1065
#5 0x000000000045f780 in ext_direct_connect (io=0x6cf2d0, err=0x0,
user_data=0x6d2bf0) at src/profile.c:1192
#6 0x0000000000445f44 in server_cb (io=0x6cf2d0, cond=(G_IO_IN |
G_IO_OUT | G_IO_HUP | G_IO_NVAL | unknown: 19520), user_data=0x6ceef0)
at btio/btio.c:264
#7 0x00007ffff7b23ea6 in g_main_dispatch (context=0x6c20a0) at
/tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3054
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix removing Long Term Key
From: Vinicius Costa Gomes @ 2013-08-16 3:29 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: BlueZ development
In-Reply-To: <CAKT1EBeGHzSTZEPr6Ap=h2u5TyGy2wGxyXP2FfUCT2dKQQpK8Q@mail.gmail.com>
Hi Claudio,
On 17:27 Thu 25 Jul, Claudio Takahasi wrote:
> Hi Vinicius:
>
> On Thu, Jul 25, 2013 at 4:34 PM, Claudio Takahasi
> <claudio.takahasi@openbossa.org> wrote:
> > This patch fixes authentication failure on LE link re-connection when
> > BlueZ acts as slave (peripheral). LTK is removed from the internal list
> > after its first use causing PIN or Key missing reply when re-connecting
> > the link. The LE Long Term Key Request event indicates that the master
> > is attempting to encrypt or re-encrypt the link.
> >
> > Pre-condition: BlueZ host paired and running as slave.
> > How to reproduce(master):
> > 1) Establish an ACL LE encrypted link
> > 2) Disconnect the link
> > 3) Try to re-establish the ACL LE encrypted link (fails)
> >
> >> HCI Event: LE Meta Event (0x3e) plen 19
> > LE Connection Complete (0x01)
> > Status: Success (0x00)
> > Handle: 64
> > Role: Slave (0x01)
> > ...
> > @ Device Connected: 00:02:72:DC:29:C9 (1) flags 0x0000
> >> HCI Event: LE Meta Event (0x3e) plen 13
> > LE Long Term Key Request (0x05)
> > Handle: 64
> > Random number: 875be18439d9aa37
> > Encryption diversifier: 0x76ed
> > < HCI Command: LE Long Term Key Request Reply (0x08|0x001a) plen 18
> > Handle: 64
> > Long term key: 2aa531db2fce9f00a0569c7d23d17409
> >> HCI Event: Command Complete (0x0e) plen 6
> > LE Long Term Key Request Reply (0x08|0x001a) ncmd 1
> > Status: Success (0x00)
> > Handle: 64
> >> HCI Event: Encryption Change (0x08) plen 4
> > Status: Success (0x00)
> > Handle: 64
> > Encryption: Enabled with AES-CCM (0x01)
> > ...
> > @ Device Disconnected: 00:02:72:DC:29:C9 (1) reason 3
> > < HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1
> > Advertising: Enabled (0x01)
> >> HCI Event: Command Complete (0x0e) plen 4
> > LE Set Advertise Enable (0x08|0x000a) ncmd 1
> > Status: Success (0x00)
> >> HCI Event: LE Meta Event (0x3e) plen 19
> > LE Connection Complete (0x01)
> > Status: Success (0x00)
> > Handle: 64
> > Role: Slave (0x01)
> > ...
> > @ Device Connected: 00:02:72:DC:29:C9 (1) flags 0x0000
> >> HCI Event: LE Meta Event (0x3e) plen 13
> > LE Long Term Key Request (0x05)
> > Handle: 64
> > Random number: 875be18439d9aa37
> > Encryption diversifier: 0x76ed
> > < HCI Command: LE Long Term Key Request Neg Reply (0x08|0x001b) plen 2
> > Handle: 64
> >> HCI Event: Command Complete (0x0e) plen 6
> > LE Long Term Key Request Neg Reply (0x08|0x001b) ncmd 1
> > Status: Success (0x00)
> > Handle: 64
> >> HCI Event: Disconnect Complete (0x05) plen 4
> > Status: Success (0x00)
> > Handle: 64
> > Reason: Authentication Failure (0x05)
> > @ Device Disconnected: 00:02:72:DC:29:C9 (1) reason 0
> >
> > Signed-off-by: Claudio Takahasi <claudio.takahasi@openbossa.org>
> > ---
> > net/bluetooth/hci_event.c | 8 +++++++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> > index ae78738..124a5e2 100644
> > --- a/net/bluetooth/hci_event.c
> > +++ b/net/bluetooth/hci_event.c
> > @@ -3558,7 +3558,13 @@ static void hci_le_ltk_request_evt(struct hci_dev *hdev, struct sk_buff *skb)
> >
> > hci_send_cmd(hdev, HCI_OP_LE_LTK_REPLY, sizeof(cp), &cp);
> >
> > - if (ltk->type & HCI_SMP_STK) {
> > + /*
> > + * Ref. Bluetooth Core SPEC pages 1975 and 2004. STK is a temporary
> > + * key used to encrypt a connection following pairing. It is used
> > + * during the Encrypted Session Setup to distribute the keys. Later,
> > + * security can be re-established using a distributed LTK.
> > + */
> > + if (ltk->type == HCI_SMP_STK_SLAVE) {
The correct one should be something like this (not tested):
if (ltk->type == HCI_SMP_STK || ltk->type == HCI_SMP_STK_SLAVE) {
> > list_del(<k->list);
> > kfree(ltk);
> > }
> > --
> > 1.7.11.7
> >
>
> Do you see another alternative?
> Is it feasible to avoid adding the STK in the list without adding a
> complex logic?
At least I couldn't find a way. This question made me think about another
problem, if the connection drops between the STK generation and its use to
encrypt the link, it's going to stay there forever.
>
> Regards,
> Claudio
Cheers,
--
Vinicius
^ permalink raw reply
* Re: [PATCH 1/1 v4] Bluetooth: Fix ACL alive for long in case of non pariable devices
From: Syam Sidhardhan @ 2013-08-15 14:18 UTC (permalink / raw)
To: User Name; +Cc: Syam Sidhardhan
In-Reply-To: <1375721952-3601-1-git-send-email-syamsidhardh@gmail.com>
Hi,
On Mon, Aug 5, 2013 at 10:29 PM, Syam Sidhardhan <syamsidhardh@gmail.com> wrote:
> From: Syam Sidhardhan <s.syam@samsung.com>
>
> For certain devices (ex: HID mouse), support for authentication,
> pairing and bonding is optional. For such devices, the ACL alive
> for too long after the L2CAP disconnection.
>
> To avoid the ACL alive for too long after L2CAP disconnection, reset the
> ACL disconnect timeout back to HCI_DISCONN_TIMEOUT during L2CAP connect.
>
> While merging the commit id:a9ea3ed9b71cc3271dd59e76f65748adcaa76422
> this issue might have introduced.
>
> Hcidump info:
> sh-4.1# /opt/hcidump -Xt
> HCI sniffer - Bluetooth packet analyzer ver 2.4
> device: hci0 snap_len: 1500 filter: 0xffffffff
> 2013-08-05 16:48:47.847053 > HCI Event: Connect Request (0x04) plen 10
> bdaddr 00:12:A1:65:E5:B2 class 0x002580 type ACL
> 2013-08-05 16:48:47.847310 < HCI Command: Accept Connection Request (0x01
> |0x0009) plen 7
> bdaddr 00:12:A1:65:E5:B2 role 0x00
> Role: Master
> 2013-08-05 16:48:47.848436 > HCI Event: Command Status (0x0f) plen 4
> Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
> 2013-08-05 16:48:48.007120 > HCI Event: Role Change (0x12) plen 8
> status 0x00 bdaddr 00:12:A1:65:E5:B2 role 0x00
> Role: Master
> 2013-08-05 16:48:48.050475 > HCI Event: Connect Complete (0x03) plen 11
> status 0x00 handle 12 bdaddr 00:12:A1:65:E5:B2 type ACL encrypt 0x00
> 2013-08-05 16:48:48.051235 < HCI Command: Read Remote Supported Features
> (0x01|0x001b) plen 2
> handle 12
> 2013-08-05 16:48:48.051691 > HCI Event: Command Status (0x0f) plen 4
> Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
> 2013-08-05 16:48:48.051864 > HCI Event: Read Remote Supported Features
> (0x0b) plen 11
> status 0x00 handle 12
> Features: 0xbc 0x02 0x04 0x38 0x08 0x00 0x00 0x00
> 2013-08-05 16:48:48.051899 < HCI Command: Remote Name Request (0x01|
> 0x0019) plen 10
> bdaddr 00:12:A1:65:E5:B2 mode 2 clkoffset 0x0000
> 2013-08-05 16:48:48.052530 > HCI Event: Command Status (0x0f) plen 4
> Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
> 2013-08-05 16:48:48.056407 > ACL data: handle 12 flags 0x02 dlen 12
> L2CAP(s): Connect req: psm 17 scid 0x0049
> 2013-08-05 16:48:48.056492 < ACL data: handle 12 flags 0x00 dlen 16
> L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0049 result 1 status 0
> Connection pending - No futher information available
> 2013-08-05 16:48:48.056510 < ACL data: handle 12 flags 0x00 dlen 10
> L2CAP(s): Info req: type 2
> 2013-08-05 16:48:48.061404 > HCI Event: Number of Completed Packets
> (0x13) plen 5
> handle 12 packets 2
> 2013-08-05 16:48:48.064019 > ACL data: handle 12 flags 0x02 dlen 16
> L2CAP(s): Info rsp: type 2 result 0
> Extended feature mask 0x0004
> Bi-directional QoS
> 2013-08-05 16:48:48.064059 < ACL data: handle 12 flags 0x00 dlen 16
> L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0049 result 0 status 0
> Connection successful
> 2013-08-05 16:48:48.064071 < ACL data: handle 12 flags 0x00 dlen 12
> L2CAP(s): Config req: dcid 0x0049 flags 0x00 clen 0
> 2013-08-05 16:48:48.067220 > HCI Event: Remote Name Req Complete (0x07)
> plen 255
> status 0x00 bdaddr 00:12:A1:65:E5:B2 name 'Bluetooth Mouse'
> 2013-08-05 16:48:48.067627 > HCI Event: Number of Completed Packets
> (0x13) plen 5
> handle 12 packets 2
> 2013-08-05 16:48:48.070114 > ACL data: handle 12 flags 0x02 dlen 16
> L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
> MTU 185
> 2013-08-05 16:48:48.070148 < ACL data: handle 12 flags 0x00 dlen 18
> L2CAP(s): Config rsp: scid 0x0049 flags 0x00 result 0 clen 4
> MTU 185
> 2013-08-05 16:48:48.072642 > ACL data: handle 12 flags 0x02 dlen 18
> L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4
> MTU 185
> 2013-08-05 16:48:48.075123 > ACL data: handle 12 flags 0x02 dlen 12
> L2CAP(s): Connect req: psm 19 scid 0x004a
> 2013-08-05 16:48:48.075196 < ACL data: handle 12 flags 0x00 dlen 16
> L2CAP(s): Connect rsp: dcid 0x0041 scid 0x004a result 1 status 2
> Connection pending - Authorization pending
> 2013-08-05 16:48:48.075364 < ACL data: handle 12 flags 0x00 dlen 16
> L2CAP(s): Connect rsp: dcid 0x0041 scid 0x004a result 0 status 0
> Connection successful
> 2013-08-05 16:48:48.075403 < ACL data: handle 12 flags 0x00 dlen 12
> L2CAP(s): Config req: dcid 0x004a flags 0x00 clen 0
> 2013-08-05 16:48:48.077633 > HCI Event: Number of Completed Packets
> (0x13) plen 5
> handle 12 packets 2
> 2013-08-05 16:48:48.080127 > HCI Event: Number of Completed Packets
> (0x13) plen 5
> handle 12 packets 2
> 2013-08-05 16:48:48.081355 > ACL data: handle 12 flags 0x02 dlen 16
> L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 4
> MTU 185
> 2013-08-05 16:48:48.081402 < ACL data: handle 12 flags 0x00 dlen 18
> L2CAP(s): Config rsp: scid 0x004a flags 0x00 result 0 clen 4
> MTU 185
> 2013-08-05 16:48:48.082633 > ACL data: handle 12 flags 0x02 dlen 18
> L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 4
> MTU 185
> 2013-08-05 16:48:48.084838 < ACL data: handle 12 flags 0x00 dlen 12
> L2CAP(d): cid 0x004a len 8 [psm 19]
> HIDP: Data: Output report
> 0000: 02 00 00 00 00 00 00 .......
> ...
> ...
>
> 2013-08-05 16:49:00.894129 < ACL data: handle 12 flags 0x00 dlen 12
> L2CAP(s): Disconn req: dcid 0x004a scid 0x0041
> 2013-08-05 16:49:00.894195 < HCI Command: Exit Sniff Mode (0x02|0x0004)
> plen 2
> handle 12
> 2013-08-05 16:49:00.894269 < ACL data: handle 12 flags 0x00 dlen 12
> L2CAP(s): Disconn req: dcid 0x0049 scid 0x0040
> 2013-08-05 16:49:00.895645 > HCI Event: Command Status (0x0f) plen 4
> Exit Sniff Mode (0x02|0x0004) status 0x00 ncmd 1
> 2013-08-05 16:49:00.934391 > HCI Event: Mode Change (0x14) plen 6
> status 0x00 handle 12 mode 0x00 interval 0
> Mode: Active
> 2013-08-05 16:49:00.936592 > HCI Event: Number of Completed Packets
> (0x13) plen 5
> handle 12 packets 2
> 2013-08-05 16:49:00.951577 > ACL data: handle 12 flags 0x02 dlen 12
> L2CAP(s): Disconn rsp: dcid 0x004a scid 0x0041
> 2013-08-05 16:49:00.952820 > ACL data: handle 12 flags 0x02 dlen 12
> L2CAP(s): Disconn rsp: dcid 0x0049 scid 0x0040
> 2013-08-05 16:49:00.969165 > HCI Event: Mode Change (0x14) plen 6
> status 0x00 handle 12 mode 0x02 interval 50
> Mode: Sniff
>
> 2013-08-05 16:49:48.175533 > HCI Event: Mode Change (0x14) plen 6
> status 0x00 handle 12 mode 0x00 interval 0
> Mode: Active
> 2013-08-05 16:49:48.219045 > HCI Event: Mode Change (0x14) plen 6
> status 0x00 handle 12 mode 0x02 interval 108
> Mode: Sniff
>
> 2013-08-05 16:51:00.968209 < HCI Command: Disconnect (0x01|0x0006) plen 3
> handle 12 reason 0x13
> Reason: Remote User Terminated Connection
> 2013-08-05 16:51:00.969056 > HCI Event: Command Status (0x0f) plen 4
> Disconnect (0x01|0x0006) status 0x00 ncmd 1
> 2013-08-05 16:51:01.013495 > HCI Event: Mode Change (0x14) plen 6
> status 0x00 handle 12 mode 0x00 interval 0
> Mode: Active
> 2013-08-05 16:51:01.073777 > HCI Event: Disconn Complete (0x05) plen 4
> status 0x00 handle 12 reason 0x16
> Reason: Connection Terminated by Local Host
>
> ========================= Conn status =================================
> sh-4.1# date; hcitool con
> Mon Aug 5 16:49:16 KST 2013
> Connections:
> > ACL 00:12:A1:65:E5:B2 handle 12 state 1 lm MASTER
> sh-4.1# date; hcitool con
> Mon Aug 5 16:50:32 KST 2013
> Connections:
> > ACL 00:12:A1:65:E5:B2 handle 12 state 1 lm MASTER
> sh-4.1# date; hcitool con
> Mon Aug 5 16:50:59 KST 2013
> Connections:
> > ACL 00:12:A1:65:E5:B2 handle 12 state 1 lm MASTER
> sh-4.1# date; hcitool con
> Mon Aug 5 16:51:01 KST 2013
> Connections:
> sh-4.1#
>
> ============================ After fix ================================
>
> 2013-08-05 16:57:35.986648 < ACL data: handle 11 flags 0x00 dlen 12
> L2CAP(s): Disconn req: dcid 0x004c scid 0x0041
> 2013-08-05 16:57:35.986713 < HCI Command: Exit Sniff Mode (0x02|0x0004)
> plen 2
> handle 11
> 2013-08-05 16:57:35.986785 < ACL data: handle 11 flags 0x00 dlen 12
> L2CAP(s): Disconn req: dcid 0x004b scid 0x0040
> 2013-08-05 16:57:35.988110 > HCI Event: Command Status (0x0f) plen 4
> Exit Sniff Mode (0x02|0x0004) status 0x00 ncmd 1
> 2013-08-05 16:57:36.030714 > HCI Event: Mode Change (0x14) plen 6
> status 0x00 handle 11 mode 0x00 interval 0
> Mode: Active
> 2013-08-05 16:57:36.032950 > HCI Event: Number of Completed Packets
> (0x13) plen 5
> handle 11 packets 2
> 2013-08-05 16:57:36.047926 > ACL data: handle 11 flags 0x02 dlen 12
> L2CAP(s): Disconn rsp: dcid 0x004c scid 0x0041
> 2013-08-05 16:57:36.049200 > ACL data: handle 11 flags 0x02 dlen 12
> L2CAP(s): Disconn rsp: dcid 0x004b scid 0x0040
> 2013-08-05 16:57:36.065509 > HCI Event: Mode Change (0x14) plen 6
> status 0x00 handle 11 mode 0x02 interval 50
> Mode: Sniff
>
> 2013-08-05 16:57:40.052006 < HCI Command: Disconnect (0x01|0x0006) plen 3
> handle 11 reason 0x13
> Reason: Remote User Terminated Connection
> 2013-08-05 16:57:40.052869 > HCI Event: Command Status (0x0f) plen 4
> Disconnect (0x01|0x0006) status 0x00 ncmd 1
> 2013-08-05 16:57:40.104731 > HCI Event: Mode Change (0x14) plen 6
> status 0x00 handle 11 mode 0x00 interval 0
> Mode: Active
> 2013-08-05 16:57:40.146935 > HCI Event: Disconn Complete (0x05) plen 4
> status 0x00 handle 11 reason 0x16
> Reason: Connection Terminated by Local Host
>
> Signed-off-by: Sang-Ki Park <sangki79.park@samsung.com>
> Signed-off-by: Chan-yeol Park <chanyeol.park@samsung.com>
> Signed-off-by: Jaganath Kanakkassery <jaganath.k@samsung.com>
> Signed-off-by: Szymon Janc <szymon.janc@tieto.com>
> Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
> ---
>
> v1 -> Modified the code as per the latest code.
> v2 -> Add descriptive comment as per Marcel request.
> v3 -> Moved from l2cap_conn_ready() to l2cap_connect() inorder to fix remote
> non ssp pairing timeout. Generated the patch based on bluetooth.git tree.
> v4 -> Include hcidump logs showing the conn status before and after fix.
>
> This patch is generated the patch based on bluetooth.git tree.
>
> net/bluetooth/l2cap_core.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index 68843a2..8179fc3 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -3753,6 +3753,13 @@ static struct l2cap_chan *l2cap_connect(struct l2cap_conn *conn,
>
> hci_conn_hold(conn->hcon);
>
> + /* For certain devices (ex: HID mouse), support for authentication,
> + * pairing and bonding is optional. For such devices, inorder to avoid
> + * the ACL alive for too long after L2CAP disconnection, reset the ACL
> + * disc_timeout back to HCI_DISCONN_TIMEOUT during L2CAP connect.
> + */
> + conn->hcon->disc_timeout = HCI_DISCONN_TIMEOUT;
> +
> bacpy(&bt_sk(sk)->src, conn->src);
> bacpy(&bt_sk(sk)->dst, conn->dst);
> chan->psm = psm;
> --
> 1.7.9.5
>
ping..
^ permalink raw reply
* Re: [PATCH] Bluetooth: Set different event mask for LE-only controllers
From: Gustavo Padovan @ 2013-08-15 8:18 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1376413254-36536-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
* Marcel Holtmann <marcel@holtmann.org> [2013-08-13 10:00:54 -0700]:
> In case of a Low Energy only controller it makes no sense to configure
> the full BR/EDR event mask. It will just enable events that can not be
> send anyway and there is no guarantee that such a controller will accept
> this value.
>
> Use event mask 0x90 0xe8 0x04 0x02 0x00 0x80 0x00 0x20 for LE-only
> controllers which enables the following events:
>
> Disconnection Complete
> Encryption Change
> Read Remote Version Information Complete
> Command Complete
> Command Status
> Hardware Error
> Number of Completed Packets
> Data Buffer Overflow
> Encryption Key Refresh Complete
> LE Meta
>
> This is according to Core Specification, Part E, Section 3.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/hci_core.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
Patch has been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH] Bluetooth: Set different event mask for LE-only controllers
From: Gustavo Padovan @ 2013-08-15 8:16 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1376413254-36536-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
* Marcel Holtmann <marcel@holtmann.org> [2013-08-13 10:00:54 -0700]:
> In case of a Low Energy only controller it makes no sense to configure
> the full BR/EDR event mask. It will just enable events that can not be
> send anyway and there is no guarantee that such a controller will accept
> this value.
>
> Use event mask 0x90 0xe8 0x04 0x02 0x00 0x80 0x00 0x20 for LE-only
> controllers which enables the following events:
>
> Disconnection Complete
> Encryption Change
> Read Remote Version Information Complete
> Command Complete
> Command Status
> Hardware Error
> Number of Completed Packets
> Data Buffer Overflow
> Encryption Key Refresh Complete
> LE Meta
>
> This is according to Core Specification, Part E, Section 3.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/hci_core.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
Patch has been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix getting SCO socket options in deferred state
From: Gustavo Padovan @ 2013-08-15 8:08 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth
In-Reply-To: <1375962836-3050-1-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
* johan.hedberg@gmail.com <johan.hedberg@gmail.com> [2013-08-08 14:53:56 +0300]:
> From: Johan Hedberg <johan.hedberg@intel.com>
>
> When a socket is in deferred state there does actually exist an
> underlying connection even though the connection state is not yet
> BT_CONNECTED. In the deferred state it should therefore be allowed to
> get socket options that usually depend on a connection, such as
> SCO_OPTIONS and SCO_CONNINFO.
>
> This patch fixes the behavior of some user space code that behaves as
> follows without it:
>
> $ sudo tools/btiotest -i 00:1B:DC:xx:xx:xx -d -s
> accept=2 reject=-1 discon=-1 defer=1 sec=0 update_sec=0 prio=0 voice=0x0000
> Listening for SCO connections
> bt_io_get(OPT_DEST): getsockopt(SCO_OPTIONS): Transport endpoint is not connected (107)
> Accepting connection
> Successfully connected to 60:D8:19:xx:xx:xx. handle=43, class=000000
>
> The conditions that the patch updates the if-statements to is taken from
> similar code in l2cap_sock.c which correctly handles the deferred state.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> net/bluetooth/sco.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
Patch has been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH] btmrvl_sdio: use DIV_ROUND_UP in suitable places
From: Gustavo Padovan @ 2013-08-15 7:56 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: linux-bluetooth, Marcel Holtmann
In-Reply-To: <1375441812-13852-1-git-send-email-andriy.shevchenko@linux.intel.com>
Hi Andy,
* Andy Shevchenko <andriy.shevchenko@linux.intel.com> [2013-08-02 14:10:12 +0300]:
> There are two places where DIV_ROUND_UP may be used. It makes code a bit
> clearer.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> drivers/bluetooth/btmrvl_sdio.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Patch has been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* [RFC 2/2] Bluetooth: Fix SCO cancelation before ACL is established
From: Frédéric Dalleau @ 2013-08-14 17:29 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Frédéric Dalleau
In-Reply-To: <1376501342-30347-1-git-send-email-frederic.dalleau@linux.intel.com>
If SCO socket is closed before ACL connection is established, it is
possible to cancel the ongoing ACL connection setup. This happen
automatically when the last reference to the ACL connection is dropped.
Thus this patch simply drop the ACL connection.
Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com>
---
include/net/bluetooth/hci_core.h | 1 +
net/bluetooth/hci_conn.c | 10 ++++++++++
net/bluetooth/sco.c | 4 +++-
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 1000553..a09556a 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -587,6 +587,7 @@ struct hci_conn *hci_connect(struct hci_dev *hdev, int type, bdaddr_t *dst,
__u8 dst_type, __u8 sec_level, __u8 auth_type);
struct hci_conn *hci_connect_sco(struct hci_dev *hdev, int type, bdaddr_t *dst,
__u16 setting);
+void hci_cancel_sco(struct hci_conn *hconn);
int hci_conn_check_link_mode(struct hci_conn *conn);
int hci_conn_check_secure(struct hci_conn *conn, __u8 sec_level);
int hci_conn_security(struct hci_conn *conn, __u8 sec_level, __u8 auth_type);
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index d3befac..c3ef7a5 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -639,6 +639,16 @@ struct hci_conn *hci_connect_sco(struct hci_dev *hdev, int type, bdaddr_t *dst,
return sco;
}
+void hci_cancel_sco(struct hci_conn *hcon)
+{
+ struct hci_conn *acl = hcon->link;
+
+ if (acl && acl->handle == 0)
+ hci_conn_drop(acl);
+ else
+ BT_DBG("ACL is already established");
+}
+
/* Create SCO, ACL or LE connection. */
struct hci_conn *hci_connect(struct hci_dev *hdev, int type, bdaddr_t *dst,
__u8 dst_type, __u8 sec_level, __u8 auth_type)
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index e94e654..89491a2 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -364,8 +364,10 @@ static void __sco_sock_close(struct sock *sk)
sco_chan_del(sk, ECONNRESET);
break;
- case BT_CONNECT2:
case BT_CONNECT:
+ if (sco_pi(sk)->conn->hcon)
+ hci_cancel_sco(sco_pi(sk)->conn->hcon);
+ case BT_CONNECT2:
case BT_DISCONN:
sco_chan_del(sk, ECONNRESET);
break;
--
1.7.9.5
^ permalink raw reply related
* [RFC 1/2] Bluetooth: Fix SCO connection without socket
From: Frédéric Dalleau @ 2013-08-14 17:29 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Frédéric Dalleau
If SCO socket is closed after ACL connection is established and before
SCO is established, it is not possible to cancel the ongoing
synchronous connection setup. When Synchronous Connection Complete
event is triggered, there will be no socket ready. Drop connection if
this is the case.
There is a side effect on this patch since it does not distinguish
between outgoing and incoming sco connections. An incoming SCO
connection with no acceptor will be dropped.
Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com>
---
include/net/bluetooth/hci_core.h | 10 +++++++---
net/bluetooth/hci_event.c | 5 +++--
net/bluetooth/sco.c | 14 +++++++++-----
3 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 1f95e9b..1000553 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -376,7 +376,7 @@ extern int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb,
u16 flags);
extern int sco_connect_ind(struct hci_dev *hdev, bdaddr_t *bdaddr, __u8 *flags);
-extern void sco_connect_cfm(struct hci_conn *hcon, __u8 status);
+extern int sco_connect_cfm(struct hci_conn *hcon, __u8 status);
extern void sco_disconn_cfm(struct hci_conn *hcon, __u8 reason);
extern int sco_recv_scodata(struct hci_conn *hcon, struct sk_buff *skb);
@@ -843,8 +843,10 @@ static inline int hci_proto_connect_ind(struct hci_dev *hdev, bdaddr_t *bdaddr,
}
}
-static inline void hci_proto_connect_cfm(struct hci_conn *conn, __u8 status)
+static inline int hci_proto_connect_cfm(struct hci_conn *conn, __u8 status)
{
+ int canceled = 0;
+
switch (conn->type) {
case ACL_LINK:
case LE_LINK:
@@ -853,7 +855,7 @@ static inline void hci_proto_connect_cfm(struct hci_conn *conn, __u8 status)
case SCO_LINK:
case ESCO_LINK:
- sco_connect_cfm(conn, status);
+ canceled = sco_connect_cfm(conn, status);
break;
default:
@@ -863,6 +865,8 @@ static inline void hci_proto_connect_cfm(struct hci_conn *conn, __u8 status)
if (conn->connect_cfm_cb)
conn->connect_cfm_cb(conn, status);
+
+ return canceled;
}
static inline int hci_proto_disconn_ind(struct hci_conn *conn)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 491c5fb..e29ef13 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -2879,6 +2879,7 @@ static void hci_sync_conn_complete_evt(struct hci_dev *hdev,
{
struct hci_ev_sync_conn_complete *ev = (void *) skb->data;
struct hci_conn *conn;
+ int canceled;
BT_DBG("%s status 0x%2.2x", hdev->name, ev->status);
@@ -2922,8 +2923,8 @@ static void hci_sync_conn_complete_evt(struct hci_dev *hdev,
break;
}
- hci_proto_connect_cfm(conn, ev->status);
- if (ev->status)
+ canceled = hci_proto_connect_cfm(conn, ev->status);
+ if (canceled || ev->status)
hci_conn_del(conn);
unlock:
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index 1170b6e..e94e654 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -979,7 +979,7 @@ static void sco_chan_del(struct sock *sk, int err)
sock_set_flag(sk, SOCK_ZAPPED);
}
-static void sco_conn_ready(struct sco_conn *conn)
+static int sco_conn_ready(struct sco_conn *conn)
{
struct sock *parent;
struct sock *sk = conn->sk;
@@ -998,7 +998,7 @@ static void sco_conn_ready(struct sco_conn *conn)
parent = sco_get_sock_listen(conn->src);
if (!parent) {
sco_conn_unlock(conn);
- return;
+ return 1;
}
bh_lock_sock(parent);
@@ -1008,7 +1008,7 @@ static void sco_conn_ready(struct sco_conn *conn)
if (!sk) {
bh_unlock_sock(parent);
sco_conn_unlock(conn);
- return;
+ return 0;
}
sco_sock_init(sk, parent);
@@ -1031,6 +1031,8 @@ static void sco_conn_ready(struct sco_conn *conn)
sco_conn_unlock(conn);
}
+
+ return 0;
}
/* ----- SCO interface with lower layer (HCI) ----- */
@@ -1061,7 +1063,7 @@ int sco_connect_ind(struct hci_dev *hdev, bdaddr_t *bdaddr, __u8 *flags)
return lm;
}
-void sco_connect_cfm(struct hci_conn *hcon, __u8 status)
+int sco_connect_cfm(struct hci_conn *hcon, __u8 status)
{
BT_DBG("hcon %p bdaddr %pMR status %d", hcon, &hcon->dst, status);
if (!status) {
@@ -1069,9 +1071,11 @@ void sco_connect_cfm(struct hci_conn *hcon, __u8 status)
conn = sco_conn_add(hcon);
if (conn)
- sco_conn_ready(conn);
+ return sco_conn_ready(conn);
} else
sco_conn_del(hcon, bt_to_errno(status));
+
+ return 0;
}
void sco_disconn_cfm(struct hci_conn *hcon, __u8 reason)
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox