* Re: [PATCH] Some code reordering in mcap_sync
From: Jose Antonio Santos Cadenas @ 2010-09-21 11:07 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas, linux-bluetooth
In-Reply-To: <20100921110529.GA10156@jh-x301>
2010/9/21 Johan Hedberg <johan.hedberg@gmail.com>:
> Hi,
>
> On Tue, Sep 21, 2010, Jose Antonio Santos Cadenas wrote:
>> Declaration, defines and struct definitions are moved to the begining
>> of the file. Just for make the code more readable.
>> ---
>> health/mcap_sync.c | 86 +++++++++++++++++++++++++--------------------------
>> 1 files changed, 42 insertions(+), 44 deletions(-)
>
> Thanks, the patch is now upstream. While you're at it, please also
> remove any unnecessary forward declarations, like these:
Ok, I'll work on it.
>
>> +static void proc_sync_cap_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
>> +static void proc_sync_set_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
>> +static void proc_sync_cap_rsp(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
>> +static void proc_sync_set_rsp(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
>> +static void proc_sync_info_ind(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
>
> Only in very rare cases are forward declarations needed. Whenever
> possible order the functions so that the dependencies of a function are
> defined above the function in the C file.
>
>> +static gboolean sync_send_indication(gpointer user_data);
>> +static gboolean proc_sync_set_req_phase2(gpointer user_data);
>
> Same here.
>
> Johan
>
^ permalink raw reply
* Re: Need complete docs on PAN and DUN with bluez 4.66
From: Luiz Augusto von Dentz @ 2010-09-21 11:06 UTC (permalink / raw)
To: Arun Kumar; +Cc: Mumia W, linux-bluetooth
In-Reply-To: <AANLkTi=gRJgyFD2uC-UsjzjQCU11326SSsN4+nsTxk9-@mail.gmail.com>
Hi,
On Tue, Sep 21, 2010 at 6:56 AM, Arun Kumar <arunkat@gmail.com> wrote:
> Depends on what role you want to use pand for ...pand is launched as a
> daemon via command line with set of options you may want to use it for
> your requirements ...
I wouldn't suggest using pand nor dund because they are deprecated.
PAN is really dead simple, Network.Connect() returns the network
interface in case of success and both NetworkManager and connman
should be able to use them, in fact I think both already have specif
PAN support to connect from their ui.
DUN is a bit more complicated, it rely on Serial.Connect("dun") which
creates a RFCOMM port to talk to the modem, but there need to be some
process that has an AT command engine to handle all the configuration,
in NetworkManager case there is ModemManager that is supposed to do
that but I have tried not long ago and it failed for me, I think we
might want to have ofono to handle this in connman case but so far
there the support for this is not complete (Gustavo Padovan has been
working on it).
Both Network and Serial interface are documented in doc/ diretory,
there is also test-network and test-serial under test/ that can be
used to manually connect to those profiles.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: [PATCH] Some code reordering in mcap_sync
From: Johan Hedberg @ 2010-09-21 11:05 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas; +Cc: linux-bluetooth
In-Reply-To: <1285056861-10099-1-git-send-email-santoscadenas@gmail.com>
Hi,
On Tue, Sep 21, 2010, Jose Antonio Santos Cadenas wrote:
> Declaration, defines and struct definitions are moved to the begining
> of the file. Just for make the code more readable.
> ---
> health/mcap_sync.c | 86 +++++++++++++++++++++++++--------------------------
> 1 files changed, 42 insertions(+), 44 deletions(-)
Thanks, the patch is now upstream. While you're at it, please also
remove any unnecessary forward declarations, like these:
> +static void proc_sync_cap_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
> +static void proc_sync_set_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
> +static void proc_sync_cap_rsp(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
> +static void proc_sync_set_rsp(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
> +static void proc_sync_info_ind(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
Only in very rare cases are forward declarations needed. Whenever
possible order the functions so that the dependencies of a function are
defined above the function in the C file.
> +static gboolean sync_send_indication(gpointer user_data);
> +static gboolean proc_sync_set_req_phase2(gpointer user_data);
Same here.
Johan
^ permalink raw reply
* [PATCH] Some code reordering in mcap_sync
From: Jose Antonio Santos Cadenas @ 2010-09-21 8:14 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jose Antonio Santos Cadenas
Declaration, defines and struct definitions are moved to the begining
of the file. Just for make the code more readable.
---
health/mcap_sync.c | 86 +++++++++++++++++++++++++--------------------------
1 files changed, 42 insertions(+), 44 deletions(-)
diff --git a/health/mcap_sync.c b/health/mcap_sync.c
index 260cd71..25fc2d4 100644
--- a/health/mcap_sync.c
+++ b/health/mcap_sync.c
@@ -44,6 +44,11 @@
#include "mcap_lib.h"
#include "mcap_internal.h"
+#define MCAP_BTCLOCK_HALF (MCAP_BTCLOCK_FIELD / 2)
+#define CLK CLOCK_MONOTONIC
+
+#define MCAP_CSP_ERROR g_quark_from_static_string("mcap-csp-error-quark")
+
struct mcap_csp {
uint64_t base_tmstamp; /* CSP base timestamp */
struct timespec base_time; /* CSP base time when timestamp set */
@@ -60,8 +65,31 @@ struct mcap_csp {
void *csp_priv_data; /* CSP-Master: In-flight request data */
};
-#define MCAP_BTCLOCK_HALF (MCAP_BTCLOCK_FIELD / 2)
-#define CLK CLOCK_MONOTONIC
+struct mcap_sync_cap_cbdata {
+ mcap_sync_cap_cb cb;
+ gpointer user_data;
+};
+
+struct mcap_sync_set_cbdata {
+ mcap_sync_set_cb cb;
+ gpointer user_data;
+};
+
+struct csp_caps {
+ int ts_acc; /* timestamp accuracy */
+ int ts_res; /* timestamp resolution */
+ int latency; /* Read BT clock latency */
+ int preempt_thresh; /* Preemption threshold for latency */
+ int syncleadtime_ms; /* SyncLeadTime in ms */
+};
+
+struct sync_set_data {
+ uint8_t update;
+ uint32_t sched_btclock;
+ uint64_t timestamp;
+ int ind_freq;
+ gboolean role;
+};
/* Ripped from lib/sdp.c */
@@ -80,6 +108,18 @@ static inline uint64_t ntoh64(uint64_t n)
#define hton64(x) ntoh64(x)
+static gboolean csp_caps_initialized = FALSE;
+struct csp_caps _caps;
+
+static void proc_sync_cap_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
+static void proc_sync_set_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
+static void proc_sync_cap_rsp(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
+static void proc_sync_set_rsp(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
+static void proc_sync_info_ind(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
+
+static gboolean sync_send_indication(gpointer user_data);
+static gboolean proc_sync_set_req_phase2(gpointer user_data);
+
static int send_sync_cmd(struct mcap_mcl *mcl, const void *buf, uint32_t size)
{
int sock;
@@ -121,24 +161,6 @@ static int send_unsupported_set_req(struct mcap_mcl *mcl)
return sent;
}
-static void proc_sync_cap_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
-static void proc_sync_set_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
-static void proc_sync_cap_rsp(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
-static void proc_sync_set_rsp(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
-static void proc_sync_info_ind(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
-
-#define MCAP_CSP_ERROR g_quark_from_static_string("mcap-csp-error-quark")
-
-struct mcap_sync_cap_cbdata {
- mcap_sync_cap_cb cb;
- gpointer user_data;
-};
-
-struct mcap_sync_set_cbdata {
- mcap_sync_set_cb cb;
- gpointer user_data;
-};
-
void proc_sync_cmd(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
{
if (!mcl->ms->csp_enabled || !mcl->csp) {
@@ -319,7 +341,6 @@ static gboolean read_btclock(struct mcap_mcl *mcl, uint32_t *btclock,
return ret < 0 ? FALSE : TRUE;
}
-
static gboolean read_btclock_retry(struct mcap_mcl *mcl, uint32_t *btclock,
uint16_t *btaccuracy)
{
@@ -381,17 +402,6 @@ uint32_t mcap_get_btclock(struct mcap_mcl *mcl)
return btclock;
}
-struct csp_caps {
- int ts_acc; /* timestamp accuracy */
- int ts_res; /* timestamp resolution */
- int latency; /* Read BT clock latency */
- int preempt_thresh; /* Preemption threshold for latency */
- int syncleadtime_ms; /* SyncLeadTime in ms */
-};
-
-static struct csp_caps _caps;
-static gboolean csp_caps_initialized = FALSE;
-
static void initialize_caps(struct mcap_mcl *mcl)
{
struct timespec t1, t2;
@@ -542,18 +552,6 @@ static int send_sync_set_rsp(struct mcap_mcl *mcl, uint8_t rspcode,
return sent;
}
-static gboolean proc_sync_set_req_phase2(gpointer user_data);
-
-struct sync_set_data {
- uint8_t update;
- uint32_t sched_btclock;
- uint64_t timestamp;
- int ind_freq;
- gboolean role;
-};
-
-static gboolean sync_send_indication(gpointer user_data);
-
static void proc_sync_set_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
{
mcap_md_sync_set_req *req;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 2/2] Bluetooth: Update conf_state before send config_req out.
From: Ville Tervo @ 2010-09-21 6:05 UTC (permalink / raw)
To: ext haijun liu; +Cc: linux-bluetooth@vger.kernel.org, dantian.ip
In-Reply-To: <AANLkTimQtkORjmsiO3wPULRErNXORBtHATbBvdCEsY27@mail.gmail.com>
On Mon, Sep 20, 2010 at 03:33:31AM +0200, ext haijun liu wrote:
> Update conf_state with L2CAP_CONF_REQ_SENT before send config_req out.
>
>
> Signed-off-by: Haijun.Liu <Haijun.Liu@Atheros.com>
Acked-by: Ville Tervo <ville.tervo@nokia.com>
> ---
> net/bluetooth/l2cap.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index 076d1af..9d1225d 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -3164,6 +3164,7 @@ static inline int l2cap_config_req(struct
> l2cap_conn *conn, struct l2cap_cmd_hdr
> u8 buf[64];
> + l2cap_pi(sk)->conf_state |= L2CAP_CONF_REQ_SENT;
> l2cap_send_cmd(conn, l2cap_get_ident(conn), L2CAP_CONF_REQ,
> l2cap_build_conf_req(sk, buf), buf);
> l2cap_pi(sk)->num_conf_req++;
> }
>
> --
> 1.6.3.3
>
>
> --
> Haijun Liu
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] Bluetooth: Remove duplicate code.
From: Ville Tervo @ 2010-09-21 5:41 UTC (permalink / raw)
To: ext haijun liu; +Cc: linux-bluetooth@vger.kernel.org, dantian.ip
In-Reply-To: <AANLkTim_N7sA6NqmNqWsrW2dQmnwkm-NSGuFz191SQCT@mail.gmail.com>
On Mon, Sep 20, 2010 at 03:26:14AM +0200, ext haijun liu wrote:
> Remove duplicate code, it's already in l2cap_send_disconn_req().
>
>
> Signed-off-by: Haijun.Liu <Haijun.Liu@Atheros.com>
Acked-by: Ville Tervo <ville.tervo@nokia.com>
> ---
> net/bluetooth/l2cap.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index 725744b..076d1af 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -3222,7 +3222,6 @@ static inline int l2cap_config_rsp(struct
> l2cap_conn *conn, struct l2cap_cmd_hdr
> }
>
> default:
> - sk->sk_err = ECONNRESET;
> l2cap_sock_set_timer(sk, HZ * 5);
> l2cap_send_disconn_req(conn, sk, ECONNRESET);
> goto done;
> --
> 1.6.3.3
>
>
> --
> Haijun Liu
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Possible regression with skb_clone() in 2.6.36
From: Gustavo F. Padovan @ 2010-09-21 4:10 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-bluetooth, netdev, linux-kernel, marcel
In-Reply-To: <20100917153440.474b93e4.akpm@linux-foundation.org>
* Andrew Morton <akpm@linux-foundation.org> [2010-09-17 15:34:40 -0700]:
> On Mon, 30 Aug 2010 20:10:23 -0300
> "Gustavo F. Padovan" <padovan@profusion.mobi> wrote:
>
> > I've been experiencing some problems when running the L2CAP Streaming mode in
> > 2.6.36. The system quickly runs in an Out Of Memory condition and crash. That
> > wasn't happening before, so I think we may have a regression here (I didn't find
> > where yet). The crash log is below.
>
> So 2.6.35 was OK?
>
> > The following patch does not fix the regression, but shows that removing the
> > skb_clone() call from l2cap_streaming_send() makes the problem goes away. The
> > patch is good anyway since it saves memory and time when sending Streaming mode
> > packets.
>
> How does "make it go away" differ from "fix the regression" :)
>
> But yes, if we don't understand the source of the bug then it may well
> still be there. Did you make any progress in understanding the cause?
I did some progress and found that this really fix the bug. We are fine
here then. :)
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: Need complete docs on PAN and DUN with bluez 4.66
From: Arun Kumar @ 2010-09-21 3:56 UTC (permalink / raw)
To: Mumia W; +Cc: linux-bluetooth
In-Reply-To: <AANLkTi=hD_U-19oPnQzQemt5wBgAqip3h7esJZpgkr4e@mail.gmail.com>
Depends on what role you want to use pand for ...pand is launched as a
daemon via command line with set of options you may want to use it for
your requirements ...
...
Best Regards,
Arun Kumar Singh
www.crazydaks.com
> On Tue, Sep 21, 2010 at 6:20 AM, Mumia W <mumia.w.18.spam@earthlink.net> wrote:
>>>From: Mumia W <mumia.w.18.spam@earthlink.net>
>>>Sent: Sep 19, 2010 4:49 PM
>>>To: linux-bluetooth@vger.kernel.org
>>>Subject: Need complete docs on PAN and DUN with bluez 4.66
>>>
>>>Where is the documentation on how to use PAN and DUN
>>>with bluez 4.66 (without using the legacy drivers)?
>>>
>>>
>>
>> Evidently the documents do not exist.
>>
>> Does anyone have any advice on how I use PAN with bluez 4.66?
>>
>>
>> --
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> --
>
--
Best Regards,
Arun Kumar Singh
www.crazydaks.com
^ permalink raw reply
* Re: Need complete docs on PAN and DUN with bluez 4.66
From: Mumia W @ 2010-09-21 0:50 UTC (permalink / raw)
To: linux-bluetooth
>From: Mumia W <mumia.w.18.spam@earthlink.net>
>Sent: Sep 19, 2010 4:49 PM
>To: linux-bluetooth@vger.kernel.org
>Subject: Need complete docs on PAN and DUN with bluez 4.66
>
>Where is the documentation on how to use PAN and DUN
>with bluez 4.66 (without using the legacy drivers)?
>
>
Evidently the documents do not exist.
Does anyone have any advice on how I use PAN with bluez 4.66?
--
^ permalink raw reply
* Re: [PATCH 0/4 v6] L2CAP updates for valid PSMs, SOCK_STREAM reads
From: Ron Shaffer @ 2010-09-20 21:14 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, marcel, gustavo, linux-arm-msm
In-Reply-To: <1283965529-17068-1-git-send-email-mathewm@codeaurora.org>
On 9/8/2010 12:05 PM, Mat Martineau wrote:
> This patch set is the same as 'v5', with a fix to PSM validation.
>
>
> [PATCH 1/4] Bluetooth: Validate PSM values in calls to connect() and bind()
>
> Modified to bypass PSM validation for SOCK_RAW (bonding) sockets.
>
>
> [PATCH 2/4] Bluetooth: Add common code for stream-oriented recvmsg()
> [PATCH 3/4] Bluetooth: Use common SOCK_STREAM receive code in RFCOMM
> [PATCH 4/4] Bluetooth: Use a stream-oriented recvmsg with SOCK_STREAM L2CAP sockets.
>
> These patches change the read behavior of SOCK_STREAM L2CAP sockets to
> allow reading of partial SDUs. Same as the 'v5' patches.
>
Ping
--
Ron Shaffer
Employee of the Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH v3] Bluetooth: Add socket option definitions for AMP
From: Ron Shaffer @ 2010-09-20 21:13 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, marcel, gustavo, haijun.liu, linux-arm-msm
In-Reply-To: <1283966193-17831-1-git-send-email-mathewm@codeaurora.org>
On 9/8/2010 12:16 PM, Mat Martineau wrote:
> This adds a new BT_AMP socket option to control the use of AMP channels.
> It is for use with the SOL_BLUETOOTH option level on L2CAP sockets.
>
> Available option values are defined as:
>
> BT_AMP_REQUIRE_BR_EDR
> * Default
> * AMP controllers cannot be used
> * Channel move requests from the remote device are denied
> * If the L2CAP channel is currently using AMP, move the channel to
> BR/EDR
>
> BT_AMP_PREFER_AMP
> * Allow use of AMP controllers
> * If the L2CAP channel is currently on BR/EDR and AMP controller
> resources are available, initiate a channel move to AMP
> * Channel move requests from the remote device are allowed
> * If the L2CAP socket has not been connected yet, try to create
> and configure the channel directly on an AMP controller rather
> than BR/EDR
>
> BT_AMP_PREFER_BR_EDR
> * Allow use of AMP controllers
> * If the L2CAP channel is currently on AMP, move it to BR/EDR
> * Channel move requests from the remote device are allowed
>
> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> ---
> include/net/bluetooth/bluetooth.h | 28 ++++++++++++++++++++++++++++
> 1 files changed, 28 insertions(+), 0 deletions(-)
>
> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> index 27a902d..d2c62dc 100644
> --- a/include/net/bluetooth/bluetooth.h
> +++ b/include/net/bluetooth/bluetooth.h
> @@ -64,6 +64,34 @@ struct bt_security {
>
> #define BT_DEFER_SETUP 7
>
> +
> +#define BT_AMP_POLICY 8
> +
> +/* Require BR/EDR (default policy)
> + * AMP controllers cannot be used
> + * Channel move requests from the remote device are denied
> + * If the L2CAP channel is currently using AMP, move the channel to BR/EDR
> + */
> +#define BT_AMP_POLICY_REQUIRE_BR_EDR 0
> +
> +/* Prefer AMP
> + * Allow use of AMP controllers
> + * If the L2CAP channel is currently on BR/EDR and AMP controller
> + * resources are available, initiate a channel move to AMP
> + * Channel move requests from the remote device are allowed
> + * If the L2CAP socket has not been connected yet, try to create
> + * and configure the channel directly on an AMP controller rather
> + * than BR/EDR
> + */
> +#define BT_AMP_POLICY_PREFER_AMP 1
> +
> +/* Prefer BR/EDR
> + * Allow use of AMP controllers
> + * If the L2CAP channel is currently on AMP, move it to BR/EDR
> + * Channel move requests from the remote device are allowed
> + */
> +#define BT_AMP_POLICY_PREFER_BR_EDR 2
> +
> #define BT_INFO(fmt, arg...) printk(KERN_INFO "Bluetooth: " fmt "\n" , ## arg)
> #define BT_ERR(fmt, arg...) printk(KERN_ERR "%s: " fmt "\n" , __func__ , ## arg)
> #define BT_DBG(fmt, arg...) pr_debug("%s: " fmt "\n" , __func__ , ## arg)
Ping
--
Ron Shaffer
Employee of the Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: >net-wireless/bluez-4.63 unable to connect audio streams due commit
From: Johan Hedberg @ 2010-09-20 18:49 UTC (permalink / raw)
To: Pacho Ramos; +Cc: linux-bluetooth
In-Reply-To: <1285006436.15378.2.camel@localhost.localdomain>
Hi,
On Mon, Sep 20, 2010, Pacho Ramos wrote:
> Reporter found that the problem with his dongle was introduced in commit
> aee26b30bbc24cde464ba1a557c2b258ddec6432 "Make BtIO default security
> level MEDIUM", he asked here, on upstream mailing list, but didn't get
> any reply clarifying this:
> http://marc.info/?l=linux-bluetooth&m=127893935109510&w=2
The important piece of info missing here is an HCI trace of the failure
(i.e. output of hcidump). There was a similar issue reported on IRC a
few days back and the hcidump there revealed a LMP response timeout
after BlueZ issues a HCI_Set_Connection_Encryption command. This would
seem to indicate a bug either in the local adapter or the remote device
(headset). Only an airtrace would really reveal what's going on.
However, I suspect it might be possible to work around this by looking
into possibilities of changing the ordering and timing of when the
kernel sends the encryption request.
Johan
^ permalink raw reply
* >net-wireless/bluez-4.63 unable to connect audio streams due commit
From: Pacho Ramos @ 2010-09-20 18:13 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 1492 bytes --]
Hello
This is an "old" issue that was reported downstream some time ago at:
http://bugs.gentoo.org/show_bug.cgi?id=327705
Getting errors like:
bluetoothd[23165]: State
changed /org/bluez/23165/hci0/dev_00_19_7F_1B_E8_BE: \
HEADSET_STATE_DISCONNECTED -> HEADSET_STATE_CONNECTING
bluetoothd[23165]: \
link_key_request (sba=00:19:86:00:10:FE, dba=00:19:7F:1B:E8:BE)
bluetoothd[23165]: \
kernel auth requirements = 0x00 bluetoothd[23165]: stored link key type
= 0x00
bluetoothd[23165]: adapter_get_device(00:19:7F:1B:E8:BE)
bluetoothd[23165]: Discovered Handsfree service on channel 1
bluetoothd[23165]: /org/bluez/23165/hci0/dev_00_19_7F_1B_E8_BE:
Connecting to \
00:19:7F:1B:E8:BE channel 1 bluetoothd[23165]:
hcid_dbus_bonding_process_complete: \
status=00 bluetoothd[23165]: adapter_get_device(00:19:7F:1B:E8:BE)
bluetoothd[23165]: hcid_dbus_bonding_process_complete: no pending auth
request # Here \
is really long pause, 1-2 seconds bluetoothd[23165]: Function not
implemented (38)
bluetoothd[23165]: State
changed /org/bluez/23165/hci0/dev_00_19_7F_1B_E8_BE: \
HEADSET_STATE_CONNECTING -> HEADSET_STATE_DISCONNECTED
Reporter found that the problem with his dongle was introduced in commit
aee26b30bbc24cde464ba1a557c2b258ddec6432 "Make BtIO default security
level MEDIUM", he asked here, on upstream mailing list, but didn't get
any reply clarifying this:
http://marc.info/?l=linux-bluetooth&m=127893935109510&w=2
Thanks a lot for your help :-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] Add hcimgmt command line test tool
From: Johan Hedberg @ 2010-09-20 13:28 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <AANLkTi=xM5RSqZJ=bG-PfphpZ8awYKjSY+sB3ey4eu_P@mail.gmail.com>
Hi Anderson,
On Mon, Sep 20, 2010, Anderson Lizardo wrote:
> On Mon, Sep 20, 2010 at 7:07 AM, <johan.hedberg@gmail.com> wrote:
> > +static void usage(void)
> > +{
> > + int i;
> > +
> > + printf("hcictl - HCI Control ver %s\n", VERSION);
>
> hcictl -> hcimgmt
Thanks. I used to call the interface "HCI Control interface" originally
and have forgotten to change all places to match the new "Management"
term.
Johan
^ permalink raw reply
* Re: [PATCH 3/3] Add hcimgmt command line test tool
From: Anderson Lizardo @ 2010-09-20 13:13 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth, Johan Hedberg
In-Reply-To: <1284980866-3974-4-git-send-email-johan.hedberg@gmail.com>
On Mon, Sep 20, 2010 at 7:07 AM, <johan.hedberg@gmail.com> wrote:
> +static void usage(void)
> +{
> + int i;
> +
> + printf("hcictl - HCI Control ver %s\n", VERSION);
hcictl -> hcimgmt
> + printf("Usage:\n"
> + "\thcictl [options] <command> [command parameters]\n");
> + printf("Options:\n"
> + "\t--help\tDisplay help\n"
> + "\t-i dev\tHCI device\n");
> + printf("Commands:\n");
> + for (i = 0; command[i].cmd; i++)
> + printf("\t%-4s\t%s\n", command[i].cmd,
> + command[i].doc);
> + printf("\n"
> + "For more information on the usage of each command use:\n"
> + "\thcictl <command> --help\n" );
> +}
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [PATCH 2/2] Fix potential NULL pointer access in MCAP CSP code
From: Johan Hedberg @ 2010-09-20 11:17 UTC (permalink / raw)
To: Santiago Carot-Nemesio; +Cc: linux-bluetooth
In-Reply-To: <1284971729-20509-2-git-send-email-sancane@gmail.com>
Hi,
On Mon, Sep 20, 2010, Santiago Carot-Nemesio wrote:
> NULL pointer acces may hapen when an attemp to send a
> synchronization command happens over a closed MCL.
> ---
> health/mcap_sync.c | 43 ++++++++++++++++++++++---------------------
> 1 files changed, 22 insertions(+), 21 deletions(-)
Thanks. This patch is also now upstream.
Johan
^ permalink raw reply
* Re: [PATCH 1/2] Fix minor coding style issues in MCAP CSP code
From: Johan Hedberg @ 2010-09-20 11:16 UTC (permalink / raw)
To: Santiago Carot-Nemesio; +Cc: linux-bluetooth
In-Reply-To: <1284971729-20509-1-git-send-email-sancane@gmail.com>
Hi,
On Mon, Sep 20, 2010, Santiago Carot-Nemesio wrote:
> ---
> health/mcap_sync.c | 22 +++++++++-------------
> 1 files changed, 9 insertions(+), 13 deletions(-)
Thanks for the patch. It's now upstream.
Johan
^ permalink raw reply
* [PATCH 3/3] Add hcimgmt command line test tool
From: johan.hedberg @ 2010-09-20 11:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Johan Hedberg
In-Reply-To: <1284980866-3974-1-git-send-email-johan.hedberg@gmail.com>
From: Johan Hedberg <johan.hedberg@nokia.com>
---
Makefile.tools | 5 +-
tools/hcimgmt.c | 413 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 417 insertions(+), 1 deletions(-)
create mode 100644 tools/hcimgmt.c
diff --git a/Makefile.tools b/Makefile.tools
index 405a42b..f354a8c 100644
--- a/Makefile.tools
+++ b/Makefile.tools
@@ -5,7 +5,7 @@ conf_DATA += tools/rfcomm.conf
endif
bin_PROGRAMS += tools/rfcomm tools/l2ping \
- tools/hcitool tools/sdptool tools/ciptool
+ tools/hcitool tools/sdptool tools/ciptool tools/hcimgmt
sbin_PROGRAMS += tools/hciattach tools/hciconfig
@@ -36,6 +36,9 @@ tools_hcitool_SOURCES = tools/hcitool.c src/oui.h src/oui.c \
src/textfile.h src/textfile.c
tools_hcitool_LDADD = lib/libbluetooth.la
+tools_hcimgmt_SOURCES = tools/hcimgmt.c
+tools_hcimgmt_LDADD = lib/libbluetooth.la
+
tools_sdptool_SOURCES = tools/sdptool.c src/sdp-xml.h src/sdp-xml.c
tools_sdptool_LDADD = lib/libbluetooth.la
diff --git a/tools/hcimgmt.c b/tools/hcimgmt.c
new file mode 100644
index 0000000..5276e2f
--- /dev/null
+++ b/tools/hcimgmt.c
@@ -0,0 +1,413 @@
+/*
+ *
+ * BlueZ - Bluetooth protocol stack for Linux
+ *
+ * Copyright (C) 2010 Nokia Corporation
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#include <stdio.h>
+#include <errno.h>
+#include <ctype.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <stdlib.h>
+#include <string.h>
+#include <getopt.h>
+#include <sys/param.h>
+#include <sys/ioctl.h>
+#include <sys/socket.h>
+
+#include <bluetooth/bluetooth.h>
+#include <bluetooth/hci.h>
+#include <bluetooth/hci_lib.h>
+
+#define HCI_MGMT_BUF_SIZE 1024
+
+#define for_each_opt(opt, long, short) while ((opt=getopt_long(argc, argv, short ? short:"+", long, NULL)) != -1)
+
+static void usage(void);
+
+/* Display local devices */
+
+static struct option dev_options[] = {
+ { "help", 0, 0, 'h' },
+ {0, 0, 0, 0 }
+};
+
+static int hci_open_channel(int dev_id, unsigned short channel)
+{
+ struct sockaddr_hci a;
+ int dd, err;
+
+ /* Create HCI socket */
+ dd = socket(AF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI);
+ if (dd < 0)
+ return -errno;
+
+ /* Bind socket to the HCI device */
+ memset(&a, 0, sizeof(a));
+ a.hci_family = AF_BLUETOOTH;
+ a.hci_dev = dev_id;
+ a.hci_channel = channel;
+ if (bind(dd, (struct sockaddr *) &a, sizeof(a)) < 0) {
+ err = -errno;
+ goto fail;
+ }
+
+ return dd;
+
+fail:
+ close(dd);
+ return err;
+}
+
+static ssize_t hci_mgmt_cmd(int dd, uint16_t opcode, void *data, uint16_t len,
+ uint16_t rsp_ev, void *rsp, uint16_t rsp_len)
+{
+ ssize_t ret;
+ size_t copied;
+ struct hci_mgmt_hdr hdr = { htobs(opcode), htobs(len) };
+ char buf[HCI_MGMT_BUF_SIZE];
+
+ memcpy(buf, &hdr, sizeof(hdr));
+ memcpy(buf + sizeof(hdr), data, len);
+
+ ret = write(dd, buf, sizeof(hdr) + len);
+ if (ret < 0)
+ return -errno;
+
+ ret = read(dd, buf, sizeof(buf));
+ if (ret < 0)
+ return -errno;
+
+ if (ret < (ssize_t) sizeof(struct hci_mgmt_hdr)) {
+ fprintf(stderr,
+ "ret (%zd) != sizeof(struct hci_mgmt_hdr) (%zu)\n",
+ ret, sizeof(struct hci_mgmt_hdr));
+ return -EIO;
+ }
+
+ memcpy(&hdr, buf, sizeof(hdr));
+
+ if (btohs(hdr.len) != ret - sizeof(hdr)) {
+ fprintf(stderr, "hdr.len (%u) != ret - sizeof(hdr) (%zu)\n",
+ btohs(hdr.len), ret - sizeof(hdr));
+ return -EIO;
+ }
+
+ if (btohs(hdr.opcode) != rsp_ev) {
+ fprintf(stderr, "hdr.opcode (%u) != rsp_ev (%u)\n",
+ btohs(hdr.opcode), rsp_ev);
+ return -EIO;
+ }
+
+ copied = rsp_len < btohs(hdr.len) ? rsp_len : btohs(hdr.len);
+
+ memcpy(rsp, buf + sizeof(hdr), copied);
+
+ return copied;
+}
+
+static void print_bytes(uint8_t *bytes, size_t count)
+{
+ size_t i;
+
+ for (i = 0; i < count; i++)
+ printf("%02x ", bytes[i]);
+}
+
+static void cmd_features(int dev_id, int argc, char **argv)
+{
+ int dd;
+ ssize_t ret;
+ uint8_t features[8];
+ uint16_t opcode;
+ char buf[HCI_MGMT_BUF_SIZE], *ptr = buf;
+
+ dd = hci_open_channel(HCI_DEV_NONE, HCI_CHANNEL_CONTROL);
+ if (dd < 0) {
+ perror("HCI Control socket open failed");
+ exit(1);
+ }
+
+ ret = hci_mgmt_cmd(dd, HCI_MGMT_OP_READ_FEATURES, NULL, 0,
+ HCI_MGMT_EV_CMD_COMPLETE, buf, sizeof(buf));
+ if (ret < 0) {
+ fprintf(stderr, "Command failed: %s (%zd)\n",
+ strerror(-ret), -ret);
+ exit(1);
+ }
+
+ if (ret != 10) {
+ fprintf(stderr, "Too short response\n");
+ exit(1);
+ }
+
+ memcpy(&opcode, ptr, 2);
+ ptr += 2;
+
+ memcpy(features, ptr, 8);
+ ptr += 8;
+
+ printf("HCI Control API features: ");
+ print_bytes(features, 8);
+ printf("\n");
+}
+
+static void cmd_version(int dev_id, int argc, char **argv)
+{
+ int dd;
+ ssize_t ret;
+ uint8_t version;
+ uint16_t revision, opcode;
+ char buf[HCI_MGMT_BUF_SIZE], *ptr = buf;
+
+ dd = hci_open_channel(HCI_DEV_NONE, HCI_CHANNEL_CONTROL);
+ if (dd < 0) {
+ perror("HCI Control socket open failed");
+ exit(1);
+ }
+
+ ret = hci_mgmt_cmd(dd, HCI_MGMT_OP_READ_VERSION, NULL, 0,
+ HCI_MGMT_EV_CMD_COMPLETE, buf, sizeof(buf));
+ if (ret < 0) {
+ fprintf(stderr, "Command failed: %s (%zd)\n",
+ strerror(-ret), -ret);
+ exit(1);
+ }
+
+ if (ret != 5) {
+ fprintf(stderr, "Too short response\n");
+ exit(1);
+ }
+
+ memcpy(&opcode, ptr, 2);
+ ptr += 2;
+
+ version = *ptr++;
+
+ memcpy(&revision, ptr, 2);
+ ptr += 2;
+
+
+ printf("HCI Control API version %u.%u\n", version, btohs(revision));
+}
+
+static const char *dev_help =
+ "Usage:\n"
+ "\tdev\n";
+
+static void cmd_dev(int dev_id, int argc, char **argv)
+{
+ int opt, dd, i;
+ ssize_t ret;
+ uint16_t count, opcode;
+ char buf[HCI_MGMT_BUF_SIZE], *ptr = buf;
+
+ for_each_opt(opt, dev_options, NULL) {
+ switch (opt) {
+ default:
+ printf("%s", dev_help);
+ return;
+ }
+ }
+
+ dd = hci_open_channel(HCI_DEV_NONE, HCI_CHANNEL_CONTROL);
+ if (dd < 0) {
+ perror("HCI Control socket open failed");
+ exit(1);
+ }
+
+ ret = hci_mgmt_cmd(dd, HCI_MGMT_OP_READ_INDEX_LIST, NULL, 0,
+ HCI_MGMT_EV_CMD_COMPLETE, buf, sizeof(buf));
+ if (ret < 0) {
+ fprintf(stderr, "Failed\n");
+ exit(1);
+ }
+
+ if (ret < 4) {
+ fprintf(stderr, "Too short response\n");
+ exit(1);
+ }
+
+ memcpy(&opcode, ptr, 2);
+ ptr += 2;
+
+ memcpy(&count, ptr, 2);
+ ptr += 2;
+
+ printf("Devices:\n\t");
+
+ for (i = 0; i < count; i++, ptr += 2) {
+ uint16_t index;
+ memcpy(&index, ptr, 2);
+ printf("hci%u ", btohs(index));
+ }
+
+ printf("\n");
+}
+
+static void cmd_info(int dev_id, int argc, char **argv)
+{
+ int dd;
+ ssize_t ret;
+ uint8_t features[8], type, status;
+ char buf[HCI_MGMT_BUF_SIZE], *ptr = buf, addr[18];
+ uint16_t id, opcode;
+ bdaddr_t bdaddr;
+
+ dd = hci_open_channel(HCI_DEV_NONE, HCI_CHANNEL_CONTROL);
+ if (dd < 0) {
+ perror("HCI Control socket open failed");
+ exit(1);
+ }
+
+ if (dev_id < 0) {
+ dev_id = hci_get_route(NULL);
+ if (dev_id < 0) {
+ perror("Device is not available");
+ exit(1);
+ }
+ }
+
+ id = (uint16_t) dev_id;
+
+ ret = hci_mgmt_cmd(dd, HCI_MGMT_OP_READ_INFO, &id, sizeof(id),
+ HCI_MGMT_EV_CMD_COMPLETE, buf, sizeof(buf));
+ if (ret < 0) {
+ fprintf(stderr, "Command failed: %s (%zd)\n",
+ strerror(-ret), -ret);
+ exit(1);
+ }
+
+ if (ret != 20) {
+ fprintf(stderr, "Unexpected response length (%zd)\n", ret);
+ exit(1);
+ }
+
+ memcpy(&opcode, ptr, 2);
+ ptr += 2;
+
+ status = *ptr;
+ ptr++;
+
+ memcpy(&id, ptr, 2);
+ ptr += 2;
+
+ type = *ptr;
+ ptr++;
+
+ bacpy(&bdaddr, (bdaddr_t *) ptr);
+ ptr += sizeof(bdaddr);
+
+ memcpy(features, ptr, 8);
+ ptr += 8;
+
+ ba2str(&bdaddr, addr);
+
+ printf("hci%u type %u addr %s features ", btohs(id), type, addr);
+ print_bytes(features, 8);
+ printf("\n");
+}
+
+static struct {
+ char *cmd;
+ void (*func)(int dev_id, int argc, char **argv);
+ char *doc;
+} command[] = {
+ { "dev", cmd_dev, "Display local devices" },
+ { "version", cmd_version, "Display version" },
+ { "features", cmd_features, "Control API features" },
+ { "info", cmd_info, "Read controller info" },
+ { NULL, NULL, 0 }
+};
+
+static void usage(void)
+{
+ int i;
+
+ printf("hcictl - HCI Control ver %s\n", VERSION);
+ printf("Usage:\n"
+ "\thcictl [options] <command> [command parameters]\n");
+ printf("Options:\n"
+ "\t--help\tDisplay help\n"
+ "\t-i dev\tHCI device\n");
+ printf("Commands:\n");
+ for (i = 0; command[i].cmd; i++)
+ printf("\t%-4s\t%s\n", command[i].cmd,
+ command[i].doc);
+ printf("\n"
+ "For more information on the usage of each command use:\n"
+ "\thcictl <command> --help\n" );
+}
+
+static struct option main_options[] = {
+ { "help", 0, 0, 'h' },
+ { "device", 1, 0, 'i' },
+ { 0, 0, 0, 0 }
+};
+
+int main(int argc, char *argv[])
+{
+ int opt, i, dev_id = -1;
+ bdaddr_t ba;
+
+ while ((opt=getopt_long(argc, argv, "+i:h", main_options, NULL)) != -1) {
+ switch (opt) {
+ case 'i':
+ dev_id = hci_devid(optarg);
+ if (dev_id < 0) {
+ perror("Invalid device");
+ exit(1);
+ }
+ break;
+
+ case 'h':
+ default:
+ usage();
+ exit(0);
+ }
+ }
+
+ argc -= optind;
+ argv += optind;
+ optind = 0;
+
+ if (argc < 1) {
+ usage();
+ exit(0);
+ }
+
+ if (dev_id != -1 && hci_devba(dev_id, &ba) < 0) {
+ perror("Device is not available");
+ exit(1);
+ }
+
+ for (i = 0; command[i].cmd; i++) {
+ if (strncmp(command[i].cmd, argv[0], 3))
+ continue;
+ command[i].func(dev_id, argc, argv);
+ break;
+ }
+ return 0;
+}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/3] Add initial definitions for Bluetooth Management API
From: johan.hedberg @ 2010-09-20 11:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Johan Hedberg
In-Reply-To: <1284980866-3974-1-git-send-email-johan.hedberg@gmail.com>
From: Johan Hedberg <johan.hedberg@nokia.com>
---
lib/hci.h | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/lib/hci.h b/lib/hci.h
index 512dab9..1ac153f 100644
--- a/lib/hci.h
+++ b/lib/hci.h
@@ -2232,6 +2232,24 @@ typedef struct {
#endif /* _NO_HCI_DEFS */
+struct hci_mgmt_hdr {
+ uint16_t opcode;
+ uint16_t len;
+} __packed;
+#define HCI_MGMT_HDR_SIZE 4
+
+#define HCI_MGMT_OP_READ_VERSION 0x0001
+#define HCI_MGMT_OP_READ_FEATURES 0x0002
+#define HCI_MGMT_OP_READ_INDEX_LIST 0x0003
+#define HCI_MGMT_OP_READ_INFO 0x0004
+#define HCI_MGMT_OP_READ_STATISTICS 0x0005
+#define HCI_MGMT_OP_READ_MODE 0x0006
+#define HCI_MGMT_OP_WRITE_MODE 0x0007
+
+#define HCI_MGMT_EV_CMD_COMPLETE 0x0001
+#define HCI_MGMT_EV_CMD_STATUS 0x0002
+#define HCI_MGMT_EV_CONTROLLER_ERROR 0x0003
+
/* HCI Socket options */
#define HCI_DATA_DIR 1
#define HCI_FILTER 2
@@ -2244,9 +2262,12 @@ typedef struct {
struct sockaddr_hci {
sa_family_t hci_family;
unsigned short hci_dev;
+ unsigned short hci_channel;
};
#define HCI_DEV_NONE 0xffff
+#define HCI_CHANNEL_CONTROL 1
+
struct hci_filter {
uint32_t type_mask;
uint32_t event_mask[2];
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/3] Add initial Bluetooth Management API doc
From: johan.hedberg @ 2010-09-20 11:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Johan Hedberg
In-Reply-To: <1284980866-3974-1-git-send-email-johan.hedberg@gmail.com>
From: Johan Hedberg <johan.hedberg@nokia.com>
---
doc/mgmt-api.txt | 178 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 178 insertions(+), 0 deletions(-)
create mode 100644 doc/mgmt-api.txt
diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
new file mode 100644
index 0000000..9281103
--- /dev/null
+++ b/doc/mgmt-api.txt
@@ -0,0 +1,178 @@
+Bluetooth Management API
+*************************
+
+Copyright (C) 2008-2009 Marcel Holtmann <marcel@holtmann.org>
+
+
+Packet Structures
+=================
+
+ Commands:
+
+ 0 4 8 12 16 202 24 28 31
+ +-------------------------------+-----------------------------+
+ | Command Code | Parameter Total Length |
+ +-------------------------------+-----------------------------+
+ | |
+
+ Events:
+
+ 0 4 8 12 16 202 24 28 31
+ +-------------------------------+-----------------------------+
+ | Event Code | Parameter Total Length |
+ +-------------------------------+-----------------------------+
+ | |
+
+
+Read Management Version Information Command
+===========================================
+
+ Command Code: 0x0001
+ Command Parameters:
+ Return Parameters: Status (1 Octet)
+ Version (1 Octets
+ Revision (2 Octets)
+
+Read Management Supported Features Command
+==========================================
+
+ Command Code: 0x0002
+ Command Parameters:
+ Return Parameters: Status (1 Octet)
+ Features (8 Octets)
+
+ Feature Bit 0: Controller Support
+ Feature Bit 1: Tracing Support
+
+Read Controller Index List Command
+==================================
+
+ Command Code: 0x0003
+ Command Parameters:
+ Return Paramters: Status (1 Octet)
+ Num_Controllers (2 Octets)
+ Controller_Index[i] (2 Octets)
+
+Read Controller Information Command
+===================================
+
+ Command Code: 0x0004
+ Command Parameters: Controller_Index (2 Octets)
+ Return Parameters: Status (1 Octet)
+ Controller_Index (2 Octets)
+ Controller_Type (1 Octet)
+ BD_ADDR (6 Octets)
+ Supported_Features (8 Octets)
+
+ Controller_Type:0x00 Reserved
+ 0x01 Bluetooth (BR/EDR)
+ 0x02 802.11 (AMP)
+
+Read Controller Statistics Command
+==================================
+
+ Command Code: 0x0005
+ Command Parameters: Controller_Index (2 Octets)
+ Return Paramters: Status (1 Octet)
+ Controller_Index (2 Octets)
+ ....
+
+Read Controller Mode Command
+============================
+
+ Command Code: 0x0006
+ Command Parameters: Controller_Index (2 Octets)
+ Return Paramters: Status (1 Octect)
+ Controller_Index (2 Octets)
+ Enabled (1 Octet)
+ Mode (1 Octet)
+
+ Enabled: 0x00 Powered off
+ 0x01 Controller Enabled
+
+ Mode: 0x00 Reserved
+ 0x01 Connectable (pairing forbidden)
+ 0x02 Connectable (pairing allowed)
+ 0x03 Discoverable (pairing forbidden)
+ 0x04 Discoverable (pairing allowed)
+
+Write Controller Mode Command
+=============================
+
+ Command Code: 0x0007
+ Command Parameters: Controller_Index (2 Octets)
+ ...
+ Return Parameters: Status (1 Octet)
+ Controller_Index (2 Octets)
+
+
+Read Tracing Buffer Size Command
+================================
+
+ Command Code: 0x0004
+ Command Parameters:
+ Return Parameters: Status (1 Octet)
+ Buffer_Size (2 Octets)
+
+ Buffer Size in Kilobytes
+
+Write Tracing Buffer Size Command
+=================================
+
+ Command Code: 0x0005
+ Command Parameters: Buffer_Size (2 Octets)
+ Return Parameters: Status (1 Octet)
+
+ Buffer Size in Kilobytes
+
+Read Controller Tracing Filter Command
+=======================================
+
+ Command Code: 0x0011
+ Command Parameters: Controller_Index (2 Octects)
+ Return Parameters: Status (1 Octet)
+ Controller_Index (2 Octets)
+ Tracing_Enable (1 Octect)
+ Num_Filters (2 Octect)
+ Protocol_UUID[i] (16 Octets)
+ Protocol_Identifier[i] (16 Octets)
+
+ Tracing_Enable: 0x00 Tracing disabled
+ 0x01 Command and Event tracing
+ 0x02 Command, Event and ACL tracing
+ 0x03 Command, Event, ACL and SCO tracing
+
+Write Controller Tracing Filter Command
+=======================================
+
+ Command Code: 0x0012 (Group 0x0)
+ Command Parameters: Controller_Index (2 Octects)
+ Tracing_Enable (1 Octect)
+ Num_Filters (2 Octect)
+ Protocol_UUID[i] (16 Octets)
+ Protocol_Identifier[i] (16 Octets)
+ Return Paramters: Status (1 Octet)
+ Controller_Index (2 Octets)
+
+
+
+Command Complete Event
+======================
+
+Event Code 0x0001
+Event Parameters Command_Opcode
+ Return_Parameters
+
+
+Command Status Event
+====================
+
+Event Code 0x0002
+Event Parameters Status
+ Command_Opcode
+
+Controller Error Event
+======================
+
+Event Code 0x0003
+Event Parameters Error_Code
--
1.7.0.4
^ permalink raw reply related
* [RFC] Bluetooth Management Interface
From: johan.hedberg @ 2010-09-20 11:07 UTC (permalink / raw)
To: linux-bluetooth
Hi,
Here's a initial set of patches to get the Bluetooth Management
interface work started. As I've mentioned in previous emails the idea of
this interface is to replace all current HCI level access in bluetoothd.
Many things, e.g. SSP logic and name resolving, will be moved to the
kernel side so there wont be a one-to-one mapping from the new
interface to the current HCI messages that bluetoothd handles.
The patches here just add the initial header file definitions and a
command line test tool. The kernel side patches can be found from my
kernel.org git tree:
http://git.kernel.org/?p=linux/kernel/git/jh/linux-2.6.git;a=summary
Access to the new kernel interface is done with the help of a new
hci_channel member of the HCI socket address. Only channel 1 is defined
for now for the new messages, but I've understood Marcel has plans to
enable some sort of special tracing support through a second channel.
Messages with hci_channel == 1 from userspace get routed to the
callbacks defined in net/bluetooth/hci_mgmt.c.
So far I haven't made many changes to the initial draft API doc from
Marcel (doc/mgmt-api.txt). The general idea is to try to mimic standard
HCI messaging concepts whenever possible. One of the changes that I did
do is removal of the Num_Command_Packets parameters from the command
status and command complete events since I don't think it makes sense to
require userspace to do command queuing.
Next steps that need to be done for bluetoothd:
- Move all HCI socket access to hciops.c
- All ioctl and hci_* calls
- HCI event processing (mostly src/security.c)
- Create a new mgmtops.c for the new API which can ultimately replace
hciops.c
- Figure out exactly which features are needed in the new API and fill
in doc/mgmt-api.txt accordingly.
Next steps for the kernel side:
- Define structs for each message. Not sure if this is needed/wanted but
it would surely improve the readability of the current code that
accesses the byte array directly. Since the new protocol and the
format of the messages is still largely open I haven't bothered with
these structs yet.
- Implement handling of events (right now only commands and direct
responses to them are supported)
- Implement handling of commands that require sleeping (currently all
implemented commands imediately write the response to the socket)
Any feedback is welcome about these plans and the code. It's my first
attempt at more serious kernel side coding so there might well be issues
needing fixing/polishing in the code.
Johan
^ permalink raw reply
* Re: [PATCH] Bluetooth: Replace hard code of fixed channels bit mask
From: Ville Tervo @ 2010-09-20 9:19 UTC (permalink / raw)
To: ext haijun liu
Cc: ext Gustavo F. Padovan, linux-bluetooth@vger.kernel.org,
Mat Martineau, dantian.ip
In-Reply-To: <AANLkTi=L3TC8Hy29xjDH-0aCMQ9RiLZ_-JtNfno97cas@mail.gmail.com>
On Fri, Sep 17, 2010 at 01:39:30PM +0200, ext haijun liu wrote:
> Hi Ville,
>
> On Fri, Sep 17, 2010 at 4:50 PM, Ville Tervo <ville.tervo@nokia.com> wrote:
> > Hi Gustavo,
> >
> > On Thu, Sep 16, 2010 at 04:16:54PM +0200, ext Gustavo F. Padovan wrote:
> >> Hi Haijun,
> >>
> >> * haijun liu <liuhaijun.er@gmail.com> [2010-09-16 15:15:18 +0800]:
> >>
> >> > This patch add fixed channels bit mask definition for
> >> > L2CAP_FIXCHAN_NULLID
> >> > L2CAP_FIXCHAN_SIGNAL
> >> > L2CAP_FIXCHAN_CONNLESS
> >> > L2CAP_FIXCHAN_A2MP
> >> > And replace hard code in source file with the macro.
> >> >
> >> > Signed-off-by: Haijun.Liu <Haijun.Liu@Atheros.com>
> >> > ---
> >> > include/net/bluetooth/l2cap.h | 6 ++++++
> >> > net/bluetooth/l2cap.c | 2 +-
> >> > 2 files changed, 7 insertions(+), 1 deletions(-)
> >> >
> >> > diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
> >> > index 6c24144..e4fe2c7 100644
> >> > --- a/include/net/bluetooth/l2cap.h
> >> > +++ b/include/net/bluetooth/l2cap.h
> >> > @@ -97,6 +97,12 @@ struct l2cap_conninfo {
> >> > #define L2CAP_FEAT_FCS 0x00000020
> >> > #define L2CAP_FEAT_FIXED_CHAN 0x00000080
> >> >
> >> > +/* L2CAP fixed channel bitmask */
> >> > +#define L2CAP_FIXCHAN_NULLID 0x00
> >> > +#define L2CAP_FIXCHAN_SIGNAL 0x02
> >> > +#define L2CAP_FIXCHAN_CONNLESS 0x04
> >> > +#define L2CAP_FIXCHAN_A2MP 0x08
> >>
> >> That's wrong, signaling channel is 0x01, connless is 0x02 and A2MP is
> >> 0x03. And if you haven't noted we already have macros for the signaling
> >> and connectionless channels:
> >
> > But these are bit masks and looks ok to me except L2CAP_FIXCHAN_A2MP which I
> > could not find from the list.. Check Vol 3 Part A 4.13.
> >
> >> #define L2CAP_CID_SIGNALING 0x0001
> >> #define L2CAP_CID_CONN_LESS 0x0002
> >
> > These are channel ids.
> >
> >
> > --
> > Ville
> >
>
> A2MP means AMP Manager Protocol, it's from <<Core_V3.0 + HS.pdf>>
ok. I am a little bit lost with all AMP acromyns.
--
Ville
^ permalink raw reply
* [PATCH 2/2] Fix potential NULL pointer access in MCAP CSP code
From: Santiago Carot-Nemesio @ 2010-09-20 8:35 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Santiago Carot-Nemesio
In-Reply-To: <1284971729-20509-1-git-send-email-sancane@gmail.com>
NULL pointer acces may hapen when an attemp to send a
synchronization command happens over a closed MCL.
---
health/mcap_sync.c | 43 ++++++++++++++++++++++---------------------
1 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/health/mcap_sync.c b/health/mcap_sync.c
index ae7ab5b..260cd71 100644
--- a/health/mcap_sync.c
+++ b/health/mcap_sync.c
@@ -80,17 +80,27 @@ static inline uint64_t ntoh64(uint64_t n)
#define hton64(x) ntoh64(x)
+static int send_sync_cmd(struct mcap_mcl *mcl, const void *buf, uint32_t size)
+{
+ int sock;
+
+ if (mcl->cc == NULL)
+ return -1;
+
+ sock = g_io_channel_unix_get_fd(mcl->cc);
+ return mcap_send_data(sock, buf, size);
+}
+
static int send_unsupported_cap_req(struct mcap_mcl *mcl)
{
mcap_md_sync_cap_rsp *cmd;
- int sock, sent;
+ int sent;
cmd = g_new0(mcap_md_sync_cap_rsp, 1);
cmd->op = MCAP_MD_SYNC_CAP_RSP;
cmd->rc = MCAP_REQUEST_NOT_SUPPORTED;
- sock = g_io_channel_unix_get_fd(mcl->cc);
- sent = mcap_send_data(sock, cmd, sizeof(*cmd));
+ sent = send_sync_cmd(mcl, cmd, sizeof(*cmd));
g_free(cmd);
return sent;
@@ -99,14 +109,13 @@ static int send_unsupported_cap_req(struct mcap_mcl *mcl)
static int send_unsupported_set_req(struct mcap_mcl *mcl)
{
mcap_md_sync_set_rsp *cmd;
- int sock, sent;
+ int sent;
cmd = g_new0(mcap_md_sync_set_rsp, 1);
cmd->op = MCAP_MD_SYNC_SET_RSP;
cmd->rc = MCAP_REQUEST_NOT_SUPPORTED;
- sock = g_io_channel_unix_get_fd(mcl->cc);
- sent = mcap_send_data(sock, cmd, sizeof(*cmd));
+ sent = send_sync_cmd(mcl, cmd, sizeof(*cmd));
g_free(cmd);
return sent;
@@ -457,7 +466,6 @@ static int send_sync_cap_rsp(struct mcap_mcl *mcl, uint8_t rspcode,
{
mcap_md_sync_cap_rsp *rsp;
int sent;
- int sock;
rsp = g_new0(mcap_md_sync_cap_rsp, 1);
@@ -469,8 +477,7 @@ static int send_sync_cap_rsp(struct mcap_mcl *mcl, uint8_t rspcode,
rsp->timestnr = htons(tmstampres);
rsp->timestna = htons(tmstampacc);
- sock = g_io_channel_unix_get_fd(mcl->cc);
- sent = mcap_send_data(sock, rsp, sizeof(*rsp));
+ sent = send_sync_cmd(mcl, rsp, sizeof(*rsp));
g_free(rsp);
return sent;
@@ -519,7 +526,7 @@ static int send_sync_set_rsp(struct mcap_mcl *mcl, uint8_t rspcode,
uint16_t tmstampres)
{
mcap_md_sync_set_rsp *rsp;
- int sock, sent;
+ int sent;
rsp = g_new0(mcap_md_sync_set_rsp, 1);
@@ -529,8 +536,7 @@ static int send_sync_set_rsp(struct mcap_mcl *mcl, uint8_t rspcode,
rsp->timestst = hton64(timestamp);
rsp->timestsa = htons(tmstampres);
- sock = g_io_channel_unix_get_fd(mcl->cc);
- sent = mcap_send_data(sock, rsp, sizeof(*rsp));
+ sent = send_sync_cmd(mcl, rsp, sizeof(*rsp));
g_free(rsp);
return sent;
@@ -786,7 +792,7 @@ static gboolean sync_send_indication(gpointer user_data)
uint32_t btclock;
uint64_t tmstamp;
struct timespec base_time;
- int sock, sent;
+ int sent;
if (!user_data)
return FALSE;
@@ -803,8 +809,7 @@ static gboolean sync_send_indication(gpointer user_data)
cmd->timestst = hton64(tmstamp);
cmd->timestsa = htons(caps(mcl)->latency);
- sock = g_io_channel_unix_get_fd(mcl->cc);
- sent = mcap_send_data(sock, cmd, sizeof(*cmd));
+ sent = send_sync_cmd(mcl, cmd, sizeof(*cmd));
g_free(cmd);
return !sent;
@@ -940,7 +945,6 @@ void mcap_sync_cap_req(struct mcap_mcl *mcl, uint16_t reqacc,
{
struct mcap_sync_cap_cbdata *cbdata;
mcap_md_sync_cap_req *cmd;
- int sock;
if (!mcl->ms->csp_enabled || !mcl->csp) {
g_set_error(err,
@@ -969,8 +973,7 @@ void mcap_sync_cap_req(struct mcap_mcl *mcl, uint16_t reqacc,
cbdata->user_data = user_data;
mcl->csp->csp_priv_data = cbdata;
- sock = g_io_channel_unix_get_fd(mcl->cc);
- mcap_send_data(sock, cmd, sizeof(*cmd));
+ send_sync_cmd(mcl, cmd, sizeof(*cmd));
g_free(cmd);
}
@@ -981,7 +984,6 @@ void mcap_sync_set_req(struct mcap_mcl *mcl, uint8_t update, uint32_t btclock,
{
mcap_md_sync_set_req *cmd;
struct mcap_sync_set_cbdata *cbdata;
- int sock;
if (!mcl->ms->csp_enabled || !mcl->csp) {
g_set_error(err,
@@ -1022,8 +1024,7 @@ void mcap_sync_set_req(struct mcap_mcl *mcl, uint8_t update, uint32_t btclock,
cbdata->user_data = user_data;
mcl->csp->csp_priv_data = cbdata;
- sock = g_io_channel_unix_get_fd(mcl->cc);
- mcap_send_data(sock, cmd, sizeof(*cmd));
+ send_sync_cmd(mcl, cmd, sizeof(*cmd));
g_free(cmd);
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] Fix minor coding style issues in MCAP CSP code
From: Santiago Carot-Nemesio @ 2010-09-20 8:35 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Santiago Carot-Nemesio
---
health/mcap_sync.c | 22 +++++++++-------------
1 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/health/mcap_sync.c b/health/mcap_sync.c
index bc1ffcd..ae7ab5b 100644
--- a/health/mcap_sync.c
+++ b/health/mcap_sync.c
@@ -590,9 +590,9 @@ static void proc_sync_set_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
return;
}
- if (sched_btclock == MCAP_BTCLOCK_IMMEDIATE) {
+ if (sched_btclock == MCAP_BTCLOCK_IMMEDIATE)
phase2_delay = 0;
- } else {
+ else {
phase2_delay = btdiff(cur_btclock, sched_btclock);
if (phase2_delay < 0) {
@@ -631,9 +631,8 @@ static void proc_sync_set_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
}
DBG("CSP: indication every %dms", ind_freq);
- } else {
+ } else
ind_freq = 0;
- }
if (mcl->csp->ind_timer) {
/* Old indications are no longer sent */
@@ -661,14 +660,12 @@ static void proc_sync_set_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
mcl->csp->set_timer = g_timeout_add(when,
proc_sync_set_req_phase2,
mcl);
- } else {
+ } else
proc_sync_set_req_phase2(mcl);
- }
/* First indication is immediate */
- if (update) {
+ if (update)
sync_send_indication(mcl);
- }
}
static gboolean get_all_clocks(struct mcap_mcl *mcl, uint32_t *btclock,
@@ -749,11 +746,10 @@ static gboolean proc_sync_set_req_phase2(gpointer user_data)
if (delay >= 0 || ((new_tmstamp - delay) > 0)) {
new_tmstamp += delay;
DBG("CSP: reset w/ delay %dus, compensated",
- delay);
- } else {
+ delay);
+ } else
DBG("CSP: reset w/ delay %dus, uncompensated",
- delay);
- }
+ delay);
}
reset_tmstamp(mcl->csp, &base_time, new_tmstamp);
@@ -860,7 +856,7 @@ static void proc_sync_cap_rsp(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
mcl->csp->local_caps = TRUE;
cb(mcl, mcap_err, btclockres, synclead, tmstampres, tmstampacc, NULL,
- user_data);
+ user_data);
}
static void proc_sync_set_rsp(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/2] Bluetooth: Update conf_state before send config_req out.
From: haijun liu @ 2010-09-20 1:33 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org; +Cc: dantian.ip
Update conf_state with L2CAP_CONF_REQ_SENT before send config_req out.
Signed-off-by: Haijun.Liu <Haijun.Liu@Atheros.com>
---
net/bluetooth/l2cap.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 076d1af..9d1225d 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -3164,6 +3164,7 @@ static inline int l2cap_config_req(struct
l2cap_conn *conn, struct l2cap_cmd_hdr
u8 buf[64];
+ l2cap_pi(sk)->conf_state |= L2CAP_CONF_REQ_SENT;
l2cap_send_cmd(conn, l2cap_get_ident(conn), L2CAP_CONF_REQ,
l2cap_build_conf_req(sk, buf), buf);
l2cap_pi(sk)->num_conf_req++;
}
--
1.6.3.3
--
Haijun Liu
^ 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