* Re: [RFC] android/avctp: Move struct definitions to header
From: Andrei Emeltchenko @ 2014-01-29 7:56 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <CABBYNZKKvD2=OGYoTdbH7=buaZMpaDN51aWd4aRrFR+7rWVSoQ@mail.gmail.com>
Hi Luiz,
On Tue, Jan 28, 2014 at 06:56:25AM -0800, Luiz Augusto von Dentz wrote:
> Hi Andrei,
>
> On Tue, Jan 28, 2014 at 4:34 AM, Andrei Emeltchenko
> <Andrei.Emeltchenko.news@gmail.com> wrote:
> > From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> >
> > There is currently inconsistence in the avctp code with
> > AVC_HEADER_LENGTH defined in avctp.h but AVCTP_HEADER_LENGTH defined in
> > avctp.c. The patch moves structure definitions to the header in
> > consistent way.
>
> I wonder why you did not do the opposite, move AVC_HEADER_LENGTH into
> avctp.c since the AVC packet control is all done inside avctp.c it
> should probably not be exposed.
I do actually think that avctp.c is wrong place to deal with AVC since
AVCTP shouldn't handle it but anyway I will move it there.
Best regards
Andrei Emeltchenko
^ permalink raw reply
* Re: [RFC BlueZ 0/3] Fix GATT server issues with BlueZ as LE peripheral
From: Isa Ansharullah @ 2014-01-29 6:51 UTC (permalink / raw)
To: linux-bluetooth
Hi Lizardo,
The patches fixed the issue.
Thank you very much.
Isa
^ permalink raw reply
* Re: [RFC BlueZ 0/2] Print bluetoothd messages in btmon
From: Marcel Holtmann @ 2014-01-29 6:42 UTC (permalink / raw)
To: Vinicius Gomes; +Cc: BlueZ development
In-Reply-To: <1390599712-1609-1-git-send-email-vcgomes@gmail.com>
Hi Vinicius,
> It is very common when debugging issues, specially users' problems to
> ask for btmon logs and the accompaining bluetoothd logs. And depending
> on the issue, it takes some time to relate the HCI/MGMT commands to
> bluetoothd messages that help narrow down the problem.
>
> This is just a proof of concept, to know if this will be generally
> helpful. And so, it needs some improvements: sending bluetoothd the USR2
> signal so debug is enabled, color support and better formatting.
so I am thinking to do this completely different.
I think that the btsnoop 2.0 format should get a section for notes/comments/logs where we can store text information. So you can actually interline HCI traffic with human readable comments. For example Apple is doing that with their Packet Logger. Obvious this is only useful if everything is in a single file that can be easily shared.
For this to work we need to read all the data from monitor interface of the kernel. Which means that the kernel also needs to have the debug/log output of bluetoothd. Meaning that bluetoothd would write the debug/logs into the kernel monitor interface and then they would be distributed to every btmon instance.
As a result bluetoothd would only log warnings, error and info messages to syslog/journal and all debug information should go back to the kernel.
Initially I was thinking just adding writing support monitor channel, but that is silly since it will turn on promiscuous mode. Something that is causing a bit of overhead on a production system. So we rather not do that. Maybe it would be better to assign a new HCI channel for bluetoothd logging data.
The one thing that is pretty obvious already is that we want to log per HCI index from bluetoothd. Which means we need to change the logging to be HCI controller aware. Without being HCI controller aware it is pretty much useless.
One interesting thing to think about is if we should tie enabling debug logs to the fact if btmon is running or not. And if we might allow btmon to configure the level of logs we want. It would be kinda cool if we can start btmon with -d ‘*audio*’ and then it magically gets all audio logs. Now it gets a bit funny with a kernel interface writing back into userspace to configure the logging level of a daemon.
I have been toying with the idea of having filters on btmon already and making the kernel just filter out packets so that userspace does not get woken up. I just never figured out the right API to do it.
Regards
Marcel
^ permalink raw reply
* [PATCH] hog: Use HoG device name as uHID input device name
From: Petri Gynther @ 2014-01-29 5:30 UTC (permalink / raw)
To: linux-bluetooth
If HoG BLE device name is known, use it when creating uHID input device.
---
profiles/input/hog.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/profiles/input/hog.c b/profiles/input/hog.c
index ded6303..3af0406 100644
--- a/profiles/input/hog.c
+++ b/profiles/input/hog.c
@@ -392,7 +392,12 @@ static void report_map_read_cb(guint8 status, const guint8 *pdu, guint16 plen,
/* create uHID device */
memset(&ev, 0, sizeof(ev));
ev.type = UHID_CREATE;
- strcpy((char *) ev.u.create.name, "bluez-hog-device");
+ if (device_name_known(hogdev->device)) {
+ device_get_name(hogdev->device, (char *) ev.u.create.name,
+ sizeof(ev.u.create.name) - 1);
+ } else {
+ strcpy((char *) ev.u.create.name, "bluez-hog-device");
+ }
ev.u.create.vendor = vendor;
ev.u.create.product = product;
ev.u.create.version = version;
--
1.8.5.3
^ permalink raw reply related
* Re: [PATCH 1/2] android/bluetooth: Add threashold to RSSI change
From: Marcel Holtmann @ 2014-01-29 1:02 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: Szymon Janc, BlueZ development
In-Reply-To: <CAJdJm_MEjCN4ooe4OSym4CLN1JLS4FrnO-n5_ZVQzrVuuZ3Sfw@mail.gmail.com>
Hi Anderson,
>>> +{
>>> + int delta;
>>> +
>>> + if (old > new)
>>> + delta = old - new;
>>> + else
>>> + delta = new - old;
>>> +
>>> + /* only 8 dBm or more */
>>> + return delta >= 8;
>>
>> int delta = old > new ? old - new : new - old;
>
> And why not:
>
> int delta = abs(old - new);
>
> (unless there is no abs() in bionic)
I remember that abs() needs -lm or something stupid.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 1/2] android/bluetooth: Add threashold to RSSI change
From: Anderson Lizardo @ 2014-01-29 0:17 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Szymon Janc, BlueZ development
In-Reply-To: <46CB790A-A0DF-47A4-ACD1-DD7C0F0A9D2D@holtmann.org>
Hi,
On Tue, Jan 28, 2014 at 8:09 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
>> +{
>> + int delta;
>> +
>> + if (old > new)
>> + delta = old - new;
>> + else
>> + delta = new - old;
>> +
>> + /* only 8 dBm or more */
>> + return delta >= 8;
>
> int delta = old > new ? old - new : new - old;
And why not:
int delta = abs(old - new);
(unless there is no abs() in bionic)
BTW, I believe this is called "hysteresis" (at least a very simple
kind). But threshold looks just fine :)
Best Regards,
--
Anderson Lizardo
http://www.indt.org/?lang=en
INdT - Manaus - Brazil
^ permalink raw reply
* Re: [PATCH 1/2] android/bluetooth: Add threashold to RSSI change
From: Marcel Holtmann @ 2014-01-29 0:09 UTC (permalink / raw)
To: Szymon Janc; +Cc: BlueZ development
In-Reply-To: <1390952835-23251-1-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
> There is no need to report very small RSSI changes.
> ---
> android/bluetooth.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/android/bluetooth.c b/android/bluetooth.c
> index b105ac8..b95023c 100644
> --- a/android/bluetooth.c
> +++ b/android/bluetooth.c
> @@ -1045,6 +1045,19 @@ static uint8_t bdaddr_type2android(uint8_t type)
> return HAL_TYPE_LE;
> }
>
> +static bool rssi_threashold(int old, int new)
lets write it threshold ;)
And I think a better name would be is_above_threshold or rssi_above_threshold.
> +{
> + int delta;
> +
> + if (old > new)
> + delta = old - new;
> + else
> + delta = new - old;
> +
> + /* only 8 dBm or more */
> + return delta >= 8;
int delta = old > new ? old - new : new - old;
> +}
> +
> static void update_found_device(const bdaddr_t *bdaddr, uint8_t bdaddr_type,
> int8_t rssi, bool confirm,
> const uint8_t *data, uint8_t data_len)
> @@ -1113,7 +1126,7 @@ static void update_found_device(const bdaddr_t *bdaddr, uint8_t bdaddr_type,
> (*num_prop)++;
> }
>
> - if (rssi) {
> + if (rssi && rssi_threashold(dev->rssi, rssi)) {
> dev->rssi = rssi;
>
> size += fill_hal_prop(buf + size, HAL_PROP_DEVICE_RSSI,
One other idea might to just use rate limit on the timestamp. Only report once every x seconds.
The inquiry TX on the remote side might not be always the same for every device. If we want to be precise we have to make sure to get the TX power level from EIR and calculate the path loss.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: Increment management interface revision
From: Johan Hedberg @ 2014-01-29 0:06 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1390952341-46747-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
On Tue, Jan 28, 2014, Marcel Holtmann wrote:
> This patch increments the management interface revision due to the
> various fixes, improvements and other changes that have been made.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/mgmt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied to bluetooth-next. Thanks.
Johan
^ permalink raw reply
* [PATCH 2/2] android/bluetooth: Send device prop event only if prop changed
From: Szymon Janc @ 2014-01-28 23:47 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
In-Reply-To: <1390952835-23251-1-git-send-email-szymon.janc@tieto.com>
This reduce number of notification sends durring discovery session.
For devices found for the first time incurrent discovery session
always send all properties.
---
android/bluetooth.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/android/bluetooth.c b/android/bluetooth.c
index b95023c..a0a678b 100644
--- a/android/bluetooth.c
+++ b/android/bluetooth.c
@@ -1068,6 +1068,7 @@ static void update_found_device(const bdaddr_t *bdaddr, uint8_t bdaddr_type,
uint8_t *num_prop;
uint8_t opcode;
int size = 0;
+ bool found = false;
memset(buf, 0, sizeof(buf));
memset(&eir, 0, sizeof(eir));
@@ -1088,7 +1089,7 @@ static void update_found_device(const bdaddr_t *bdaddr, uint8_t bdaddr_type,
if (!dev)
dev = create_device(bdaddr, bdaddr_type);
- dev->found = true;
+ found = true;
size += sizeof(*ev);
@@ -1118,7 +1119,7 @@ static void update_found_device(const bdaddr_t *bdaddr, uint8_t bdaddr_type,
bdaddr2android(bdaddr, ev->bdaddr);
}
- if (eir.class) {
+ if (eir.class && (found || dev->class != eir.class)) {
dev->class = eir.class;
size += fill_hal_prop(buf + size, HAL_PROP_DEVICE_CLASS,
@@ -1126,7 +1127,7 @@ static void update_found_device(const bdaddr_t *bdaddr, uint8_t bdaddr_type,
(*num_prop)++;
}
- if (rssi && rssi_threashold(dev->rssi, rssi)) {
+ if (rssi && (found || rssi_threashold(dev->rssi, rssi))) {
dev->rssi = rssi;
size += fill_hal_prop(buf + size, HAL_PROP_DEVICE_RSSI,
@@ -1134,7 +1135,7 @@ static void update_found_device(const bdaddr_t *bdaddr, uint8_t bdaddr_type,
(*num_prop)++;
}
- if (eir.name) {
+ if (eir.name && (found || g_strcmp0(dev->name, eir.name))) {
g_free(dev->name);
dev->name = g_strdup(eir.name);
@@ -1143,6 +1144,9 @@ static void update_found_device(const bdaddr_t *bdaddr, uint8_t bdaddr_type,
(*num_prop)++;
}
+ if (found)
+ dev->found = true;
+
if (dev->bond_state != HAL_BOND_STATE_BONDED)
cache_device(dev);
--
1.8.5.3
^ permalink raw reply related
* [PATCH 1/2] android/bluetooth: Add threashold to RSSI change
From: Szymon Janc @ 2014-01-28 23:47 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
There is no need to report very small RSSI changes.
---
android/bluetooth.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/android/bluetooth.c b/android/bluetooth.c
index b105ac8..b95023c 100644
--- a/android/bluetooth.c
+++ b/android/bluetooth.c
@@ -1045,6 +1045,19 @@ static uint8_t bdaddr_type2android(uint8_t type)
return HAL_TYPE_LE;
}
+static bool rssi_threashold(int old, int new)
+{
+ int delta;
+
+ if (old > new)
+ delta = old - new;
+ else
+ delta = new - old;
+
+ /* only 8 dBm or more */
+ return delta >= 8;
+}
+
static void update_found_device(const bdaddr_t *bdaddr, uint8_t bdaddr_type,
int8_t rssi, bool confirm,
const uint8_t *data, uint8_t data_len)
@@ -1113,7 +1126,7 @@ static void update_found_device(const bdaddr_t *bdaddr, uint8_t bdaddr_type,
(*num_prop)++;
}
- if (rssi) {
+ if (rssi && rssi_threashold(dev->rssi, rssi)) {
dev->rssi = rssi;
size += fill_hal_prop(buf + size, HAL_PROP_DEVICE_RSSI,
--
1.8.5.3
^ permalink raw reply related
* [PATCH] Bluetooth: Increment management interface revision
From: Marcel Holtmann @ 2014-01-28 23:39 UTC (permalink / raw)
To: linux-bluetooth
This patch increments the management interface revision due to the
various fixes, improvements and other changes that have been made.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
net/bluetooth/mgmt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 4ee07b432379..bde8e675c5ea 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -34,7 +34,7 @@
#include "smp.h"
#define MGMT_VERSION 1
-#define MGMT_REVISION 4
+#define MGMT_REVISION 5
static const u16 mgmt_commands[] = {
MGMT_OP_READ_INDEX_LIST,
--
1.8.5.3
^ permalink raw reply related
* Re: [PATCH] Bluetooth: Remove unnecessary check for chan->psm
From: Marcel Holtmann @ 2014-01-28 23:35 UTC (permalink / raw)
To: Johan Hedberg; +Cc: BlueZ development
In-Reply-To: <1390951684-3225-1-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> Now that ATT sockets have been converted to use the new L2CAP_CHAN_FIXED
> type there is no need to have an extra check for chan->psm in the
> l2cap_chan_close function.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> net/bluetooth/l2cap_core.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 4/4] Bluetooth: Always use l2cap_chan->psm for returning PSM to user space
From: Marcel Holtmann @ 2014-01-28 23:33 UTC (permalink / raw)
To: Johan Hedberg; +Cc: BlueZ development
In-Reply-To: <1390951011-30576-4-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> The l2cap_chan->psm value is always set to a valid value for a
> connection oriented channel. The l2cap_chan->sport is used for tracking
> local PSM allocations but will not always have a proper value, such as
> with connected sockets derived from a listening socket. This patch fixes
> the sock_getname callback to always use chan->psm when returning address
> information.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> net/bluetooth/l2cap_sock.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH BlueZ v3 1/4] android/AVDTP: Make signalling channel priority 6
From: Szymon Janc @ 2014-01-28 23:33 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1390929286-30206-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Tuesday 28 of January 2014 09:14:43 Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>
> This makes signalling priority 6 so it can push commands before the
> stream channel, without this the stream channel may be schedule
> first and cause the signalling commands to timeout while waiting a slot.
> ---
> v2: Return error if writes fails since that probably means the socket has
> been disconnected, also makes code setting socket to blocking a bit
> cleaner. v3: Remove cast as suggested by Marcel, make code setting stream
> fd to block a separate function.
>
> android/avdtp.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/android/avdtp.c b/android/avdtp.c
> index 4abcd75..e93ff70 100644
> --- a/android/avdtp.c
> +++ b/android/avdtp.c
> @@ -2056,7 +2056,7 @@ struct avdtp *avdtp_new(int fd, size_t imtu, size_t
> omtu, uint16_t version) {
> struct avdtp *session;
> GIOCondition cond = G_IO_IN | G_IO_ERR | G_IO_HUP | G_IO_NVAL;
> - int new_fd;
> + int new_fd, priority;
>
> new_fd = dup(fd);
> if (new_fd < 0) {
> @@ -2064,6 +2064,14 @@ struct avdtp *avdtp_new(int fd, size_t imtu, size_t
> omtu, uint16_t version) return NULL;
> }
>
> + priority = 6;
> + if (setsockopt(new_fd, SOL_SOCKET, SO_PRIORITY, &priority,
> + sizeof(priority)) < 0) {
> + error("setsockopt(SO_PRIORITY): %s (%d)", strerror(errno),
> + errno);
> + return NULL;
> + }
> +
> session = g_new0(struct avdtp, 1);
> session->io = g_io_channel_unix_new(new_fd);
> session->version = version;
All four patches applied, thanks.
--
BR
Szymon Janc
^ permalink raw reply
* Re: [PATCH 3/4] Bluetooth: Refuse peer RFCOMM address reading when not connected
From: Marcel Holtmann @ 2014-01-28 23:31 UTC (permalink / raw)
To: Johan Hedberg; +Cc: BlueZ development
In-Reply-To: <1390951011-30576-3-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> When we're not connected the peer address information is undefined. This
> patch fixes the remote address getting to return a proper error in case
> the sate is anything else than BT_CONNECTED.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> net/bluetooth/rfcomm/sock.c | 3 +++
> 1 file changed, 3 insertions(+)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 2/4] Bluetooth: Refuse peer L2CAP address reading when not connected
From: Marcel Holtmann @ 2014-01-28 23:29 UTC (permalink / raw)
To: Johan Hedberg; +Cc: BlueZ development
In-Reply-To: <1390951011-30576-2-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> When we're not connected the peer address information is undefined. This
> patch fixes the remote address getting to return a proper error in case
> the state is anything else than BT_CONNECTED.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> net/bluetooth/l2cap_sock.c | 3 +++
> 1 file changed, 3 insertions(+)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 1/4] Bluetooth: Free up l2cap_chan->sport when initiating a connection
From: Marcel Holtmann @ 2014-01-28 23:28 UTC (permalink / raw)
To: Johan Hedberg; +Cc: BlueZ development
In-Reply-To: <1390951011-30576-1-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> The sport variable is used to track the allocation of the local PSM
> database to ensure no two sockets take the same local PSM. It is
> acquired upon bind() but needs to be freed up if the socket ends up
> becoming a client one. This patch adds the clearing of the value when
> l2cap_chan_connect is called.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> net/bluetooth/l2cap_core.c | 7 +++++++
> 1 file changed, 7 insertions(+)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* [PATCH] Bluetooth: Remove unnecessary check for chan->psm
From: johan.hedberg @ 2014-01-28 23:28 UTC (permalink / raw)
To: linux-bluetooth
From: Johan Hedberg <johan.hedberg@intel.com>
Now that ATT sockets have been converted to use the new L2CAP_CHAN_FIXED
type there is no need to have an extra check for chan->psm in the
l2cap_chan_close function.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
---
net/bluetooth/l2cap_core.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index f583988a4653..66fbac91eaed 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -666,10 +666,7 @@ void l2cap_chan_close(struct l2cap_chan *chan, int reason)
case BT_CONNECTED:
case BT_CONFIG:
- /* ATT uses L2CAP_CHAN_CONN_ORIENTED so we must also
- * check for chan->psm.
- */
- if (chan->chan_type == L2CAP_CHAN_CONN_ORIENTED && chan->psm) {
+ if (chan->chan_type == L2CAP_CHAN_CONN_ORIENTED) {
__set_chan_timer(chan, chan->ops->get_sndtimeo(chan));
l2cap_send_disconn_req(chan, reason);
} else
--
1.8.5.3
^ permalink raw reply related
* [PATCH 4/4] Bluetooth: Always use l2cap_chan->psm for returning PSM to user space
From: johan.hedberg @ 2014-01-28 23:16 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1390951011-30576-1-git-send-email-johan.hedberg@gmail.com>
From: Johan Hedberg <johan.hedberg@intel.com>
The l2cap_chan->psm value is always set to a valid value for a
connection oriented channel. The l2cap_chan->sport is used for tracking
local PSM allocations but will not always have a proper value, such as
with connected sockets derived from a listening socket. This patch fixes
the sock_getname callback to always use chan->psm when returning address
information.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
---
net/bluetooth/l2cap_sock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index a0b8c7aa448e..6ca14c411b89 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -373,13 +373,13 @@ static int l2cap_sock_getname(struct socket *sock, struct sockaddr *addr,
addr->sa_family = AF_BLUETOOTH;
*len = sizeof(struct sockaddr_l2);
+ la->l2_psm = chan->psm;
+
if (peer) {
- la->l2_psm = chan->psm;
bacpy(&la->l2_bdaddr, &chan->dst);
la->l2_cid = cpu_to_le16(chan->dcid);
la->l2_bdaddr_type = chan->dst_type;
} else {
- la->l2_psm = chan->sport;
bacpy(&la->l2_bdaddr, &chan->src);
la->l2_cid = cpu_to_le16(chan->scid);
la->l2_bdaddr_type = chan->src_type;
--
1.8.5.3
^ permalink raw reply related
* [PATCH 3/4] Bluetooth: Refuse peer RFCOMM address reading when not connected
From: johan.hedberg @ 2014-01-28 23:16 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1390951011-30576-1-git-send-email-johan.hedberg@gmail.com>
From: Johan Hedberg <johan.hedberg@intel.com>
When we're not connected the peer address information is undefined. This
patch fixes the remote address getting to return a proper error in case
the sate is anything else than BT_CONNECTED.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
---
net/bluetooth/rfcomm/sock.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
index fb8158af1f39..00573fb79030 100644
--- a/net/bluetooth/rfcomm/sock.c
+++ b/net/bluetooth/rfcomm/sock.c
@@ -528,6 +528,9 @@ static int rfcomm_sock_getname(struct socket *sock, struct sockaddr *addr, int *
BT_DBG("sock %p, sk %p", sock, sk);
+ if (peer && sk->sk_state != BT_CONNECTED)
+ return -ENOTCONN;
+
memset(sa, 0, sizeof(*sa));
sa->rc_family = AF_BLUETOOTH;
sa->rc_channel = rfcomm_pi(sk)->channel;
--
1.8.5.3
^ permalink raw reply related
* [PATCH 2/4] Bluetooth: Refuse peer L2CAP address reading when not connected
From: johan.hedberg @ 2014-01-28 23:16 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1390951011-30576-1-git-send-email-johan.hedberg@gmail.com>
From: Johan Hedberg <johan.hedberg@intel.com>
When we're not connected the peer address information is undefined. This
patch fixes the remote address getting to return a proper error in case
the state is anything else than BT_CONNECTED.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
---
net/bluetooth/l2cap_sock.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index 304fc8589af4..a0b8c7aa448e 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -366,6 +366,9 @@ static int l2cap_sock_getname(struct socket *sock, struct sockaddr *addr,
BT_DBG("sock %p, sk %p", sock, sk);
+ if (peer && sk->sk_state != BT_CONNECTED)
+ return -ENOTCONN;
+
memset(la, 0, sizeof(struct sockaddr_l2));
addr->sa_family = AF_BLUETOOTH;
*len = sizeof(struct sockaddr_l2);
--
1.8.5.3
^ permalink raw reply related
* [PATCH 1/4] Bluetooth: Free up l2cap_chan->sport when initiating a connection
From: johan.hedberg @ 2014-01-28 23:16 UTC (permalink / raw)
To: linux-bluetooth
From: Johan Hedberg <johan.hedberg@intel.com>
The sport variable is used to track the allocation of the local PSM
database to ensure no two sockets take the same local PSM. It is
acquired upon bind() but needs to be freed up if the socket ends up
becoming a client one. This patch adds the clearing of the value when
l2cap_chan_connect is called.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
---
net/bluetooth/l2cap_core.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index d2ef49b54aa2..f583988a4653 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -7126,6 +7126,13 @@ int l2cap_chan_connect(struct l2cap_chan *chan, __le16 psm, u16 cid,
l2cap_state_change(chan, BT_CONNECT);
__set_chan_timer(chan, chan->ops->get_sndtimeo(chan));
+ /* Release chan->sport so that it can be reused by other
+ * sockets (as it's only used for listening sockets).
+ */
+ write_lock(&chan_list_lock);
+ chan->sport = 0;
+ write_unlock(&chan_list_lock);
+
if (hcon->state == BT_CONNECTED) {
if (chan->chan_type != L2CAP_CHAN_CONN_ORIENTED) {
__clear_chan_timer(chan);
--
1.8.5.3
^ permalink raw reply related
* [PATCH] Bluetooth: Fix consistency of local vs remote PSM reporting
From: johan.hedberg @ 2014-01-28 22:13 UTC (permalink / raw)
To: linux-bluetooth
From: Johan Hedberg <johan.hedberg@intel.com>
When we're the initiators of a connection the PSM resides on the remote
side and when we're acceptors on the local side. Since the PSM isn't
defined for the initiating side for all practical purposes it should
have the value 0 if requested by user space.
The l2cap_chan structure contains two values for a PSM, psm and sport,
which are used to return the value for getsockname() and getpeername().
However, the values returned haven't really been consistent. When we
initiate an outgoing connection the sport value should be set to 0, and
when we receive an incoming connect request the sport of the newly
created l2cap_chan should reflect the targetted PSM.
It's important the chan->psm has always a valid value since there are
several code paths that rely on it being set regardless of acceptor or
initiator use cases.
This patch updates the relevant outgoing and incoming connection paths
to ensure that the psm and sport l2cap_chan members have the appropriate
values in all cases.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
---
net/bluetooth/l2cap_core.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index d2ef49b54aa2..a5519a8dcb65 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -3774,7 +3774,8 @@ static struct l2cap_chan *l2cap_connect(struct l2cap_conn *conn,
bacpy(&chan->dst, &conn->hcon->dst);
chan->src_type = bdaddr_type(conn->hcon, conn->hcon->src_type);
chan->dst_type = bdaddr_type(conn->hcon, conn->hcon->dst_type);
- chan->psm = psm;
+ chan->psm = psm;
+ chan->sport = psm;
chan->dcid = scid;
chan->local_amp_id = amp_id;
@@ -5421,7 +5422,8 @@ static int l2cap_le_connect_req(struct l2cap_conn *conn,
bacpy(&chan->dst, &conn->hcon->dst);
chan->src_type = bdaddr_type(conn->hcon, conn->hcon->src_type);
chan->dst_type = bdaddr_type(conn->hcon, conn->hcon->dst_type);
- chan->psm = psm;
+ chan->psm = psm;
+ chan->sport = psm;
chan->dcid = scid;
chan->omtu = mtu;
chan->remote_mps = mps;
@@ -7083,6 +7085,7 @@ int l2cap_chan_connect(struct l2cap_chan *chan, __le16 psm, u16 cid,
chan->dst_type = dst_type;
chan->psm = psm;
+ chan->sport = 0;
chan->dcid = cid;
auth_type = l2cap_get_auth_type(chan);
--
1.8.5.3
^ permalink raw reply related
* Re: [PATCH] Bluetooth: hidp: make sure input buffers are big enough
From: Jiri Kosina @ 2014-01-28 20:53 UTC (permalink / raw)
To: David Herrmann
Cc: Marcel Holtmann, open list:HID CORE LAYER,
linux-bluetooth@vger.kernel.org development, Gustavo F. Padovan
In-Reply-To: <alpine.LNX.2.00.1401071811530.4962@pobox.suse.cz>
On Tue, 7 Jan 2014, Jiri Kosina wrote:
> > > So doing kzalloc(rsize, GFP_ATOMIC) in the HID-core for now, and copying
> > > the buffer around, seems like only viable solution for now, with the
> > > outlook of removing this ugliness once hid-core honors 'size' properly.
> >
> > Should I resend the patches and move it to hid_input_report() for now?
> > Or are you getting something in yourself?
>
> Due to various reasons I will not have access to any testing HW for the
> upcoming 2-3 days, so if you can cook something up in that timeframe, it'd
> be appreciated.
>
> Otherwise I'll be working on it by the end of this week.
David,
just got back to this, finally ... did you have time to work on this at
all, or should I just start from scratch?
> > Given the amount of reports on the list and bugzilla, I think we should
> > get this fix in asap. We can always fix it properly in -next.
>
> Agreed.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH BlueZ] audio/AVRCP: Fix sending invalid response to GetCapabilities
From: Luiz Augusto von Dentz @ 2014-01-28 20:05 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The attribute count has to be initialized with 0 since we reuse the same
buffer for both command and responses it may be already be set causing
invalid response to be generated.
---
profiles/audio/avrcp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/profiles/audio/avrcp.c b/profiles/audio/avrcp.c
index 59a966e..ad5dc34 100644
--- a/profiles/audio/avrcp.c
+++ b/profiles/audio/avrcp.c
@@ -921,6 +921,7 @@ static uint8_t avrcp_handle_get_capabilities(struct avrcp *session,
return AVC_CTYPE_STABLE;
case CAP_EVENTS_SUPPORTED:
+ pdu->params[1] = 0;
for (i = 1; i <= AVRCP_EVENT_LAST; i++) {
if (session->supported_events & (1 << i)) {
pdu->params[1]++;
--
1.8.4.2
^ 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