* Re: [PATCH 8/9] Bluetooth: Use a stream-oriented recvmsg with SOCK_STREAM L2CAP sockets.
From: Marcel Holtmann @ 2010-08-09 2:50 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, gustavo, rshaffer, linux-arm-msm
In-Reply-To: <1281048867-32630-9-git-send-email-mathewm@codeaurora.org>
Hi Mat,
> L2CAP ERTM sockets can be opened with the SOCK_STREAM socket type,
> which is a mandatory request for ERTM mode.
>
> However, these sockets still have SOCK_SEQPACKET read semantics when
> bt_sock_recvmsg() is used to pull data from the receive queue. If the
> application is only reading part of a frame, then the unread portion
> of the frame is discarded. If the application requests more bytes
> than are in the current frame, only the current frame's data is
> returned.
>
> This patch utilizes common code derived from RFCOMM's recvmsg()
> function to make L2CAP SOCK_STREAM reads behave like RFCOMM reads (and
> other SOCK_STREAM sockets in general). The application may read one
> byte at a time from the input stream and not lose any data, and may
> also read across L2CAP frame boundaries.
>
> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> ---
> net/bluetooth/l2cap.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index 43e0eae..cd0e150 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -1956,7 +1956,10 @@ static int l2cap_sock_recvmsg(struct kiocb *iocb, struct socket *sock, struct ms
>
> release_sock(sk);
>
> - return bt_sock_recvmsg(iocb, sock, msg, len, flags);
> + if (sock->type == SOCK_STREAM)
> + return bt_sock_stream_recvmsg(iocb, sock, msg, len, flags);
> + else
> + return bt_sock_recvmsg(iocb, sock, msg, len, flags);
> }
>
> static int l2cap_sock_setsockopt_old(struct socket *sock, int optname, char __user *optval, unsigned int optlen)
this is more a style issue, but I clearly prefer this:
if (sock->type == SOCK_STREAM)
return bt_sock_stream_recvmsg(iocb, sock, msg, len, flags);
return bt_sock_recvmsg(iocb, sock, msg, len, flags);
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 3/9] Bluetooth: Validate PSM values in calls to connect() and bind().
From: Marcel Holtmann @ 2010-08-09 2:46 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, gustavo, rshaffer, linux-arm-msm
In-Reply-To: <1281048867-32630-4-git-send-email-mathewm@codeaurora.org>
Hi Mat,
> Valid L2CAP PSMs are odd numbers, and the least significant bit of the
> most significant byte must be 0.
>
> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> ---
> net/bluetooth/l2cap.c | 12 ++++++++++++
> 1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index bc10be8..77ba106 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -1008,6 +1008,12 @@ static int l2cap_sock_bind(struct socket *sock, struct sockaddr *addr, int alen)
> goto done;
> }
>
> + /* If specified, PSM must be odd and lsb of upper byte must be 0 */
> + if (la.l2_psm && (__le16_to_cpu(la.l2_psm) & 0x0101) != 0x0001) {
> + err = -EINVAL;
> + goto done;
> + }
> +
> if (la.l2_psm && __le16_to_cpu(la.l2_psm) < 0x1001 &&
> !capable(CAP_NET_BIND_SERVICE)) {
> err = -EACCES;
we might wanna do this a bit nicer here:
if (la.l2_psm) {
__u16 psm = __le16_to_cpu(la.l2_psm);
if ((psm & 0x0101) != 0x0001) {
err = -EINVAL;
goto done;
}
if (psm < 0x1001 && ...) {
...
}
}
Regards
Marcel
^ permalink raw reply
* QuiC AMP development
From: Ron Shaffer @ 2010-08-09 2:43 UTC (permalink / raw)
To: linux-bluetooth
As requested in today's summit discussions, here's a link that can be
used to inspect the code we've done to add AMP support on the latest
next tree.
https://www.codeaurora.org/gitweb/quic/bluetooth/?p=bluetooth-next-2.6.git;a=summary
branch pk-upstream
And for those who missed the original RFC, you can find it here:
http://www.spinics.net/lists/linux-bluetooth/msg04674.html
--
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 1/9] Bluetooth: Only enable for L2CAP FCS for ERTM or streaming.
From: Marcel Holtmann @ 2010-08-09 2:43 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, gustavo, rshaffer, linux-arm-msm
In-Reply-To: <1281048867-32630-2-git-send-email-mathewm@codeaurora.org>
Hi Mat,
> This fixes a bug which caused the FCS setting to show L2CAP_FCS_CRC16
> with L2CAP modes other than ERTM or streaming. At present, this only
> affects the FCS value shown with getsockopt() for basic mode.
>
> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> ---
> net/bluetooth/l2cap.c | 16 ++++++++++++----
> 1 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index 3e3cd9d..bc10be8 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -3072,6 +3072,16 @@ static inline int l2cap_connect_rsp(struct l2cap_conn *conn, struct l2cap_cmd_hd
> return 0;
> }
>
> +static inline int l2cap_fcs_needed(struct l2cap_pinfo *pi)
> +{
> + if (pi->mode != L2CAP_MODE_ERTM && pi->mode != L2CAP_MODE_STREAMING)
> + return 0;
> +
> + /* FCS is enabled if one or both sides request it. */
> + return !(pi->conf_state & L2CAP_CONF_NO_FCS_RECV) ||
> + pi->fcs == L2CAP_FCS_CRC16;
> +}
so I think a switch statement is easier to read:
switch (pi->mode) {
case L2CAP_MODE_ERTM:
case L2CAP_MODE_STREAMING:
return !(pi->conf_state & L2CAP_CONF_NO_FCS_RECV) ||
pi->fcs == L2CAP_FCS_CRC16;
}
return 0;
> static inline int l2cap_config_req(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd, u16 cmd_len, u8 *data)
> {
> struct l2cap_conf_req *req = (struct l2cap_conf_req *) data;
> @@ -3136,8 +3146,7 @@ static inline int l2cap_config_req(struct l2cap_conn *conn, struct l2cap_cmd_hdr
> goto unlock;
>
> if (l2cap_pi(sk)->conf_state & L2CAP_CONF_INPUT_DONE) {
> - if (!(l2cap_pi(sk)->conf_state & L2CAP_CONF_NO_FCS_RECV) ||
> - l2cap_pi(sk)->fcs != L2CAP_FCS_NONE)
> + if (l2cap_fcs_needed(l2cap_pi(sk)))
> l2cap_pi(sk)->fcs = L2CAP_FCS_CRC16;
While this is just fine, I think we might should make this a lot
simpler:
if (l2cap_pi(sk)->conf_state & L2CAP_CONF_INPUT_DONE) {
set_default_fcs(pi);
...
}
With then set_default_fcs() doing all the checks etc. and setting either
FCS_NONE or FCS_CRC16.
Would this work or do we have to deal with some funny default behavior?
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] net: bluetooth: Fix build error from rfcomm/tty.c
From: Gustavo F. Padovan @ 2010-08-08 18:24 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: linux-bluetooth, linux-omap, Marcel Holtmann
In-Reply-To: <1281258478-17335-1-git-send-email-santosh.shilimkar@ti.com>
Hi Santosh,
* Santosh Shilimkar <santosh.shilimkar@ti.com> [2010-08-08 14:37:58 +0530]:
> The build error is as follows:
> `rfcomm_cleanup_ttys' referenced in section `.init.text' of net/built-in.o:
> defined in discarded section `.exit.text' of net/built-in.o
> make: *** [.tmp_vmlinux1] Error 1
>
> This patch fixes by removing __exit from fucntion 'rfcomm_cleanup_ttys'
> to avoid section mismatch
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/rfcomm/tty.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
We have fixed that already, thanks anyway. ;)
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* [PATCH] net: bluetooth: Fix build error from rfcomm/tty.c
From: Santosh Shilimkar @ 2010-08-08 9:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: linux-omap, Santosh Shilimkar, Marcel Holtmann
The build error is as follows:
`rfcomm_cleanup_ttys' referenced in section `.init.text' of net/built-in.o:
defined in discarded section `.exit.text' of net/built-in.o
make: *** [.tmp_vmlinux1] Error 1
This patch fixes by removing __exit from fucntion 'rfcomm_cleanup_ttys'
to avoid section mismatch
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
---
net/bluetooth/rfcomm/tty.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/rfcomm/tty.c b/net/bluetooth/rfcomm/tty.c
index 026205c..befc3a5 100644
--- a/net/bluetooth/rfcomm/tty.c
+++ b/net/bluetooth/rfcomm/tty.c
@@ -1183,7 +1183,7 @@ int __init rfcomm_init_ttys(void)
return 0;
}
-void __exit rfcomm_cleanup_ttys(void)
+void rfcomm_cleanup_ttys(void)
{
tty_unregister_driver(rfcomm_tty_driver);
put_tty_driver(rfcomm_tty_driver);
--
1.6.0.4
^ permalink raw reply related
* Re: Next BlueZ developer meeting
From: Arun Kumar @ 2010-08-07 22:10 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Ron Shaffer, linux-bluetooth
In-Reply-To: <1281186114.12579.165.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]
Hi All,
I am already checked in my room for same but looks like the front desk is
not aware of the bluez mini-summit tomorrow :-) Any other folks attending
bluez conf and already checked in may kindly get in touch. I am put up in
#1615.
Thanks,
Arun
On Sat, Aug 7, 2010 at 6:31 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Ron,
>
> > >> Can you send out the event specifics - times and meeting places?
> > >
> > > the event details will be provided by the LinuxCon when you register on
> > > Sunday morning. The registration will start at 8am along with the
> > > continental breakfast. And we have our room from 9am - 6pm. I assume it
> > > will be Aegean room on the Ballroom level, but we will see when we get
> > > there.
> > >
> > > Since we start on a Sunday, we can take it certainly easy and start
> > > around 10am. So no rush ;)
> > >
> >
> > Thanks for the info. FYI, the LinuxCon schedule shows registration
> > starting Tues at 8:00 AM. Either it's wrong or there's no registration
> > on Sunday.
>
> this is what I've been told. So I hope that someone does registration as
> well on Sunday. Otherwise just go directly to the room. If something
> goes wrong or is missing we will sort it out Sunday morning. As I said,
> no stress. I myself will only arrive later tonight so we just have to
> see ;)
>
> Regards
>
> Marcel
>
>
> --
> 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
Also catch me on
www.facebook.com/arunkat
www.twitter.com/arun_cats
[-- Attachment #2: Type: text/html, Size: 2779 bytes --]
^ permalink raw reply
* Re: Next BlueZ developer meeting
From: Manuel Naranjo @ 2010-08-07 13:29 UTC (permalink / raw)
Cc: linux-bluetooth
In-Reply-To: <1281186114.12579.165.camel@localhost.localdomain>
Hi guys,
> this is what I've been told. So I hope that someone does registration as
> well on Sunday. Otherwise just go directly to the room. If something
> goes wrong or is missing we will sort it out Sunday morning. As I said,
> no stress. I myself will only arrive later tonight so we just have to
> see ;)
>
I envy you :D. Hey any chance to have a stream or something about it? I
saw LinuxCon is going to stream but the BlueZ one is not included. I
wouldn't mind paying to get access if it's available, but I would like
to see it.
Manuel
^ permalink raw reply
* Re: Question about BlueZ licenses (LGPL and Apache)
From: Alan Carvalho de Assis @ 2010-08-07 13:28 UTC (permalink / raw)
To: Madhavi Manchala, linux-bluetooth; +Cc: Marcel Holtmann
In-Reply-To: <1281157620.12579.157.camel@localhost.localdomain>
Hi Madhavi,
On 8/7/10, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Madhavi,
>
>> I am trying to implement a custom voice codec on the android bluetooth
>> platform by linking it, into the A2DP module. I have heard different
>> versions from different people regarding the licenses (like LGPL and
>> Apache License). So, before starting my work, I would like to know if
>> I would be forced to reveal my source code, once I implement my codec
>> on BlueZ stack. Please let me know, so that I can choose my platform,
>> before starting my work.
As you asked this same question in Android mailing list I suggest you
to forward Marcel reply to here as well. This way many other people in
that list will be aware of it.
Best Regards,
Alan
^ permalink raw reply
* Re: Next BlueZ developer meeting
From: Marcel Holtmann @ 2010-08-07 13:01 UTC (permalink / raw)
To: Ron Shaffer; +Cc: linux-bluetooth
In-Reply-To: <4C5CF3C7.8020503@codeaurora.org>
Hi Ron,
> >> Can you send out the event specifics - times and meeting places?
> >
> > the event details will be provided by the LinuxCon when you register on
> > Sunday morning. The registration will start at 8am along with the
> > continental breakfast. And we have our room from 9am - 6pm. I assume it
> > will be Aegean room on the Ballroom level, but we will see when we get
> > there.
> >
> > Since we start on a Sunday, we can take it certainly easy and start
> > around 10am. So no rush ;)
> >
>
> Thanks for the info. FYI, the LinuxCon schedule shows registration
> starting Tues at 8:00 AM. Either it's wrong or there's no registration
> on Sunday.
this is what I've been told. So I hope that someone does registration as
well on Sunday. Otherwise just go directly to the room. If something
goes wrong or is missing we will sort it out Sunday morning. As I said,
no stress. I myself will only arrive later tonight so we just have to
see ;)
Regards
Marcel
^ permalink raw reply
* Re: Next BlueZ developer meeting
From: Ron Shaffer @ 2010-08-07 5:48 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1281157965.12579.163.camel@localhost.localdomain>
On 8/7/2010 12:12 AM, Marcel Holtmann wrote:
> Hi Ron,
>
>> Can you send out the event specifics - times and meeting places?
>
> the event details will be provided by the LinuxCon when you register on
> Sunday morning. The registration will start at 8am along with the
> continental breakfast. And we have our room from 9am - 6pm. I assume it
> will be Aegean room on the Ballroom level, but we will see when we get
> there.
>
> Since we start on a Sunday, we can take it certainly easy and start
> around 10am. So no rush ;)
>
> Regards
>
> Marcel
>
>
> --
> 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
>
Thanks for the info. FYI, the LinuxCon schedule shows registration
starting Tues at 8:00 AM. Either it's wrong or there's no registration
on Sunday.
--
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: Next BlueZ developer meeting
From: Marcel Holtmann @ 2010-08-07 5:12 UTC (permalink / raw)
To: Ron Shaffer; +Cc: linux-bluetooth
In-Reply-To: <4C5C8A7A.8060301@codeaurora.org>
Hi Ron,
> Can you send out the event specifics - times and meeting places?
the event details will be provided by the LinuxCon when you register on
Sunday morning. The registration will start at 8am along with the
continental breakfast. And we have our room from 9am - 6pm. I assume it
will be Aegean room on the Ballroom level, but we will see when we get
there.
Since we start on a Sunday, we can take it certainly easy and start
around 10am. So no rush ;)
Regards
Marcel
^ permalink raw reply
* Re: Question about BlueZ licenses (LGPL and Apache)
From: Marcel Holtmann @ 2010-08-07 5:07 UTC (permalink / raw)
To: Madhavi Manchala; +Cc: linux-bluetooth
In-Reply-To: <AANLkTimiBsL60-8w4MPoP=g8Fo_+U-SrSBTa9--aqEK4@mail.gmail.com>
Hi Madhavi,
> I am trying to implement a custom voice codec on the android bluetooth
> platform by linking it, into the A2DP module. I have heard different
> versions from different people regarding the licenses (like LGPL and
> Apache License). So, before starting my work, I would like to know if
> I would be forced to reveal my source code, once I implement my codec
> on BlueZ stack. Please let me know, so that I can choose my platform,
> before starting my work.
BlueZ (bluetoothd and libbluetooth) is licensed under GPL 2.0 license
and nothing else. It is pretty clear in the COPYING file. There are a
few source code files licensed under LGPL, but after linking the end
result is still GPL. If in doubt ask your lawyer since nobody here on
the mailing list can give you official legal advise.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 7/7] Add service UUIDs from EIR to device properties in "Device Found" signal.
From: Johan Hedberg @ 2010-08-07 3:10 UTC (permalink / raw)
To: Inga Stotland; +Cc: linux-bluetooth, marcel, rshaffer
In-Reply-To: <1281119724-28882-1-git-send-email-ingas@codeaurora.org>
Hi Inga,
On Fri, Aug 06, 2010, Inga Stotland wrote:
> If service UUIDs are present in EIR, they are written to
> "device properties" dictionary when emitting "Device Found" signal.
> This allows peek at available services offered by a remote device
> without establishing SDP connection.
> ---
> src/adapter.c | 108 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
> src/adapter.h | 4 +-
> src/dbus-hci.c | 6 ++--
> 3 files changed, 110 insertions(+), 8 deletions(-)
The patch is now upstream. Thanks!
Johan
^ permalink raw reply
* Re: Next BlueZ developer meeting
From: Ron Shaffer @ 2010-08-06 22:19 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1278555742.10421.11.camel@localhost.localdomain>
On 7/7/2010 9:22 PM, Marcel Holtmann wrote:
> Hello once more,
>
>>> our next BlueZ developer meeting will be held as mini-summit as part of
>>> the LinuxCon in Boston.
>>>
>>> http://events.linuxfoundation.org/events/linuxcon/mini-summits
>>>
>>> I like to invite interested developers to join us in Boston. The summit
>>> will be held on Sunday, 8th and Monday, 9th of July.
>>
>> I obviously meant 8th and 9th of August. Sorry for the confusion.
>
> I just got reminded that the registration fee for LinuxCon increases on
> July, 15th. So if you already know that you are attending you might
> wanna register sooner than later. The link is here:
>
> http://events.linuxfoundation.org/component/registrationpro/?func=details&did=27
>
> Regards
>
> Marcel
>
>
> --
> 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
>
Can you send out the event specifics - times and meeting places?
Thanks,
--
Ron Shaffer
Employee of the Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH 7/7] Add service UUIDs from EIR to device properties in "Device Found" signal.
From: Inga Stotland @ 2010-08-06 18:35 UTC (permalink / raw)
To: linux-bluetooth; +Cc: johan.hedberg, marcel, rshaffer, Inga Stotland
In-Reply-To: <20100806173042.GA28198@jh-x301>
If service UUIDs are present in EIR, they are written to
"device properties" dictionary when emitting "Device Found" signal.
This allows peek at available services offered by a remote device
without establishing SDP connection.
---
src/adapter.c | 108 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
src/adapter.h | 4 +-
src/dbus-hci.c | 6 ++--
3 files changed, 110 insertions(+), 8 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index c142a4a..5746cbc 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -2749,8 +2749,102 @@ static void emit_device_found(const char *path, const char *address,
g_dbus_send_message(connection, signal);
}
+static char **get_eir_uuids(uint8_t *eir_data, size_t *uuid_count)
+{
+ uint16_t len = 0;
+ char **uuids;
+ size_t total;
+ size_t uuid16_count = 0;
+ size_t uuid32_count = 0;
+ size_t uuid128_count = 0;
+ uint8_t *uuid16;
+ uint8_t *uuid32;
+ uint8_t *uuid128;
+ uuid_t service;
+ unsigned int i;
+
+ while (len < EIR_DATA_LENGTH - 1) {
+ uint8_t type = eir_data[1];
+ uint8_t field_len = eir_data[0];
+
+ /* Check for the end of EIR */
+ if (field_len == 0)
+ break;
+
+ switch (type) {
+ case EIR_UUID16_SOME:
+ case EIR_UUID16_ALL:
+ uuid16_count = field_len / 2;
+ uuid16 = &eir_data[2];
+ break;
+ case EIR_UUID32_SOME:
+ case EIR_UUID32_ALL:
+ uuid32_count = field_len / 4;
+ uuid32 = &eir_data[2];
+ break;
+ case EIR_UUID128_SOME:
+ case EIR_UUID128_ALL:
+ uuid128_count = field_len / 16;
+ uuid128 = &eir_data[2];
+ break;
+ }
+
+ len += field_len + 1;
+ eir_data += field_len + 1;
+ }
+
+ /* Bail out if got incorrect length */
+ if (len > EIR_DATA_LENGTH)
+ return NULL;
+
+ total = uuid16_count + uuid32_count + uuid128_count;
+ *uuid_count = total;
+
+ if (!total)
+ return NULL;
+
+ uuids = g_new0(char *, total + 1);
+
+ /* Generate uuids in SDP format (EIR data is Little Endian) */
+ service.type = SDP_UUID16;
+ for (i = 0; i < uuid16_count; i++) {
+ uint16_t val16 = uuid16[1];
+
+ val16 = (val16 << 8) + uuid16[0];
+ service.value.uuid16 = val16;
+ uuids[i] = bt_uuid2string(&service);
+ uuid16 += 2;
+ }
+
+ service.type = SDP_UUID32;
+ for (i = uuid16_count; i < uuid32_count + uuid16_count; i++) {
+ uint32_t val32 = uuid32[3];
+ int k;
+
+ for (k = 2; k >= 0; k--)
+ val32 = (val32 << 8) + uuid32[k];
+
+ service.value.uuid32 = val32;
+ uuids[i] = bt_uuid2string(&service);
+ uuid32 += 4;
+ }
+
+ service.type = SDP_UUID128;
+ for (i = uuid32_count + uuid16_count; i < total; i++) {
+ int k;
+
+ for (k = 0; k < 16; k++)
+ service.value.uuid128.data[k] = uuid128[16 - k - 1];
+
+ uuids[i] = bt_uuid2string(&service);
+ uuid128 += 16;
+ }
+
+ return uuids;
+}
+
void adapter_emit_device_found(struct btd_adapter *adapter,
- struct remote_dev_info *dev)
+ struct remote_dev_info *dev, uint8_t *eir_data)
{
struct btd_device *device;
char peer_addr[18], local_addr[18];
@@ -2758,6 +2852,8 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
dbus_bool_t paired = FALSE;
dbus_int16_t rssi = dev->rssi;
char *alias;
+ char **uuids = NULL;
+ size_t uuid_count = 0;
ba2str(&dev->bdaddr, peer_addr);
ba2str(&adapter->bdaddr, local_addr);
@@ -2777,6 +2873,10 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
} else
alias = g_strdup(dev->alias);
+ /* Extract UUIDs from extended inquiry response if any*/
+ if (eir_data != NULL)
+ uuids = get_eir_uuids(eir_data, &uuid_count);
+
emit_device_found(adapter->path, paddr,
"Address", DBUS_TYPE_STRING, &paddr,
"Class", DBUS_TYPE_UINT32, &dev->class,
@@ -2786,15 +2886,17 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
"Alias", DBUS_TYPE_STRING, &alias,
"LegacyPairing", DBUS_TYPE_BOOLEAN, &dev->legacy,
"Paired", DBUS_TYPE_BOOLEAN, &paired,
+ "UUIDs", DBUS_TYPE_ARRAY, &uuids, uuid_count,
NULL);
g_free(alias);
+ g_strfreev(uuids);
}
void adapter_update_found_devices(struct btd_adapter *adapter, bdaddr_t *bdaddr,
int8_t rssi, uint32_t class, const char *name,
const char *alias, gboolean legacy,
- name_status_t name_status)
+ name_status_t name_status, uint8_t *eir_data)
{
struct remote_dev_info *dev, match;
@@ -2833,7 +2935,7 @@ done:
adapter->found_devices = g_slist_sort(adapter->found_devices,
(GCompareFunc) dev_rssi_cmp);
- adapter_emit_device_found(adapter, dev);
+ adapter_emit_device_found(adapter, dev, eir_data);
}
int adapter_remove_found_device(struct btd_adapter *adapter, bdaddr_t *bdaddr)
diff --git a/src/adapter.h b/src/adapter.h
index 8226514..a7eca0e 100644
--- a/src/adapter.h
+++ b/src/adapter.h
@@ -113,10 +113,10 @@ struct remote_dev_info *adapter_search_found_devices(struct btd_adapter *adapter
void adapter_update_found_devices(struct btd_adapter *adapter, bdaddr_t *bdaddr,
int8_t rssi, uint32_t class, const char *name,
const char *alias, gboolean legacy,
- name_status_t name_status);
+ name_status_t name_status, uint8_t *eir_data);
int adapter_remove_found_device(struct btd_adapter *adapter, bdaddr_t *bdaddr);
void adapter_emit_device_found(struct btd_adapter *adapter,
- struct remote_dev_info *dev);
+ struct remote_dev_info *dev, uint8_t *eir_data);
void adapter_update_oor_devices(struct btd_adapter *adapter);
void adapter_mode_changed(struct btd_adapter *adapter, uint8_t scan_mode);
void adapter_setname_complete(bdaddr_t *local, uint8_t status);
diff --git a/src/dbus-hci.c b/src/dbus-hci.c
index b83506f..6d27caa 100644
--- a/src/dbus-hci.c
+++ b/src/dbus-hci.c
@@ -515,7 +515,7 @@ void hcid_dbus_inquiry_result(bdaddr_t *local, bdaddr_t *peer, uint32_t class,
if (dev) {
adapter_update_found_devices(adapter, peer, rssi, class,
NULL, NULL, dev->legacy,
- NAME_NOT_REQUIRED);
+ NAME_NOT_REQUIRED, data);
return;
}
@@ -566,7 +566,7 @@ void hcid_dbus_inquiry_result(bdaddr_t *local, bdaddr_t *peer, uint32_t class,
/* add in the list to track name sent/pending */
adapter_update_found_devices(adapter, peer, rssi, class, name, alias,
- legacy, name_status);
+ legacy, name_status, data);
g_free(name);
g_free(alias);
@@ -642,7 +642,7 @@ void hcid_dbus_remote_name(bdaddr_t *local, bdaddr_t *peer, uint8_t status,
if (dev_info) {
g_free(dev_info->name);
dev_info->name = g_strdup(name);
- adapter_emit_device_found(adapter, dev_info);
+ adapter_emit_device_found(adapter, dev_info, NULL);
}
if (device)
--
1.7.2
--
Inga Stotland
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* Re: [PATCH 7/7] Add service UUIDs from EIR to device properties in "Device Found" signal.
From: ingas @ 2010-08-06 18:18 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth
In-Reply-To: <20100806173042.GA28198@jh-x301>
>
> There's still however one issue (I only now tried to compile the patch):
>
> src/adapter.c: In function ‘get_eir_uuids’:
> src/adapter.c:2810: error: comparison between signed and unsigned integer
> expressions
> src/adapter.c:2820: error: comparison between signed and unsigned integer
> expressions
> src/adapter.c:2833: error: comparison between signed and unsigned integer
> expressions
> make[1]: *** [src/adapter.o] Error 1
>
> Could you please fix it and always in the future ensure that the code
> compiles cleanly when configured with ./bootstrap-configure. Also, could
> you make the commit message more descriptive. The summary line should be
> a very short summary of what the patch is about and the more detailed
> description should be in the message body.
>
Oops, sorry about that: I was using bootstrap and configure as separate
scripts. Apparently the warning level is not set high enough in there.
Will fix and resubmit.
Regards,
Inga
^ permalink raw reply
* Re: [PATCH 7/7] Add service UUIDs from EIR to device properties in "Device Found" signal.
From: Johan Hedberg @ 2010-08-06 17:30 UTC (permalink / raw)
To: ingas; +Cc: linux-bluetooth, rshaffer
In-Reply-To: <1844054b1cfff4c91e67223013eb09ac.squirrel@www.codeaurora.org>
Hi Inga,
On Fri, Aug 06, 2010, ingas@codeaurora.org wrote:
> > On Thu, Aug 05, 2010, Inga Stotland wrote:
> >> + while (len < EIR_DATA_LENGTH - 1) {
> >> + uint8_t type = eir_data[1];
> >> + uint8_t field_len = eir_data[0];
> >> +
> >> + /* Check for the end of EIR */
> >> + if (field_len == 0)
> >> + break;
> >
> > Shouldn't there also be another check here:
> >
> > /* Bail out if field_len claims to reach beyond the EIR
> > * data end */
> > if (len + field_len + 1 >= EIR_DATA_LENGTH)
> > break;
> >
>
> After reading in eir_data[0] & eir_data[1] (and those reads are valid due
> to passing the "while (len < EIR_DATA_LENGTH - 1)" check above) there are
> no more memory accesses in the loop. And if we do end up reading in field
> length that's bogus, we fail the "while" check on next iteration, exit the
> loop, fail the "(len > EIR_DATA_LENGTH)" and bail out of the routine with
> NULL return value.
Yep, you're right. What got me unnerved was that you still set pointers
to potentially out-of-bounds data in the switch statement, but as you
say the if check after the switch statement ensures that the pointers
don't get accessed if something went beyond the EIR data length.
There's still however one issue (I only now tried to compile the patch):
src/adapter.c: In function ‘get_eir_uuids’:
src/adapter.c:2810: error: comparison between signed and unsigned integer expressions
src/adapter.c:2820: error: comparison between signed and unsigned integer expressions
src/adapter.c:2833: error: comparison between signed and unsigned integer expressions
make[1]: *** [src/adapter.o] Error 1
Could you please fix it and always in the future ensure that the code
compiles cleanly when configured with ./bootstrap-configure. Also, could
you make the commit message more descriptive. The summary line should be
a very short summary of what the patch is about and the more detailed
description should be in the message body.
Johan
^ permalink raw reply
* Re: [PATCH 7/7] Add service UUIDs from EIR to device properties in "Device Found" signal.
From: ingas @ 2010-08-06 16:16 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth, rshaffer
In-Reply-To: <20100806075552.GA22150@jh-x301>
Hi Johan,
> Hi Inga,
>
> On Thu, Aug 05, 2010, Inga Stotland wrote:
>> + while (len < EIR_DATA_LENGTH - 1) {
>> + uint8_t type = eir_data[1];
>> + uint8_t field_len = eir_data[0];
>> +
>> + /* Check for the end of EIR */
>> + if (field_len == 0)
>> + break;
>
> Shouldn't there also be another check here:
>
> /* Bail out if field_len claims to reach beyond the EIR
> * data end */
> if (len + field_len + 1 >= EIR_DATA_LENGTH)
> break;
>
After reading in eir_data[0] & eir_data[1] (and those reads are valid due
to passing the "while (len < EIR_DATA_LENGTH - 1)" check above) there are
no more memory accesses in the loop. And if we do end up reading in field
length that's bogus, we fail the "while" check on next iteration, exit the
loop, fail the "(len > EIR_DATA_LENGTH)" and bail out of the routine with
NULL return value.
Actually, I originally had the check for field length inside the loop, but
then moved it outside for efficiency reasons.
Thanks,
Inga
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
>
^ permalink raw reply
* Question about BlueZ licenses (LGPL and Apache)
From: Madhavi Manchala @ 2010-08-06 15:44 UTC (permalink / raw)
To: linux-bluetooth
Dear All,
I am trying to implement a custom voice codec on the android bluetooth
platform by linking it, into the A2DP module. I have heard different
versions from different people regarding the licenses (like LGPL and
Apache License). So, before starting my work, I would like to know if
I would be forced to reveal my source code, once I implement my codec
on BlueZ stack. Please let me know, so that I can choose my platform,
before starting my work.
Regards,
Madhavi.
^ permalink raw reply
* [PATCH] add mailing list as bug report address to configure.ac
From: Uwe Kleine-König @ 2010-08-06 14:20 UTC (permalink / raw)
To: linux-bluetooth
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
configure.ac | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index b004f6e..2804d29 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
AC_PREREQ(2.60)
-AC_INIT(bluez, 4.69)
+AC_INIT(bluez, 4.69, [linux-bluetooth@vger.kernel.org])
AM_INIT_AUTOMAKE([foreign subdir-objects])
AM_CONFIG_HEADER(config.h)
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] add three missing api documents to EXTRA_DIST
From: Uwe Kleine-König @ 2010-08-06 14:18 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1281104283-8792-1-git-send-email-u.kleine-koenig@pengutronix.de>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
Hello,
there are still a few files in bluez.git/doc that are not listed in EXTRA_DIST:
- bluez-docs.xml
- gtk-doc.make
- version.xml.in
I didn't know if I should add these, too, so I just point that out.
Best regards
Uwe
Makefile.am | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 4bb82fe..7007026 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -316,9 +316,12 @@ EXTRA_DIST += \
doc/audio-api.txt \
doc/control-api.txt \
doc/device-api.txt \
+ doc/health-api.txt \
+ doc/hfp-api.txt \
doc/input-api.txt \
doc/manager-api.txt \
doc/network-api.txt \
+ doc/node-api.txt \
doc/serial-api.txt \
doc/service-api.txt \
--
1.7.1
^ permalink raw reply related
* [PATCH 1/2] list api docs alphabetically and one per line in EXTRA_DIST
From: Uwe Kleine-König @ 2010-08-06 14:18 UTC (permalink / raw)
To: linux-bluetooth
This makes further changes to the list easier to review
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
Makefile.am | 17 ++++++++++++-----
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 65d4312..4bb82fe 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -309,11 +309,18 @@ udevdir = $(libexecdir)/udev
dist_udev_SCRIPTS = scripts/bluetooth_serial
endif
-EXTRA_DIST += doc/manager-api.txt \
- doc/adapter-api.txt doc/device-api.txt \
- doc/service-api.txt doc/agent-api.txt doc/attribute-api.txt \
- doc/serial-api.txt doc/network-api.txt \
- doc/input-api.txt doc/audio-api.txt doc/control-api.txt
+EXTRA_DIST += \
+ doc/adapter-api.txt \
+ doc/agent-api.txt \
+ doc/attribute-api.txt \
+ doc/audio-api.txt \
+ doc/control-api.txt \
+ doc/device-api.txt \
+ doc/input-api.txt \
+ doc/manager-api.txt \
+ doc/network-api.txt \
+ doc/serial-api.txt \
+ doc/service-api.txt \
AM_YFLAGS = -d
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 7/7] Add service UUIDs from EIR to device properties in "Device Found" signal.
From: Johan Hedberg @ 2010-08-06 7:58 UTC (permalink / raw)
To: Inga Stotland, linux-bluetooth, marcel, rshaffer
In-Reply-To: <20100806075552.GA22150@jh-x301>
Hi,
On Fri, Aug 06, 2010, Johan Hedberg wrote:
> /* Bail out if field_len claims to reach beyond the EIR
> * data end */
> if (len + field_len + 1 >= EIR_DATA_LENGTH)
> break;
Sorry, that should actually be > and not >= since it's fine if the end
of the field coincides with the end of EIR data.
Johan
^ permalink raw reply
* Re: [PATCH 7/7] Add service UUIDs from EIR to device properties in "Device Found" signal.
From: Johan Hedberg @ 2010-08-06 7:55 UTC (permalink / raw)
To: Inga Stotland; +Cc: linux-bluetooth, marcel, rshaffer
In-Reply-To: <1281047801-4044-1-git-send-email-ingas@codeaurora.org>
Hi Inga,
On Thu, Aug 05, 2010, Inga Stotland wrote:
> + while (len < EIR_DATA_LENGTH - 1) {
> + uint8_t type = eir_data[1];
> + uint8_t field_len = eir_data[0];
> +
> + /* Check for the end of EIR */
> + if (field_len == 0)
> + break;
Shouldn't there also be another check here:
/* Bail out if field_len claims to reach beyond the EIR
* data end */
if (len + field_len + 1 >= EIR_DATA_LENGTH)
break;
Johan
^ permalink raw reply
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