* Re: [PATCH] Fix hal plugin compilation error
From: Johan Hedberg @ 2011-03-04 18:52 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth, par-gunnar.p.hjalmdahl, henrik.possung
In-Reply-To: <1299144254-5405-1-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
On Thu, Mar 03, 2011, Szymon Janc wrote:
> ---
> plugins/hal.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH v5 0/6] Support for out of band association model
From: Szymon Janc @ 2011-03-04 18:51 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: linux-bluetooth@vger.kernel.org,
par-gunnar.p.hjalmdahl@stericsson.com,
henrik.possung@stericsson.com
In-Reply-To: <AANLkTinhJ2Omcj2s5Um8ARxhG1fVcwEEqH8uF-=dioMx@mail.gmail.com>
Hi,
> > Whats in the patchset:
> > - for new kernels implementation in mgmtops
> > (with kernel patches from "[PATCH v2 0/4] Support for OOB in mgmt interface")
> > - for compatibility with older kernels implementation in hciops (mimic mgmt)
> > - D-Bus plugin only exposes OOB functionality. In future we could also have
> > CreateOOB[Paired]Device (or similar) which would act as
> > AddRemoteOobData+CreateDevice.
>
> What happened to the idea of changing CreateDevice to take a
> dictionary as we discussed in irc? I guess this is the main point of
> the OOB since with this implementation any process can overwrite the
> OOB data of a remote device which is not safe, once we have OOB we
> should try to pair to check if the data is really valid. The drawback
> is that it breaks the current API but I guess we should be focusing on
> BlueZ 5.x pretty soon.
We can still have CreateDevice to take a dictionary along with 'direct' API.
Keep in mind that OOB data can be used in incoming pairing request as well so
a way to provide OOB data for that is needed too.
As for security reason we can limit access to those methods to registered agent
only but I'm not sure if that would improve security if one has already bogus
program running (i.e. it can register itself as agent, possibly after killing agent
process)
--
BR,
Szymon Janc
^ permalink raw reply
* Re: [PATCH 1/3] Replace all strdup() with g_strdup() in gatttool
From: Johan Hedberg @ 2011-03-04 18:51 UTC (permalink / raw)
To: Sheldon Demario; +Cc: linux-bluetooth
In-Reply-To: <1299105418-15795-1-git-send-email-sheldon.demario@openbossa.org>
Hi Sheldon,
On Wed, Mar 02, 2011, Sheldon Demario wrote:
> ---
> attrib/gatttool.c | 2 +-
> attrib/interactive.c | 8 ++++----
> 2 files changed, 5 insertions(+), 5 deletions(-)
All three patches are now upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Add offset option to characteristic read by handle
From: Johan Hedberg @ 2011-03-04 18:49 UTC (permalink / raw)
To: Sheldon Demario; +Cc: linux-bluetooth
In-Reply-To: <1299085748-5328-1-git-send-email-sheldon.demario@openbossa.org>
Hi Sheldon,
On Wed, Mar 02, 2011, Sheldon Demario wrote:
> Some tests require an arbitrary offset.
> ---
> attrib/client.c | 10 +++++-----
> attrib/gatt.c | 15 +++++++++++----
> attrib/gatt.h | 4 ++--
> attrib/gatttool.c | 5 ++++-
> attrib/interactive.c | 16 ++++++++++++++--
> 5 files changed, 36 insertions(+), 14 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Fix handling owner data in phonebook pull
From: Johan Hedberg @ 2011-03-04 18:46 UTC (permalink / raw)
To: Lukasz Pawlik; +Cc: linux-bluetooth
In-Reply-To: <1299072355-24766-1-git-send-email-lucas.pawlik@gmail.com>
Hi Lukasz,
On Wed, Mar 02, 2011, Lukasz Pawlik wrote:
> This patch fix handling "empty" phone owner data in phonebook pull via
> PBAP. Previously owner vCard was always present as a first on list in
> phonebook pull results even if it was empty. This patch fix this and
> owner vCard will not be present in pulled phonebook.
> ---
> plugins/phonebook-tracker.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Simplify bachk function
From: Johan Hedberg @ 2011-03-04 18:45 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth, par-gunnar.p.hjalmdahl, henrik.possung
In-Reply-To: <1299061167-8323-1-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
On Wed, Mar 02, 2011, Szymon Janc wrote:
> ---
> lib/bluetooth.c | 21 ++++++---------------
> 1 files changed, 6 insertions(+), 15 deletions(-)
Pushed upstream. Thanks. For non-trivial changes please add more
descriptive commit messages in the future (it would have saved me some
time in reviewing the patch for correctness).
Johan
^ permalink raw reply
* RE: [PATCH] pand: Fix for TP_BNEP_CTRL_BV_01_C qualification test
From: Lukasz.Rymanowski @ 2011-03-04 18:45 UTC (permalink / raw)
To: Lukasz.Rymanowski, linux-bluetooth; +Cc: par-gunnar.p.hjalmdahl, henrik.possung
In-Reply-To: <1299263709-7763-1-git-send-email-lukasz.rymanowski@tieto.com>
Please ignore this patch. I sent incorrect one.
Corrected V2.
/Lukasz
^ permalink raw reply
* [PATCH v2] pand: Fix for TP_BNEP_CTRL_BV_01_C qualification test
From: Lukasz Rymanowski @ 2011-03-04 18:41 UTC (permalink / raw)
To: linux-bluetooth; +Cc: par-gunnar.p.hjalmdahl, henrik.possung, Lukasz Rymanowski
With this fix pand will correctly respond on
unknown BNEP control command
---
compat/bnep.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/compat/bnep.c b/compat/bnep.c
index 24bf7e3..99b3ecb 100644
--- a/compat/bnep.c
+++ b/compat/bnep.c
@@ -231,6 +231,22 @@ int bnep_accept_connection(int sk, uint16_t role, char *dev)
return -1;
req = (void *) pkt;
+
+ /*
+ * Highest known Control command ID
+ * is BNEP_FILTER_MULT_ADDR_RSP = 0x06
+ */
+ if (req->type == BNEP_CONTROL &&
+ req->ctrl > BNEP_FILTER_MULT_ADDR_RSP) {
+ uint8_t pkt[3];
+ pkt[0] = BNEP_CONTROL;
+ pkt[1] = BNEP_CMD_NOT_UNDERSTOOD;
+ pkt[2] = req->ctrl;
+
+ send(sk, pkt, sizeof(*pkt), 0);
+ return -1;
+ }
+
if (req->type != BNEP_CONTROL || req->ctrl != BNEP_SETUP_CONN_REQ)
return -1;
--
1.7.0.4
On behalf ST-Ericsson
/Lukasz
^ permalink raw reply related
* Re: [PATCH] Fix adapter reference count in input plugin
From: Johan Hedberg @ 2011-03-04 18:38 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth, par-gunnar.p.hjalmdahl, henrik.possung
In-Reply-To: <1299059097-24462-1-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
On Wed, Mar 02, 2011, Szymon Janc wrote:
> Adapter unref was called on driver removal even if input server
> failed to start on probe and reference was not incremented. This leads
> to segmentation fault while removing adapter.
> ---
> input/manager.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/input/manager.c b/input/manager.c
> index a98a080..259aef7 100644
> --- a/input/manager.c
> +++ b/input/manager.c
> @@ -143,6 +143,9 @@ static void hid_server_remove(struct btd_adapter *adapter)
> {
> bdaddr_t src;
>
> + if (!g_slist_find(adapters, adapter))
> + return;
> +
> adapter_get_address(adapter, &src);
>
> server_stop(&src);
This one looks like it's working around the core issue instead of fixing
it. The _remove function shouldn't get called if _probe failed. I.e. the
issue seems to be somewhere in the core daemon.
Johan
^ permalink raw reply
* Re: [PATCH v2] Implement ATT handle indications
From: Elvis Pfützenreuter @ 2011-03-04 18:36 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1298646072-28812-1-git-send-email-epx@signove.com>
Just a reminder that this patch needs review.
On 25 Feb 2011, at 12:01 , Elvis Pfützenreuter wrote:
> ---
> src/attrib-server.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 69 insertions(+), 0 deletions(-)
>
> diff --git a/src/attrib-server.c b/src/attrib-server.c
> index 5f645bb..f683707 100644
> --- a/src/attrib-server.c
> +++ b/src/attrib-server.c
> @@ -54,6 +54,8 @@ struct gatt_channel {
> GSList *configs;
> GSList *notify;
> GSList *indicate;
> + gboolean outstanding_indication;
> + GSList *pending_indications;
> GAttrib *attrib;
> guint mtu;
> guint id;
> @@ -770,12 +772,58 @@ static void channel_disconnect(void *user_data)
>
> g_slist_free(channel->notify);
> g_slist_free(channel->indicate);
> + g_slist_free(channel->pending_indications);
> g_slist_foreach(channel->configs, (GFunc) g_free, NULL);
> g_slist_free(channel->configs);
>
> g_free(channel);
> }
>
> +static void attrib_resume_indications(struct gatt_channel *channel);
> +
> +static void attrib_indicate_client_cb(guint8 status, const guint8 *pdu,
> + guint16 len, gpointer user_data)
> +{
> + struct gatt_channel *channel = user_data;
> +
> + if (status)
> + return;
> +
> + attrib_resume_indications(channel);
> +}
> +
> +static void attrib_indicate_client(struct gatt_channel *channel,
> + struct attribute *attr)
> +{
> + uint8_t pdu[ATT_MAX_MTU];
> + uint16_t len;
> +
> + len = enc_indication(attr, pdu, channel->mtu);
> + if (len == 0)
> + return;
> +
> + channel->outstanding_indication = TRUE;
> +
> + g_attrib_send(channel->attrib, 0, pdu[0], pdu, len,
> + attrib_indicate_client_cb, channel, NULL);
> +}
> +
> +static void attrib_resume_indications(struct gatt_channel *channel)
> +{
> + struct attribute *a;
> +
> + channel->outstanding_indication = FALSE;
> +
> + if (!channel->pending_indications)
> + return;
> +
> + a = channel->pending_indications->data;
> + channel->pending_indications =
> + g_slist_remove(channel->pending_indications, a);
> +
> + attrib_indicate_client(channel, a);
> +}
> +
> static void channel_handler(const uint8_t *ipdu, uint16_t len,
> gpointer user_data)
> {
> @@ -872,6 +920,8 @@ static void channel_handler(const uint8_t *ipdu, uint16_t len,
> length = find_by_type(start, end, &uuid, value, vlen,
> opdu, channel->mtu);
> break;
> + case ATT_OP_HANDLE_CNF:
> + return;
> case ATT_OP_READ_MULTI_REQ:
> case ATT_OP_PREP_WRITE_REQ:
> case ATT_OP_EXEC_WRITE_REQ:
> @@ -948,6 +998,15 @@ static void confirm_event(GIOChannel *io, void *user_data)
> return;
> }
>
> +static void attrib_sched_indication(struct gatt_channel *channel,
> + struct attribute *a)
> +{
> + if (!g_slist_find_custom(channel->pending_indications, a,
> + attribute_cmp))
> + channel->pending_indications =
> + g_slist_append(channel->pending_indications, a);
> +}
> +
> static void attrib_notify_clients(struct attribute *attr)
> {
> guint handle = attr->handle;
> @@ -969,6 +1028,15 @@ static void attrib_notify_clients(struct attribute *attr)
> g_attrib_send(channel->attrib, 0, pdu[0], pdu, len,
> NULL, NULL, NULL);
> }
> +
> + /* Indication */
> + if (g_slist_find_custom(channel->indicate,
> + GUINT_TO_POINTER(handle), handle_cmp) != NULL) {
> + if (channel->outstanding_indication)
> + attrib_sched_indication(channel, attr);
> + else
> + attrib_indicate_client(channel, attr);
> + }
> }
> }
>
> @@ -1111,6 +1179,7 @@ void attrib_server_exit(void)
>
> g_slist_free(channel->notify);
> g_slist_free(channel->indicate);
> + g_slist_free(channel->pending_indications);
> g_slist_foreach(channel->configs, (GFunc) g_free, NULL);
> g_slist_free(channel->configs);
>
> --
> 1.7.1
>
^ permalink raw reply
* [PATCH] pand: Fix for TP_BNEP_CTRL_BV_01_C qualification test
From: Lukasz Rymanowski @ 2011-03-04 18:35 UTC (permalink / raw)
To: linux-bluetooth; +Cc: par-gunnar.p.hjalmdahl, henrik.possung, Lukasz Rymanowski
With this fix pand will correctly respond on
unknown BNEP control command
---
compat/bnep.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/compat/bnep.c b/compat/bnep.c
index 24bf7e3..1d02ea7 100644
--- a/compat/bnep.c
+++ b/compat/bnep.c
@@ -231,6 +231,22 @@ int bnep_accept_connection(int sk, uint16_t role, char *dev)
return -1;
req = (void *) pkt;
+
+ /*
+ * Highest known Control command ID
+ * is BNEP_FILTER_MULT_ADDR_RSP = 0x06
+ */
+ iif (req->type == BNEP_CONTROL &&
+ req->ctrl > BNEP_FILTER_MULT_ADDR_RSP) {
+ __u8 pkt[3];
+ pkt[0] = BNEP_CONTROL;
+ pkt[1] = BNEP_CMD_NOT_UNDERSTOOD;
+ pkt[2] = cmd;
+
+ send(sk, pkt, sizeof(*pkt), 0);
+ return -1;
+ }
+
if (req->type != BNEP_CONTROL || req->ctrl != BNEP_SETUP_CONN_REQ)
return -1;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v3] Fix response on adapter RequestSession method
From: Johan Hedberg @ 2011-03-04 18:34 UTC (permalink / raw)
To: Dmitriy Paliy; +Cc: linux-bluetooth, luiz.dentz, anderson.lizardo
In-Reply-To: <1299054257-15806-2-git-send-email-dmitriy.paliy@nokia.com>
Hi Dmitriy,
On Wed, Mar 02, 2011, Dmitriy Paliy wrote:
> Fixes response on adapter RequestSession method to be sent after mode
> is changed, if such is necessary. More specifically, change of power
> off mode to power on is in question.
>
> Currently response is sent when mode change is confirmed by agent, not
> by response from controller. Such may lead to failed CreateDevice
> method if it is called quickly enough after RequestSession when
> controller is in powered off state.
>
> New session is not created if there is already a session for such
> D-Bus message.
> ---
> src/adapter.c | 52 +++++++++++++++++++++++++++++++++++++++++-----------
> 1 files changed, 41 insertions(+), 11 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* [PATCH 4/4] Make strtoba use str2ba for string conversion
From: Szymon Janc @ 2011-03-04 18:34 UTC (permalink / raw)
To: linux-bluetooth; +Cc: par-gunnar.p.hjalmdahl, henrik.possung, Szymon Janc
In-Reply-To: <1299263645-25329-1-git-send-email-szymon.janc@tieto.com>
---
lib/bluetooth.c | 18 ++++++------------
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/lib/bluetooth.c b/lib/bluetooth.c
index d943fdc..aac9bdc 100644
--- a/lib/bluetooth.c
+++ b/lib/bluetooth.c
@@ -63,21 +63,15 @@ char *batostr(const bdaddr_t *ba)
bdaddr_t *strtoba(const char *str)
{
- const char *ptr = str;
- int i;
-
- uint8_t *ba = bt_malloc(sizeof(bdaddr_t));
- if (!ba)
- return NULL;
+ bdaddr_t b;
+ bdaddr_t *ba = bt_malloc(sizeof(*ba));
- for (i = 0; i < 6; i++) {
- ba[i] = (uint8_t) strtol(ptr, NULL, 16);
- if (i != 5 && !(ptr = strchr(ptr,':')))
- ptr = ":00:00:00:00:00";
- ptr++;
+ if (ba) {
+ str2ba(str, &b);
+ baswap(ba, &b);
}
- return (bdaddr_t *) ba;
+ return ba;
}
int ba2str(const bdaddr_t *ba, char *str)
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/4] Fix str2ba behaviour on malformed bt address
From: Szymon Janc @ 2011-03-04 18:34 UTC (permalink / raw)
To: linux-bluetooth; +Cc: par-gunnar.p.hjalmdahl, henrik.possung, Szymon Janc
In-Reply-To: <1299263645-25329-1-git-send-email-szymon.janc@tieto.com>
str2ba could create bogus bt address from malformed string. Return
all zeros bt address on malformed string.
---
lib/bluetooth.c | 15 +++++++--------
1 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/lib/bluetooth.c b/lib/bluetooth.c
index f51e310..d943fdc 100644
--- a/lib/bluetooth.c
+++ b/lib/bluetooth.c
@@ -88,19 +88,18 @@ int ba2str(const bdaddr_t *ba, char *str)
int str2ba(const char *str, bdaddr_t *ba)
{
- uint8_t b[6];
- const char *ptr = str;
+ bdaddr_t b;
int i;
- for (i = 0; i < 6; i++) {
- b[i] = (uint8_t) strtol(ptr, NULL, 16);
- if (i != 5 && !(ptr = strchr(ptr, ':')))
- ptr = ":00:00:00:00:00";
- ptr++;
+ if (bachk(str) < 0) {
+ memset(ba, 0, sizeof(*ba));
+ return -1;
}
- baswap(ba, (bdaddr_t *) b);
+ for (i = 0; i < 6; i++, str += 3)
+ b.b[i] = strtol(str, NULL, 16);
+ baswap(ba, &b);
return 0;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/4] Simplify ba2str function
From: Szymon Janc @ 2011-03-04 18:34 UTC (permalink / raw)
To: linux-bluetooth; +Cc: par-gunnar.p.hjalmdahl, henrik.possung, Szymon Janc
In-Reply-To: <1299263645-25329-1-git-send-email-szymon.janc@tieto.com>
---
lib/bluetooth.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/lib/bluetooth.c b/lib/bluetooth.c
index d064f9e..f51e310 100644
--- a/lib/bluetooth.c
+++ b/lib/bluetooth.c
@@ -82,11 +82,8 @@ bdaddr_t *strtoba(const char *str)
int ba2str(const bdaddr_t *ba, char *str)
{
- uint8_t b[6];
-
- baswap((bdaddr_t *) b, ba);
return sprintf(str, "%2.2X:%2.2X:%2.2X:%2.2X:%2.2X:%2.2X",
- b[0], b[1], b[2], b[3], b[4], b[5]);
+ ba->b[5], ba->b[4], ba->b[3], ba->b[2], ba->b[1], ba->b[0]);
}
int str2ba(const char *str, bdaddr_t *ba)
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/4] Simplify ba2oui function
From: Szymon Janc @ 2011-03-04 18:34 UTC (permalink / raw)
To: linux-bluetooth; +Cc: par-gunnar.p.hjalmdahl, henrik.possung, Szymon Janc
In-Reply-To: <1299263645-25329-1-git-send-email-szymon.janc@tieto.com>
---
lib/bluetooth.c | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/lib/bluetooth.c b/lib/bluetooth.c
index 875119b..d064f9e 100644
--- a/lib/bluetooth.c
+++ b/lib/bluetooth.c
@@ -109,11 +109,7 @@ int str2ba(const char *str, bdaddr_t *ba)
int ba2oui(const bdaddr_t *ba, char *str)
{
- uint8_t b[6];
-
- baswap((bdaddr_t *) b, ba);
-
- return sprintf(str, "%2.2X-%2.2X-%2.2X", b[0], b[1], b[2]);
+ return sprintf(str, "%2.2X-%2.2X-%2.2X", ba->b[5], ba->b[4], ba->b[3]);
}
int bachk(const char *str)
--
1.7.0.4
^ permalink raw reply related
* [PATCH 0/4] Some small bluetooth.c cleanups and fixes
From: Szymon Janc @ 2011-03-04 18:34 UTC (permalink / raw)
To: linux-bluetooth; +Cc: par-gunnar.p.hjalmdahl, henrik.possung, Szymon Janc
Along with "[PATCH] Simplify bachk function" these patches make bluetooth.c
a little nicer.
BR,
Szymon Janc
on behalf of ST-Ericsson
Szymon Janc (4):
Simplify ba2oui function
Simplify ba2str function
Fix str2ba behaviour on malformed bt address
Make strtoba use str2ba for string conversion
lib/bluetooth.c | 44 +++++++++++++++-----------------------------
1 files changed, 15 insertions(+), 29 deletions(-)
^ permalink raw reply
* [PATCH] Remove duplicated NULL check and debug message
From: Szymon Janc @ 2011-03-04 18:33 UTC (permalink / raw)
To: linux-bluetooth; +Cc: par-gunnar.p.hjalmdahl, henrik.possung, Szymon Janc
---
src/sdpd-request.c | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/src/sdpd-request.c b/src/sdpd-request.c
index 668e190..1722f78 100644
--- a/src/sdpd-request.c
+++ b/src/sdpd-request.c
@@ -557,17 +557,13 @@ static int extract_attrs(sdp_record_t *rec, sdp_list_t *seq, sdp_buf_t *buf)
if (!rec)
return SDP_INVALID_RECORD_HANDLE;
- if (seq) {
- SDPDBG("Entries in attr seq : %d", sdp_list_len(seq));
- } else {
- SDPDBG("NULL attribute descriptor");
- }
-
if (seq == NULL) {
SDPDBG("Attribute sequence is NULL");
return 0;
}
+ SDPDBG("Entries in attr seq : %d", sdp_list_len(seq));
+
sdp_gen_record_pdu(rec, &pdu);
for (; seq; seq = seq->next) {
--
1.7.0.4
on behalf of ST-Ericsson
^ permalink raw reply related
* [PATCH] Fix small memleak in hciemu
From: Szymon Janc @ 2011-03-04 18:32 UTC (permalink / raw)
To: linux-bluetooth; +Cc: par-gunnar.p.hjalmdahl, henrik.possung, Szymon Janc
---
test/hciemu.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/test/hciemu.c b/test/hciemu.c
index 5227766..9eed9d9 100644
--- a/test/hciemu.c
+++ b/test/hciemu.c
@@ -1023,7 +1023,7 @@ static int getbdaddrbyname(char *str, bdaddr_t *ba)
if (n == 5) {
/* BD address */
- baswap(ba, strtoba(str));
+ str2ba(str, ba);
return 0;
}
--
1.7.0.4
on behalf of ST-Ericsson
^ permalink raw reply related
* Re: [PATCH 1/5] Add new UUID utility functions
From: Elvis Pfützenreuter @ 2011-03-04 18:32 UTC (permalink / raw)
To: Brian Gix; +Cc: linux-bluetooth, Claudio Takahasi
In-Reply-To: <4D712A3D.6090402@codeaurora.org>
Hi Brian,
On 4 Mar 2011, at 15:06 , Brian Gix wrote:
> Hi Elvis,
>
> I'm trying to understand the problem being addressed by these patches. I am guessing that there is a difference in behaviour between little endian and big endian architectures, but I still question some of the changes.
>
> One example below.
>
> On 11-03-04 08:20 AM, Elvis Pfützenreuter wrote:
> [...]
>> +
>> +#if __BYTE_ORDER == __BIG_ENDIAN
>> +static uint128_t bluetooth_base_uuid = {
>> + .data = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00,
>> + 0x80, 0x00, 0x00, 0x80, 0x5F, 0x9B, 0x34, 0xFB }
>> +};
>> +
>> +#define BASE_UUID16_OFFSET 2
>> +#define BASE_UUID32_OFFSET 0
>> +
>> +#else
>> +static uint128_t bluetooth_base_uuid = {
>> + .data = { 0xFB, 0x34, 0x9B, 0x5F, 0x80, 0x00, 0x00, 0x80,
>> + 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }
>> +};
>> +
>> +#define BASE_UUID16_OFFSET 12
>> +#define BASE_UUID32_OFFSET BASE_UUID16_OFFSET
>> +
>> +#endif
>> +
>> +static void bt_uuid16_to_uuid128(const bt_uuid_t *uuid16, bt_uuid_t *uuid128)
>> +{
>> + uint16_t data;
>> +
>> + uuid128->value.u128 = bluetooth_base_uuid;
>> + uuid128->type = BT_UUID128;
>> +
>> + memcpy(&data,&bluetooth_base_uuid.data[BASE_UUID16_OFFSET], 2);
>
> This line should always be copying Zero, and so more directly should be data = 0; These appear to be bluetooth specific, so the 4 MSBs of the base are Zero by definition.
>
>> + data += uuid16->value.u16;
>
> Given the above line, this would become "data = uuid16->value.16", and the other eliminated.
Perhaps we were a bit precious here :)
>
>> +
>> + memcpy(&uuid128->value.u128.data[BASE_UUID16_OFFSET],&data, 2);
>
> I don't believe this line to be always portable between platforms. This line makes the assumption that a uint16_t is two native units (not always true) and can therefore be directly memcopy'd into into an array of uint8_t array members. This is not always true. memcpy should never be used in portable code when packing data for network datagram usage models (anything that treats data as an octet stream).
If we had used "unsigned char" and "unsigned short int", I'd agree, but uint8_t and uint16_t are *explicitly* 8-bit and 16-bit types, and thus there is a guaranteed 2:1 size relationship.
>
> I am not saying I agree with the need to store UUIDs in anything but network order, however if I were to write a portable function that will always work in this instance, I would eliminate all usage of memcpy here and do something like:
>
> uuid128->value.u128.data[SHORT_UUID_LE_0] = (uint8_t) data;
> uuid128->value.u128.data[SHORT_UUID_LE_1] = (uint8_t) (data >> 8);
>
> And likewise for uuid32 to uui128:
> uuid128->value.u128.data[SHORT_UUID_LE_2] = (uint8_t) (data >> 16);
> uuid128->value.u128.data[SHORT_UUID_LE_3] = (uint8_t) (data >> 24);
I don't feel it's any better. This is Claudio's style, I'd prefer something like
*((uint16_t* ) &uuid128->value.u128.data[BASE_UUID16_OFFSET]) = data;
>
>
> Where depending on the endian, SHORT_UUID_LE_0 thru SHORT_UUID_LE_3 would be defined as 3 thru 0 for Big Endian storage, and 12 thru 15 for Little Endian storage.
>
> This is guaranteed to put the desired octet into it's correct position within the uuid128's data array, while it could not be guaranteed across platforms with memcpy.
>
>> +}
>
>
> Regards,
>
> --
> Brian Gix
> bgix@codeaurora.org
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* [PATCH] Fix small memleak in compat/pand.c
From: Szymon Janc @ 2011-03-04 18:32 UTC (permalink / raw)
To: linux-bluetooth; +Cc: par-gunnar.p.hjalmdahl, henrik.possung, Szymon Janc
---
compat/pand.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/compat/pand.c b/compat/pand.c
index c3860fa..b82650e 100644
--- a/compat/pand.c
+++ b/compat/pand.c
@@ -456,10 +456,13 @@ static void do_show(void)
static void do_kill(char *dst)
{
- if (dst)
- bnep_kill_connection((void *) strtoba(dst));
- else
+ if (dst) {
+ bdaddr_t *ba = strtoba(dst);
+ bnep_kill_connection((void *) ba);
+ free(ba);
+ } else {
bnep_kill_all_connections();
+ }
}
static void sig_hup(int sig)
--
1.7.0.4
on behalf of ST-Ericsson
^ permalink raw reply related
* Re: [PATCH v5 0/6] Support for out of band association model
From: Luiz Augusto von Dentz @ 2011-03-04 18:17 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth, par-gunnar.p.hjalmdahl, henrik.possung
In-Reply-To: <1299251315-2041-1-git-send-email-szymon.janc@tieto.com>
Hi,
On Fri, Mar 4, 2011 at 12:08 PM, Szymon Janc <szymon.janc@tieto.com> wrote:
> Significant change since last version is that oob data is now fed to kernel (or
> hciops) and is used while pairing if needed. No need for requesting
> providers/agent while pairing. Advantage is less roundtrips and much simpler
> implementation.
>
> Whats in the patchset:
> - for new kernels implementation in mgmtops
> (with kernel patches from "[PATCH v2 0/4] Support for OOB in mgmt interface")
> - for compatibility with older kernels implementation in hciops (mimic mgmt)
> - D-Bus plugin only exposes OOB functionality. In future we could also have
> CreateOOB[Paired]Device (or similar) which would act as
> AddRemoteOobData+CreateDevice.
What happened to the idea of changing CreateDevice to take a
dictionary as we discussed in irc? I guess this is the main point of
the OOB since with this implementation any process can overwrite the
OOB data of a remote device which is not safe, once we have OOB we
should try to pair to check if the data is really valid. The drawback
is that it breaks the current API but I guess we should be focusing on
BlueZ 5.x pretty soon.
> As usual, comments are welcome.
>
>
> BR,
> Szymon Janc
> on behalf of ST-Ericsson
>
>
> Szymon Janc (6):
> Add initial support for Out of Band (OOB) association model
> Add support for Out of Band (OOB) association model in mgmtops
> Add support for Out of Band (OOB) association model in hciops
> Add D-Bus OOB plugin
> Update mgmt-api.txt with OOB commands
> Add oob-api.txt with documentation about OOB D-Bus methods
>
> Makefile.am | 8 ++-
> acinclude.m4 | 6 ++
> doc/mgmt-api.txt | 30 +++++++
> doc/oob-api.txt | 38 +++++++++
> lib/mgmt.h | 18 ++++
> plugins/dbusoob.c | 241 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> plugins/hciops.c | 143 ++++++++++++++++++++++++++++++-
> plugins/mgmtops.c | 127 ++++++++++++++++++++++++++++
> src/adapter.c | 18 ++++
> src/adapter.h | 12 +++
> src/oob.c | 43 ++++++++++
> src/oob.h | 30 +++++++
> 12 files changed, 708 insertions(+), 6 deletions(-)
> create mode 100644 doc/oob-api.txt
> create mode 100644 plugins/dbusoob.c
> create mode 100644 src/oob.c
> create mode 100644 src/oob.h
>
> --
> 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
>
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: [PATCH 1/5] Add new UUID utility functions
From: Brian Gix @ 2011-03-04 18:06 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: linux-bluetooth, Claudio Takahasi
In-Reply-To: <1299255640-13599-1-git-send-email-epx@signove.com>
Hi Elvis,
I'm trying to understand the problem being addressed by these patches. I
am guessing that there is a difference in behaviour between little
endian and big endian architectures, but I still question some of the
changes.
One example below.
On 11-03-04 08:20 AM, Elvis Pfützenreuter wrote:
[...]
> +
> +#if __BYTE_ORDER == __BIG_ENDIAN
> +static uint128_t bluetooth_base_uuid = {
> + .data = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00,
> + 0x80, 0x00, 0x00, 0x80, 0x5F, 0x9B, 0x34, 0xFB }
> +};
> +
> +#define BASE_UUID16_OFFSET 2
> +#define BASE_UUID32_OFFSET 0
> +
> +#else
> +static uint128_t bluetooth_base_uuid = {
> + .data = { 0xFB, 0x34, 0x9B, 0x5F, 0x80, 0x00, 0x00, 0x80,
> + 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }
> +};
> +
> +#define BASE_UUID16_OFFSET 12
> +#define BASE_UUID32_OFFSET BASE_UUID16_OFFSET
> +
> +#endif
> +
> +static void bt_uuid16_to_uuid128(const bt_uuid_t *uuid16, bt_uuid_t *uuid128)
> +{
> + uint16_t data;
> +
> + uuid128->value.u128 = bluetooth_base_uuid;
> + uuid128->type = BT_UUID128;
> +
> + memcpy(&data,&bluetooth_base_uuid.data[BASE_UUID16_OFFSET], 2);
This line should always be copying Zero, and so more directly should be
data = 0; These appear to be bluetooth specific, so the 4 MSBs of the
base are Zero by definition.
> + data += uuid16->value.u16;
Given the above line, this would become "data = uuid16->value.16", and
the other eliminated.
> +
> + memcpy(&uuid128->value.u128.data[BASE_UUID16_OFFSET],&data, 2);
I don't believe this line to be always portable between platforms. This
line makes the assumption that a uint16_t is two native units (not
always true) and can therefore be directly memcopy'd into into an array
of uint8_t array members. This is not always true. memcpy should never
be used in portable code when packing data for network datagram usage
models (anything that treats data as an octet stream).
I am not saying I agree with the need to store UUIDs in anything but
network order, however if I were to write a portable function that will
always work in this instance, I would eliminate all usage of memcpy here
and do something like:
uuid128->value.u128.data[SHORT_UUID_LE_0] = (uint8_t) data;
uuid128->value.u128.data[SHORT_UUID_LE_1] = (uint8_t) (data >> 8);
And likewise for uuid32 to uui128:
uuid128->value.u128.data[SHORT_UUID_LE_2] = (uint8_t) (data >> 16);
uuid128->value.u128.data[SHORT_UUID_LE_3] = (uint8_t) (data >> 24);
Where depending on the endian, SHORT_UUID_LE_0 thru SHORT_UUID_LE_3
would be defined as 3 thru 0 for Big Endian storage, and 12 thru 15 for
Little Endian storage.
This is guaranteed to put the desired octet into it's correct position
within the uuid128's data array, while it could not be guaranteed across
platforms with memcpy.
> +}
Regards,
--
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* hci_conn_timeout
From: Koustuv Ghosh @ 2011-03-04 17:47 UTC (permalink / raw)
To: linux-bluetooth
Hello ,
I am using vcgomes kernel for LE .
I observed two thing...
once I issue LE connect via gatttool from my host , after 2 or 3s I
am geeting a hci_conn_timeout, which causes existing LE connection
disconnected.
So I noticed there is a hci_conn_hold(conn) which I feel basically
deactivate the timer, and as a work around I introduced it in
hci_le_conn_complete_evt ,and after that disconnect time out does
not occur.
But then if I am trying to connect remote device via gatttool with
same parameter twice , system hangs.
Any help...
rgds
Koustuv
^ permalink raw reply
* [PATCH 5/5] Use new UUID functions in example GATT server
From: Elvis Pfützenreuter @ 2011-03-04 16:20 UTC (permalink / raw)
To: linux-bluetooth; +Cc: epx
In-Reply-To: <1299255640-13599-1-git-send-email-epx@signove.com>
---
attrib/example.c | 92 ++++++++++++++++++++++++++++--------------------------
1 files changed, 48 insertions(+), 44 deletions(-)
diff --git a/attrib/example.c b/attrib/example.c
index 395650a..fae288c 100644
--- a/attrib/example.c
+++ b/attrib/example.c
@@ -29,8 +29,7 @@
#include <arpa/inet.h>
-#include <bluetooth/sdp.h>
-#include <bluetooth/sdp_lib.h>
+#include <bluetooth/uuid.h>
#include <glib.h>
@@ -70,36 +69,41 @@ static int register_attributes(void)
const char *manufacturer_name2 = "ACME Weighing Scales";
const char *serial1 = "237495-3282-A";
const char *serial2 = "11267-2327A00239";
- const unsigned char char_weight_uuid[] = { 0x80, 0x88, 0xF2, 0x18, 0x90,
- 0x2C, 0x45, 0x0B, 0xB6, 0xC4, 0x62, 0x89, 0x1E, 0x8C, 0x25,
- 0xE9 };
- const unsigned char prim_weight_uuid[] = { 0x4F, 0x0A, 0xC0, 0x96, 0x35,
- 0xD4, 0x49, 0x11, 0x96, 0x31, 0xDE, 0xA8, 0xDC, 0x74, 0xEE,
- 0xFE };
+
+ const uint128_t char_weight_uuid_btorder = {
+ .data = { 0x80, 0x88, 0xF2, 0x18, 0x90, 0x2C, 0x45, 0x0B,
+ 0xB6, 0xC4, 0x62, 0x89, 0x1E, 0x8C, 0x25, 0xE9 } };
+ const uint128_t prim_weight_uuid_btorder = {
+ .data = { 0x4F, 0x0A, 0xC0, 0x96, 0x35, 0xD4, 0x49, 0x11,
+ 0x96, 0x31, 0xDE, 0xA8, 0xDC, 0x74, 0xEE, 0xFE } };
+
+ uint128_t char_weight_uuid;
uint8_t atval[256];
uint32_t handle;
- uuid_t uuid;
+ bt_uuid_t uuid;
int len;
+ btoh128(&char_weight_uuid_btorder, &char_weight_uuid);
+
/* Battery state service: primary service definition */
- sdp_uuid16_create(&uuid, GATT_PRIM_SVC_UUID);
+ bt_uuid16_create(&uuid, GATT_PRIM_SVC_UUID);
att_put_u16(BATTERY_STATE_SVC_UUID, &atval[0]);
attrib_db_add(0x0100, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 2);
/* Battery: battery state characteristic */
- sdp_uuid16_create(&uuid, GATT_CHARAC_UUID);
+ bt_uuid16_create(&uuid, GATT_CHARAC_UUID);
atval[0] = ATT_CHAR_PROPER_READ;
att_put_u16(0x0110, &atval[1]);
att_put_u16(BATTERY_STATE_UUID, &atval[3]);
attrib_db_add(0x0106, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 5);
/* Battery: battery state attribute */
- sdp_uuid16_create(&uuid, BATTERY_STATE_UUID);
+ bt_uuid16_create(&uuid, BATTERY_STATE_UUID);
atval[0] = 0x04;
attrib_db_add(0x0110, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 1);
/* Battery: Client Characteristic Configuration */
- sdp_uuid16_create(&uuid, GATT_CLIENT_CHARAC_CFG_UUID);
+ bt_uuid16_create(&uuid, GATT_CLIENT_CHARAC_CFG_UUID);
atval[0] = 0x00;
atval[1] = 0x00;
attrib_db_add(0x0111, &uuid, ATT_NONE, ATT_AUTHENTICATION, atval, 2);
@@ -110,12 +114,12 @@ static int register_attributes(void)
sdp_handles = g_slist_prepend(sdp_handles, GUINT_TO_POINTER(handle));
/* Thermometer: primary service definition */
- sdp_uuid16_create(&uuid, GATT_PRIM_SVC_UUID);
+ bt_uuid16_create(&uuid, GATT_PRIM_SVC_UUID);
att_put_u16(THERM_HUMIDITY_SVC_UUID, &atval[0]);
attrib_db_add(0x0200, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 2);
/* Thermometer: Include */
- sdp_uuid16_create(&uuid, GATT_INCLUDE_UUID);
+ bt_uuid16_create(&uuid, GATT_INCLUDE_UUID);
att_put_u16(0x0500, &atval[0]);
att_put_u16(0x0504, &atval[2]);
att_put_u16(MANUFACTURER_SVC_UUID, &atval[4]);
@@ -128,20 +132,20 @@ static int register_attributes(void)
attrib_db_add(0x0202, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 6);
/* Thermometer: temperature characteristic */
- sdp_uuid16_create(&uuid, GATT_CHARAC_UUID);
+ bt_uuid16_create(&uuid, GATT_CHARAC_UUID);
atval[0] = ATT_CHAR_PROPER_READ;
att_put_u16(0x0204, &atval[1]);
att_put_u16(TEMPERATURE_UUID, &atval[3]);
attrib_db_add(0x0203, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 5);
/* Thermometer: temperature characteristic value */
- sdp_uuid16_create(&uuid, TEMPERATURE_UUID);
+ bt_uuid16_create(&uuid, TEMPERATURE_UUID);
atval[0] = 0x8A;
atval[1] = 0x02;
attrib_db_add(0x0204, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 2);
/* Thermometer: temperature characteristic format */
- sdp_uuid16_create(&uuid, GATT_CHARAC_FMT_UUID);
+ bt_uuid16_create(&uuid, GATT_CHARAC_FMT_UUID);
atval[0] = 0x0E;
atval[1] = 0xFE;
att_put_u16(FMT_CELSIUS_UUID, &atval[2]);
@@ -150,25 +154,25 @@ static int register_attributes(void)
attrib_db_add(0x0205, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 7);
/* Thermometer: characteristic user description */
- sdp_uuid16_create(&uuid, GATT_CHARAC_USER_DESC_UUID);
+ bt_uuid16_create(&uuid, GATT_CHARAC_USER_DESC_UUID);
len = strlen(desc_out_temp);
strncpy((char *) atval, desc_out_temp, len);
attrib_db_add(0x0206, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, len);
/* Thermometer: relative humidity characteristic */
- sdp_uuid16_create(&uuid, GATT_CHARAC_UUID);
+ bt_uuid16_create(&uuid, GATT_CHARAC_UUID);
atval[0] = ATT_CHAR_PROPER_READ;
att_put_u16(0x0212, &atval[1]);
att_put_u16(RELATIVE_HUMIDITY_UUID, &atval[3]);
attrib_db_add(0x0210, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 5);
/* Thermometer: relative humidity value */
- sdp_uuid16_create(&uuid, RELATIVE_HUMIDITY_UUID);
+ bt_uuid16_create(&uuid, RELATIVE_HUMIDITY_UUID);
atval[0] = 0x27;
attrib_db_add(0x0212, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 1);
/* Thermometer: relative humidity characteristic format */
- sdp_uuid16_create(&uuid, GATT_CHARAC_FMT_UUID);
+ bt_uuid16_create(&uuid, GATT_CHARAC_FMT_UUID);
atval[0] = 0x04;
atval[1] = 0x00;
att_put_u16(FMT_PERCENT_UUID, &atval[2]);
@@ -177,7 +181,7 @@ static int register_attributes(void)
attrib_db_add(0x0213, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 8);
/* Thermometer: characteristic user description */
- sdp_uuid16_create(&uuid, GATT_CHARAC_USER_DESC_UUID);
+ bt_uuid16_create(&uuid, GATT_CHARAC_USER_DESC_UUID);
len = strlen(desc_out_hum);
strncpy((char *) atval, desc_out_hum, len);
attrib_db_add(0x0214, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, len);
@@ -188,62 +192,62 @@ static int register_attributes(void)
sdp_handles = g_slist_prepend(sdp_handles, GUINT_TO_POINTER(handle));
/* Secondary Service: Manufacturer Service */
- sdp_uuid16_create(&uuid, GATT_SND_SVC_UUID);
+ bt_uuid16_create(&uuid, GATT_SND_SVC_UUID);
att_put_u16(MANUFACTURER_SVC_UUID, &atval[0]);
attrib_db_add(0x0500, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 2);
/* Manufacturer name characteristic definition */
- sdp_uuid16_create(&uuid, GATT_CHARAC_UUID);
+ bt_uuid16_create(&uuid, GATT_CHARAC_UUID);
atval[0] = ATT_CHAR_PROPER_READ;
att_put_u16(0x0502, &atval[1]);
att_put_u16(MANUFACTURER_NAME_UUID, &atval[3]);
attrib_db_add(0x0501, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 5);
/* Manufacturer name characteristic value */
- sdp_uuid16_create(&uuid, MANUFACTURER_NAME_UUID);
+ bt_uuid16_create(&uuid, MANUFACTURER_NAME_UUID);
len = strlen(manufacturer_name1);
strncpy((char *) atval, manufacturer_name1, len);
attrib_db_add(0x0502, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, len);
/* Manufacturer serial number characteristic */
- sdp_uuid16_create(&uuid, GATT_CHARAC_UUID);
+ bt_uuid16_create(&uuid, GATT_CHARAC_UUID);
atval[0] = ATT_CHAR_PROPER_READ;
att_put_u16(0x0504, &atval[1]);
att_put_u16(MANUFACTURER_SERIAL_UUID, &atval[3]);
attrib_db_add(0x0503, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 5);
/* Manufacturer serial number characteristic value */
- sdp_uuid16_create(&uuid, MANUFACTURER_SERIAL_UUID);
+ bt_uuid16_create(&uuid, MANUFACTURER_SERIAL_UUID);
len = strlen(serial1);
strncpy((char *) atval, serial1, len);
attrib_db_add(0x0504, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, len);
/* Secondary Service: Manufacturer Service */
- sdp_uuid16_create(&uuid, GATT_SND_SVC_UUID);
+ bt_uuid16_create(&uuid, GATT_SND_SVC_UUID);
att_put_u16(MANUFACTURER_SVC_UUID, &atval[0]);
attrib_db_add(0x0505, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 2);
/* Manufacturer name characteristic definition */
- sdp_uuid16_create(&uuid, GATT_CHARAC_UUID);
+ bt_uuid16_create(&uuid, GATT_CHARAC_UUID);
atval[0] = ATT_CHAR_PROPER_READ;
att_put_u16(0x0507, &atval[1]);
att_put_u16(MANUFACTURER_NAME_UUID, &atval[3]);
attrib_db_add(0x0506, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 5);
/* Secondary Service: Vendor Specific Service */
- sdp_uuid16_create(&uuid, GATT_SND_SVC_UUID);
+ bt_uuid16_create(&uuid, GATT_SND_SVC_UUID);
att_put_u16(VENDOR_SPECIFIC_SVC_UUID, &atval[0]);
attrib_db_add(0x0550, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 2);
/* Vendor Specific Type characteristic definition */
- sdp_uuid16_create(&uuid, GATT_CHARAC_UUID);
+ bt_uuid16_create(&uuid, GATT_CHARAC_UUID);
atval[0] = ATT_CHAR_PROPER_READ;
att_put_u16(0x0568, &atval[1]);
att_put_u16(VENDOR_SPECIFIC_TYPE_UUID, &atval[3]);
attrib_db_add(0x0560, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 5);
/* Vendor Specific Type characteristic value */
- sdp_uuid16_create(&uuid, VENDOR_SPECIFIC_TYPE_UUID);
+ bt_uuid16_create(&uuid, VENDOR_SPECIFIC_TYPE_UUID);
atval[0] = 0x56;
atval[1] = 0x65;
atval[2] = 0x6E;
@@ -253,45 +257,45 @@ static int register_attributes(void)
attrib_db_add(0x0568, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 6);
/* Manufacturer name attribute */
- sdp_uuid16_create(&uuid, MANUFACTURER_NAME_UUID);
+ bt_uuid16_create(&uuid, MANUFACTURER_NAME_UUID);
len = strlen(manufacturer_name2);
strncpy((char *) atval, manufacturer_name2, len);
attrib_db_add(0x0507, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, len);
/* Characteristic: serial number */
- sdp_uuid16_create(&uuid, GATT_CHARAC_UUID);
+ bt_uuid16_create(&uuid, GATT_CHARAC_UUID);
atval[0] = ATT_CHAR_PROPER_READ;
att_put_u16(0x0509, &atval[1]);
att_put_u16(MANUFACTURER_SERIAL_UUID, &atval[3]);
attrib_db_add(0x0508, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 5);
/* Serial number characteristic value */
- sdp_uuid16_create(&uuid, MANUFACTURER_SERIAL_UUID);
+ bt_uuid16_create(&uuid, MANUFACTURER_SERIAL_UUID);
len = strlen(serial2);
strncpy((char *) atval, serial2, len);
attrib_db_add(0x0509, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, len);
/* Weight service: primary service definition */
- sdp_uuid16_create(&uuid, GATT_PRIM_SVC_UUID);
- memcpy(atval, prim_weight_uuid, 16);
+ bt_uuid16_create(&uuid, GATT_PRIM_SVC_UUID);
+ memcpy(atval, &prim_weight_uuid_btorder, 16);
attrib_db_add(0x0680, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 16);
/* Weight: include */
- sdp_uuid16_create(&uuid, GATT_INCLUDE_UUID);
+ bt_uuid16_create(&uuid, GATT_INCLUDE_UUID);
att_put_u16(0x0505, &atval[0]);
att_put_u16(0x0509, &atval[2]);
att_put_u16(MANUFACTURER_SVC_UUID, &atval[4]);
attrib_db_add(0x0681, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 6);
/* Weight: characteristic */
- sdp_uuid16_create(&uuid, GATT_CHARAC_UUID);
+ bt_uuid16_create(&uuid, GATT_CHARAC_UUID);
atval[0] = ATT_CHAR_PROPER_READ;
att_put_u16(0x0683, &atval[1]);
- memcpy(&atval[3], char_weight_uuid, 16);
+ memcpy(&atval[3], &char_weight_uuid_btorder, 16);
attrib_db_add(0x0682, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 19);
/* Weight: characteristic value */
- sdp_uuid128_create(&uuid, char_weight_uuid);
+ bt_uuid128_create(&uuid, char_weight_uuid);
atval[0] = 0x82;
atval[1] = 0x55;
atval[2] = 0x00;
@@ -299,7 +303,7 @@ static int register_attributes(void)
attrib_db_add(0x0683, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 4);
/* Weight: characteristic format */
- sdp_uuid16_create(&uuid, GATT_CHARAC_FMT_UUID);
+ bt_uuid16_create(&uuid, GATT_CHARAC_FMT_UUID);
atval[0] = 0x08;
atval[1] = 0xFD;
att_put_u16(FMT_KILOGRAM_UUID, &atval[2]);
@@ -308,7 +312,7 @@ static int register_attributes(void)
attrib_db_add(0x0684, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 8);
/* Weight: characteristic user description */
- sdp_uuid16_create(&uuid, GATT_CHARAC_USER_DESC_UUID);
+ bt_uuid16_create(&uuid, GATT_CHARAC_USER_DESC_UUID);
len = strlen(desc_weight);
strncpy((char *) atval, desc_weight, len);
attrib_db_add(0x0685, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, len);
--
1.7.1
^ 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