* Re: Passive scanning of iBeacons results in a "Data Buffer Overflow"
From: Adam Warski @ 2014-03-05 20:41 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: BlueZ development
In-Reply-To: <CAJdJm_MXR08tvceb0-vHT=VD+dKY_dz2MbkO3eaUoBneeFxXMA@mail.gmail.com>
Hello,
I recompiled the kernel with dynamic debug, and here are the two files as per your instructions:
http://www.warski.org/ibeacons/dmesg.txt
http://www.warski.org/ibeacons/lescan.dump
I also tried another thing. I have two kinds of beacons: one coming from Estimote, the other from Qualcomm (Gimbal).
The Estimote beacons broadcast the advertisement packets with the same source address (well, it changes, but rarely). Hence to get all the packets the --duplicates flag is needed.
The Gimbal beacons broadcast with a different source address every time (random address). Hence to get all the packets the duplicate flag isn’t needed, as every packet is different.
Both transmit at a similar rate (maybe the Gimbals are a bit slower, but I also tried decreasing the scanning interval in hcitool), and with the Gimbal beacons the are no problems. So I guess this puts more doubt on possible USB cause? (and I checked the USB hub, it works fine as far as I can tell)
The root cause must be something with the usage of the --duplicates flag, no? Though I can’t find the code that it is handling the buffering - is it done on the dongle itself?
Adam
On 04 Mar 2014, at 00:07, Anderson Lizardo <anderson.lizardo@openbossa.org> wrote:
> Hi Adam,
>
> On Mon, Mar 3, 2014 at 5:25 PM, Adam Warski <adam@warski.org> wrote:
>> But I guess even if it was a USB issue, it would be caught earlier? The advertisement packets have a certain preamble, and a CRC, so the shifted data would be discarded? Anyway, that doesn't seem to be the cause.
>
> There are are a few things that point out to USB issue (in my opinion):
>
> 1) You said that having ethernet cable connected or not modifies the
> behavior. on RPI, the ethernet chip is attached to the USB. As I said,
> strange things happen to me as well when not using powered USB hub
> (specially with WiFi dongles and USB cameras) :)
>
> 2) As you noticed, the "truncated" adv. packet is not being discarded
> by the controller as we would expect. This means that the BT
> controller is actually receiving a correct packet, but it is being
> "truncated" when being sent to the host. The CRC/preamble, after
> parsed and verified by the BT controller, is removed before sending
> the packet to the host, so there is no way for the host do detect
> corruptions between the BT controller and the kernel.
>
> The dynamic debug messages may help identify whether there are
> missing/truncated USB packets (there is a debug message in
> btusb_intr_complete() from drivers/bluetooth/btusb.c to help identify
> HCI reassembly issues).
>
> Did you try using only the BT dongle and removing the Wifi one (and
> connecting through ethernet cable)? Wifi dongles tend to be very power
> hungry.
>
> Also check whether the power source for the USB hub is working
> properly... unfortunately I don't know how to check from the RPi side,
> so you have to rely on first attaching it to the outlet, checking some
> LED, and then attaching to the RPi. Also make sure the RPi uses its
> own power adapter (instead of powering from the hub itself).
>
> Well, at least you found a workaround (attaching an ethernet cable) :)
>
> Best Regards,
> --
> Anderson Lizardo
> http://www.indt.org/?lang=en
> INdT - Manaus - Brazil
> --
> 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
--
Adam Warski
http://twitter.com/#!/adamwarski
http://www.softwaremill.com
http://www.warski.org
^ permalink raw reply
* Re: [RFC BlueZ 0/3] Fix GATT server issues with BlueZ as LE peripheral
From: Johan Hedberg @ 2014-03-05 20:40 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <1390924298-13804-1-git-send-email-anderson.lizardo@openbossa.org>
Hi Lizardo,
On Tue, Jan 28, 2014, Anderson Lizardo wrote:
> Currently, we do not officially support running BlueZ as LE peripheral. But
> there is already enough support from the kernel to support this. For instance,
> there is the "Set Advertising" mgmt command to keep LE advertising enabled
> after each connection.
>
> The current tracking of connections in BlueZ does not fully work for peripheral
> role. These patches are a first attempt to improve the situation. Other fixes
> are necessary to have full LE Peripheral support.
>
> In particular, with these patches, notifications for PASP and ANP profiles
> (implemented in profiles/alert/*) should work when BlueZ is on the peripheral
> role. Other GATT server profiles will need fixing as well.
>
> I'm sending as RFC because I only did minimal testing. I hope that people
> having issues with GATT server profiles running on peripheral role can tests
> these patches. Otherwise, I'll do more tests later today and send a final
> version by tomorrow.
>
> Notes:
> * The first patch is just cleanup, so can be applied as is.
> * For testing, make sure to enable advertising on the machine running as
> peripheral (I use btmgmt tool for this).
>
> Best Regards,
> Anderson Lizardo
>
> Anderson Lizardo (3):
> attrib-server: Remove unnecessary fields from struct gatt_channel
> core: Fix associating a GAttrib to a device on incoming connections
> alert: Only remove attio callback after ATT request was sent
>
> profiles/alert/server.c | 18 +++++++++++++++++-
> src/attrib-server.c | 45 +++++++++++++++++++++++++++++----------------
> src/attrib-server.h | 1 +
> src/device.c | 5 +++++
> 4 files changed, 52 insertions(+), 17 deletions(-)
These patches seem to have been forgotten about. They looked fairly good
to me so I rebased and applied them finally.
Johan
^ permalink raw reply
* Re: [PATCH v3] various header include fixes for building with musl libc
From: Johan Hedberg @ 2014-03-05 20:32 UTC (permalink / raw)
To: Natanael Copa; +Cc: linux-bluetooth, Natanael Copa
In-Reply-To: <1390425638-15241-1-git-send-email-ncopa@alpinelinux.org>
Hi Natanael,
On Wed, Jan 22, 2014, Natanael Copa wrote:
> we need:
> sys/stat.h for mode_t
> limits.h for PATH_MAX
>
> Fixes compile errors:
> In file included from tools/hciconfig.c:45:0:
> ./src/textfile.h:27:1: error: unknown type name 'mode_t'
> int create_file(const char *filename, const mode_t mode);
> ^
>
> tools/csr_usb.c: In function 'read_value':
> tools/csr_usb.c:71:12: error: 'PATH_MAX' undeclared (first use in this function)
> char path[PATH_MAX];
> ^
> ---
> Changes v2 -> v3:
> - include the sys/stat.h in hciconfig.c instead of textfile.h. This was
> the only needed change for defining mode_t everywhere.
>
> tools/csr_usb.c | 1 +
> tools/hciconfig.c | 1 +
> tools/hid2hci.c | 1 +
> 3 files changed, 3 insertions(+)
Seems this patch was forgotten. It has now finally been applied
upstream.
Johan
^ permalink raw reply
* Re: [PATCH 1/4] android/hal-gatt-api: Rename Service ID to GATT Service ID
From: Szymon Janc @ 2014-03-05 19:53 UTC (permalink / raw)
To: Jakub Tyszkowski; +Cc: linux-bluetooth
In-Reply-To: <1394030639-28134-1-git-send-email-jakub.tyszkowski@tieto.com>
Hi Jakub,
On Wednesday 05 March 2014 15:43:56 Jakub Tyszkowski wrote:
> Use "GATT Service ID" instead "Service ID" inside ipc documentation
> which is used to describe Core services like HAL_SERVICE_ID_GATT
> himself.
> ---
> android/hal-ipc-api.txt | 46 ++++++++++++++++++++++------------------------
> 1 file changed, 22 insertions(+), 24 deletions(-)
>
> diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
> index 43b79ec..4f1b74d 100644
> --- a/android/hal-ipc-api.txt
> +++ b/android/hal-ipc-api.txt
> @@ -1496,15 +1496,13 @@ Android HAL name: "gatt" (BT_PROFILE_GATT_ID)
> Opcode 0x09 - Get Included Service command/response
>
> Command parameters: Connection ID (4 octets)
> - Number of Service ID Elements (1 octet)
> - Service ID Elements (variable)
> + Number of GATT Service ID Elements (1 octet)
> + GATT Service ID Elements (variable)
> Valid Number of Service ID Elements: 0x01
> 0x02
> - Valid Service ID Element: UUID (16 octets)
> - Instance ID (1 octet)
> - Is Primary (1 octet)
> - Valid GATT ID: UUID (16 octets)
> - Instance ID (1 octet)
> + Valid GATT Service ID Element: UUID (16 octets)
> + Instance ID (1 octet)
> + Is Primary (1 octet)
> Response parameters: <none>
>
> In case of an error, the error response will be returned.
> @@ -1512,10 +1510,10 @@ Android HAL name: "gatt" (BT_PROFILE_GATT_ID)
> Opcode 0x0a - Get Characteristic command/response
>
> Command parameters: Connection ID (4 octets)
> - Service ID (18 octets)
> + GATT Service ID (18 octets)
> Number of GATT ID Elements (1 octet)
> GATT ID Elements (variable)
> - Valid Service ID: as described in Get Included Service
> + Valid GATT Service ID: as described in Get Included Service
> Valid Number of GATT ID Elements: 0x00
> 0x01
> Valid GATT ID Element: as described in Get Included Service
> @@ -1526,10 +1524,10 @@ Android HAL name: "gatt" (BT_PROFILE_GATT_ID)
> Opcode 0x0b - Get Descriptor command/response
>
> Command parameters: Connection ID (4 octets)
> - Service ID (18 octets)
> + GATT Service ID (18 octets)
> Number of GATT ID Elements (1 octet)
> GATT ID Elements (variable)
> - Valid Service ID: as described in Get Included Service
> + Valid GATT Service ID: as described in Get Included Service
> Valid Number of GATT ID Elements: 0x01
> 0x02
> Valid GATT ID Element: as described in Get Included Service
> @@ -1540,10 +1538,10 @@ Android HAL name: "gatt" (BT_PROFILE_GATT_ID)
> Opcode 0x0c - Read Characteristic command/response
>
> Command parameters: Connection ID (4 octets)
> - Service ID (18 octets)
> + GATT Service ID (18 octets)
> GATT ID (17 octets)
> Authorization (4 octets)
> - Valid Service ID: as described in Get Included Service
> + Valid GATT Service ID: as described in Get Included Service
> Valid GATT ID: as described in Get Included Service
> Response parameters: <none>
>
> @@ -1552,13 +1550,13 @@ Android HAL name: "gatt" (BT_PROFILE_GATT_ID)
> Opcode 0x0d - Write Characteristic command/response
>
> Command parameters: Connection ID (4 octets)
> - Service ID (18 octets)
> + GATT Service ID (18 octets)
> GATT ID (17 octets)
> Write Type (4 octets)
> Length (4 octets)
> Authorization Req. (4 octets)
> Value (variable)
> - Valid Service ID: as described in Get Included Service
> + Valid GATT Service ID: as described in Get Included Service
> Valid GATT ID: as described in Get Included Service
> Response parameters: <none>
>
> @@ -1567,11 +1565,11 @@ Android HAL name: "gatt" (BT_PROFILE_GATT_ID)
> Opcode 0x0e - Read Descriptor command/response
>
> Command parameters: Connection ID (4 octets)
> - Service ID (18 octets)
> + GATT Service ID (18 octets)
> GATT ID (17 octets)
> Descr. GATT ID (17 octets)
> Authorization Req. (4 octets)
> - Valid Service ID: as described in Get Included Service
> + Valid GATT Service ID: as described in Get Included Service
> Valid GATT ID: as described in Get Included Service
> Response parameters: <none>
>
> @@ -1580,14 +1578,14 @@ Android HAL name: "gatt" (BT_PROFILE_GATT_ID)
> Opcode 0x0f - Write Descriptor command/response
>
> Command parameters: Connection ID (4 octets)
> - Service ID (18 octets)
> + GATT Service ID (18 octets)
> GATT ID (17 octets)
> Descr. GATT ID (17 octets)
> Write Type (4 octets)
> Length (4 octets)
> Authorization Req. (4 octets)
> Value (variable)
> - Valid Service ID: as described in Get Included Service
> + Valid GATT Service ID: as described in Get Included Service
> Valid GATT ID: as described in Get Included Service
> Response parameters: <none>
>
> @@ -1605,7 +1603,7 @@ Android HAL name: "gatt" (BT_PROFILE_GATT_ID)
>
> Command parameters: Client Interface (4 octets)
> Remote address (6 octets)
> - Service ID (18 octets)
> + GATT Service ID (18 octets)
> GATT ID (17 octets)
> Response parameters: <none>
>
> @@ -1615,7 +1613,7 @@ Android HAL name: "gatt" (BT_PROFILE_GATT_ID)
>
> Command parameters: Client Interface (4 octets)
> Remote address (6 octets)
> - Service ID (18 octets)
> + GATT Service ID (18 octets)
> GATT ID (17 octets)
> Response parameters: <none>
>
> @@ -1973,9 +1971,9 @@ Android HAL name: "gatt" (BT_PROFILE_GATT_ID)
> GATT Service ID (18 octets)
> Service Handle (4 octets)
>
> - Valid Service ID: UUID (16 octets)
> - Instance ID (1 octet)
> - Is Primary (1 octet)
> + Valid GATT Service ID: UUID (16 octets)
> + Instance ID (1 octet)
> + Is Primary (1 octet)
>
> Opcode 0x96 - Included Service Added notification
All patches applied, thanks.
--
Szymon K. Janc
szymon.janc@gmail.com
^ permalink raw reply
* [PATCHv2 11/11] shared/hfp: Don't try read uninitialized data in ringbuffer
From: Marcin Kraglak @ 2014-03-05 19:22 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1394047376-11495-1-git-send-email-marcin.kraglak@tieto.com>
Don't try to read uninitialized value if '\r' was not found.
This is call stack from test-hfp run with valgrind:
/hfp/test_fragmented_1: ==24869== Conditional jump or move depends on uninitialised value(s)
==24869== at 0x400A5E4: memchr (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==24869== by 0x804D24D: can_read_data (hfp.c:359)
==24869== by 0x804A6E2: read_callback (io-glib.c:168)
==24869== by 0x4108BFD5: ??? (in /usr/lib/libglib-2.0.so.0.3600.4)
==24869== by 0x410470E5: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.3600.4)
==24869== by 0x41047497: ??? (in /usr/lib/libglib-2.0.so.0.3600.4)
==24869== by 0x41047912: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.3600.4)
==24869== by 0x8049EE0: execute_context (test-hfp.c:186)
==24869== by 0x4106CBC1: ??? (in /usr/lib/libglib-2.0.so.0.3600.4)
==24869== by 0x4106CD5B: ??? (in /usr/lib/libglib-2.0.so.0.3600.4)
==24869== by 0x4106D0E0: g_test_run_suite (in /usr/lib/libglib-2.0.so.0.3600.4)
==24869== by 0x4106D13C: g_test_run (in /usr/lib/libglib-2.0.so.0.3600.4)
---
src/shared/hfp.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/src/shared/hfp.c b/src/shared/hfp.c
index 9523243..1be53fb 100644
--- a/src/shared/hfp.c
+++ b/src/shared/hfp.c
@@ -374,6 +374,12 @@ static void process_input(struct hfp_gw *hfp)
char *str2;
size_t len2;
+ /* If there is no more data in ringbuffer,
+ * it's just an incomplete command.
+ */
+ if (len == ringbuf_len(hfp->read_buf))
+ return;
+
str2 = ringbuf_peek(hfp->read_buf, len, &len2);
if (!str2)
return;
--
1.8.3.1
^ permalink raw reply related
* [PATCHv2 10/11] unit/test-hfp: Add /hfp/test_fragmented_1
From: Marcin Kraglak @ 2014-03-05 19:22 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1394047376-11495-1-git-send-email-marcin.kraglak@tieto.com>
---
unit/test-hfp.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/unit/test-hfp.c b/unit/test-hfp.c
index 546a239..5218a2b 100644
--- a/unit/test-hfp.c
+++ b/unit/test-hfp.c
@@ -45,6 +45,7 @@ struct test_pdu {
const uint8_t *data;
size_t size;
enum hfp_gw_cmd_type type;
+ bool fragmented;
};
struct test_data {
@@ -74,6 +75,14 @@ struct test_data {
.type = cmd_type, \
}
+#define frg_pdu(args...) \
+ { \
+ .valid = true, \
+ .data = data(args), \
+ .size = sizeof(data(args)), \
+ .fragmented = true, \
+ }
+
#define define_test(name, function, args...) \
do { \
const struct test_pdu pdus[] = { \
@@ -255,6 +264,40 @@ static void test_register(gconstpointer data)
execute_context(context);
}
+static gboolean send_pdu(gpointer user_data)
+{
+ struct context *context = user_data;
+ const struct test_pdu *pdu;
+ ssize_t len;
+
+ pdu = &context->data->pdu_list[context->pdu_offset++];
+
+ len = write(context->fd_server, pdu->data, pdu->size);
+ g_assert_cmpint(len, ==, pdu->size);
+
+ pdu = &context->data->pdu_list[context->pdu_offset];
+ if (pdu->fragmented)
+ g_idle_add(send_pdu, context);
+
+ return FALSE;
+}
+
+static void test_fragmented(gconstpointer data)
+{
+ struct context *context = create_context(data);
+ bool ret;
+
+ context->hfp = hfp_gw_new(context->fd_client);
+ g_assert(context->hfp);
+
+ ret = hfp_gw_set_close_on_unref(context->hfp, true);
+ g_assert(ret);
+
+ g_idle_add(send_pdu, context);
+
+ execute_context(context);
+}
+
int main(int argc, char *argv[])
{
g_test_init(&argc, &argv, NULL);
@@ -294,6 +337,10 @@ int main(int argc, char *argv[])
raw_pdu('A', 'T', 'D', '1', '2', '3', '4', '5', '\r'),
type_pdu(HFP_GW_CMD_TYPE_SET, 0),
data_end());
+ define_test("/hfp/test_fragmented_1", test_fragmented,
+ frg_pdu('A'), frg_pdu('T'), frg_pdu('+'), frg_pdu('B'),
+ frg_pdu('R'), frg_pdu('S'), frg_pdu('F'), frg_pdu('\r'),
+ data_end());
return g_test_run();
}
--
1.8.3.1
^ permalink raw reply related
* [PATCHv2 09/11] unit/test-hfp: Add /hfp/test_register_5
From: Marcin Kraglak @ 2014-03-05 19:22 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1394047376-11495-1-git-send-email-marcin.kraglak@tieto.com>
---
unit/test-hfp.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/unit/test-hfp.c b/unit/test-hfp.c
index 85d3a60..546a239 100644
--- a/unit/test-hfp.c
+++ b/unit/test-hfp.c
@@ -289,6 +289,11 @@ int main(int argc, char *argv[])
'\r'),
type_pdu(HFP_GW_CMD_TYPE_TEST, 0),
data_end());
+ define_test("/hfp/test_register_5", test_register,
+ raw_pdu('D', '\0'),
+ raw_pdu('A', 'T', 'D', '1', '2', '3', '4', '5', '\r'),
+ type_pdu(HFP_GW_CMD_TYPE_SET, 0),
+ data_end());
return g_test_run();
}
--
1.8.3.1
^ permalink raw reply related
* [PATCHv2 08/11] unit/test-hfp: Add /hfp/test_register_4
From: Marcin Kraglak @ 2014-03-05 19:22 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1394047376-11495-1-git-send-email-marcin.kraglak@tieto.com>
---
unit/test-hfp.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/unit/test-hfp.c b/unit/test-hfp.c
index a5fe436..85d3a60 100644
--- a/unit/test-hfp.c
+++ b/unit/test-hfp.c
@@ -283,6 +283,12 @@ int main(int argc, char *argv[])
raw_pdu('A', 'T', '+', 'B', 'R', 'S', 'F', '?', '\r'),
type_pdu(HFP_GW_CMD_TYPE_READ, 0),
data_end());
+ define_test("/hfp/test_register_4", test_register,
+ raw_pdu('+', 'B', 'R', 'S', 'F', '\0'),
+ raw_pdu('A', 'T', '+', 'B', 'R', 'S', 'F', '=', '?',
+ '\r'),
+ type_pdu(HFP_GW_CMD_TYPE_TEST, 0),
+ data_end());
return g_test_run();
}
--
1.8.3.1
^ permalink raw reply related
* [PATCHv2 07/11] unit/test-hfp: Add /hfp/test_register_3
From: Marcin Kraglak @ 2014-03-05 19:22 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1394047376-11495-1-git-send-email-marcin.kraglak@tieto.com>
---
unit/test-hfp.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/unit/test-hfp.c b/unit/test-hfp.c
index cb422d4..a5fe436 100644
--- a/unit/test-hfp.c
+++ b/unit/test-hfp.c
@@ -278,6 +278,11 @@ int main(int argc, char *argv[])
raw_pdu('A', 'T', '+', 'B', 'R', 'S', 'F', '=', '\r'),
type_pdu(HFP_GW_CMD_TYPE_SET, 0),
data_end());
+ define_test("/hfp/test_register_3", test_register,
+ raw_pdu('+', 'B', 'R', 'S', 'F', '\0'),
+ raw_pdu('A', 'T', '+', 'B', 'R', 'S', 'F', '?', '\r'),
+ type_pdu(HFP_GW_CMD_TYPE_READ, 0),
+ data_end());
return g_test_run();
}
--
1.8.3.1
^ permalink raw reply related
* [PATCHv2 06/11] unit/test-hfp: Add /hfp/test_register_2
From: Marcin Kraglak @ 2014-03-05 19:22 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1394047376-11495-1-git-send-email-marcin.kraglak@tieto.com>
---
unit/test-hfp.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/unit/test-hfp.c b/unit/test-hfp.c
index f202f91..cb422d4 100644
--- a/unit/test-hfp.c
+++ b/unit/test-hfp.c
@@ -273,6 +273,11 @@ int main(int argc, char *argv[])
raw_pdu('A', 'T', '+', 'B', 'R', 'S', 'F', '\r'),
type_pdu(HFP_GW_CMD_TYPE_COMMAND, 0),
data_end());
+ define_test("/hfp/test_register_2", test_register,
+ raw_pdu('+', 'B', 'R', 'S', 'F', '\0'),
+ raw_pdu('A', 'T', '+', 'B', 'R', 'S', 'F', '=', '\r'),
+ type_pdu(HFP_GW_CMD_TYPE_SET, 0),
+ data_end());
return g_test_run();
}
--
1.8.3.1
^ permalink raw reply related
* [PATCHv2 05/11] unit/test-hfp: Add /hfp/test_register_1
From: Marcin Kraglak @ 2014-03-05 19:22 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1394047376-11495-1-git-send-email-marcin.kraglak@tieto.com>
---
unit/test-hfp.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/unit/test-hfp.c b/unit/test-hfp.c
index 1a22298..f202f91 100644
--- a/unit/test-hfp.c
+++ b/unit/test-hfp.c
@@ -44,6 +44,7 @@ struct test_pdu {
bool valid;
const uint8_t *data;
size_t size;
+ enum hfp_gw_cmd_type type;
};
struct test_data {
@@ -65,6 +66,14 @@ struct test_data {
.valid = false, \
}
+#define type_pdu(cmd_type, args...) \
+ { \
+ .valid = true, \
+ .data = data(args), \
+ .size = sizeof(data(args)), \
+ .type = cmd_type, \
+ }
+
#define define_test(name, function, args...) \
do { \
const struct test_pdu pdus[] = { \
@@ -118,6 +127,19 @@ static void cmd_handler(const char *command, void *user_data)
hfp_gw_send_result(context->hfp, HFP_RESULT_ERROR);
}
+static void prefix_handler(struct hfp_gw_result *result,
+ enum hfp_gw_cmd_type type, void *user_data)
+{
+ struct context *context = user_data;
+ const struct test_pdu *pdu;
+
+ pdu = &context->data->pdu_list[context->pdu_offset++];
+
+ g_assert(type == pdu->type);
+
+ hfp_gw_send_result(context->hfp, HFP_RESULT_ERROR);
+}
+
static struct context *create_context(gconstpointer data)
{
struct context *context = g_new0(struct context, 1);
@@ -206,6 +228,33 @@ static void test_command_handler(gconstpointer data)
execute_context(context);
}
+static void test_register(gconstpointer data)
+{
+ struct context *context = create_context(data);
+ const struct test_pdu *pdu;
+ ssize_t len;
+ bool ret;
+
+ context->hfp = hfp_gw_new(context->fd_client);
+ g_assert(context->hfp);
+
+ pdu = &context->data->pdu_list[context->pdu_offset++];
+
+ ret = hfp_gw_set_close_on_unref(context->hfp, true);
+ g_assert(ret);
+
+ ret = hfp_gw_register(context->hfp, prefix_handler, (char *)pdu->data,
+ context, NULL);
+ g_assert(ret);
+
+ pdu = &context->data->pdu_list[context->pdu_offset++];
+
+ len = write(context->fd_server, pdu->data, pdu->size);
+ g_assert_cmpint(len, ==, pdu->size);
+
+ execute_context(context);
+}
+
int main(int argc, char *argv[])
{
g_test_init(&argc, &argv, NULL);
@@ -219,6 +268,11 @@ int main(int argc, char *argv[])
raw_pdu('A', 'T', 'D', '1', '2', '3', '4', '\r'),
raw_pdu('A', 'T', 'D', '1', '2', '3', '4'),
data_end());
+ define_test("/hfp/test_register_1", test_register,
+ raw_pdu('+', 'B', 'R', 'S', 'F', '\0'),
+ raw_pdu('A', 'T', '+', 'B', 'R', 'S', 'F', '\r'),
+ type_pdu(HFP_GW_CMD_TYPE_COMMAND, 0),
+ data_end());
return g_test_run();
}
--
1.8.3.1
^ permalink raw reply related
* [PATCHv2 04/11] unit/test-hfp: Add /hfp/test_cmd_handler_2
From: Marcin Kraglak @ 2014-03-05 19:22 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1394047376-11495-1-git-send-email-marcin.kraglak@tieto.com>
---
unit/test-hfp.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/unit/test-hfp.c b/unit/test-hfp.c
index 5e16378..1a22298 100644
--- a/unit/test-hfp.c
+++ b/unit/test-hfp.c
@@ -215,6 +215,10 @@ int main(int argc, char *argv[])
raw_pdu('A', 'T', '+', 'B', 'R', 'S', 'F', '\r'),
raw_pdu('A', 'T', '+', 'B', 'R', 'S', 'F'),
data_end());
+ define_test("/hfp/test_cmd_handler_2", test_command_handler,
+ raw_pdu('A', 'T', 'D', '1', '2', '3', '4', '\r'),
+ raw_pdu('A', 'T', 'D', '1', '2', '3', '4'),
+ data_end());
return g_test_run();
}
--
1.8.3.1
^ permalink raw reply related
* [PATCHv2 03/11] unit/test-hfp: Add /hfp/test_cmd_handler_1
From: Marcin Kraglak @ 2014-03-05 19:22 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1394047376-11495-1-git-send-email-marcin.kraglak@tieto.com>
---
unit/test-hfp.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/unit/test-hfp.c b/unit/test-hfp.c
index f220569..5e16378 100644
--- a/unit/test-hfp.c
+++ b/unit/test-hfp.c
@@ -104,6 +104,20 @@ static gboolean test_handler(GIOChannel *channel, GIOCondition cond,
return FALSE;
}
+static void cmd_handler(const char *command, void *user_data)
+{
+ struct context *context = user_data;
+ const struct test_pdu *pdu;
+ unsigned int cmd_len = strlen(command);
+
+ pdu = &context->data->pdu_list[context->pdu_offset++];
+
+ g_assert(cmd_len == pdu->size);
+ g_assert(!memcmp(command, pdu->data, cmd_len));
+
+ hfp_gw_send_result(context->hfp, HFP_RESULT_ERROR);
+}
+
static struct context *create_context(gconstpointer data)
{
struct context *context = g_new0(struct context, 1);
@@ -146,6 +160,9 @@ static void execute_context(struct context *context)
test_free(context->data);
+ if (context->hfp)
+ hfp_gw_unref(context->hfp);
+
g_free(context);
}
@@ -159,6 +176,32 @@ static void test_init(gconstpointer data)
g_assert(hfp_gw_set_close_on_unref(context->hfp, true));
hfp_gw_unref(context->hfp);
+ context->hfp = NULL;
+
+ execute_context(context);
+}
+
+static void test_command_handler(gconstpointer data)
+{
+ struct context *context = create_context(data);
+ const struct test_pdu *pdu;
+ ssize_t len;
+ bool ret;
+
+ context->hfp = hfp_gw_new(context->fd_client);
+ g_assert(context->hfp);
+
+ pdu = &context->data->pdu_list[context->pdu_offset++];
+
+ ret = hfp_gw_set_close_on_unref(context->hfp, true);
+ g_assert(ret);
+
+ ret = hfp_gw_set_command_handler(context->hfp, cmd_handler,
+ context, NULL);
+ g_assert(ret);
+
+ len = write(context->fd_server, pdu->data, pdu->size);
+ g_assert_cmpint(len, ==, pdu->size);
execute_context(context);
}
@@ -168,6 +211,10 @@ int main(int argc, char *argv[])
g_test_init(&argc, &argv, NULL);
define_test("/hfp/test_init", test_init, data_end());
+ define_test("/hfp/test_cmd_handler_1", test_command_handler,
+ raw_pdu('A', 'T', '+', 'B', 'R', 'S', 'F', '\r'),
+ raw_pdu('A', 'T', '+', 'B', 'R', 'S', 'F'),
+ data_end());
return g_test_run();
}
--
1.8.3.1
^ permalink raw reply related
* [PATCHv2 02/11] unit: Initial version of test-hfp
From: Marcin Kraglak @ 2014-03-05 19:22 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1394047376-11495-1-git-send-email-marcin.kraglak@tieto.com>
This is skeleton of hfp unit tests with basic init test
for hfp_gw_new().
Basic test with hfp_gw_new() and hfp_gw_unref.
---
.gitignore | 1 +
Makefile.am | 12 ++++
unit/test-hfp.c | 173 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 186 insertions(+)
create mode 100644 unit/test-hfp.c
diff --git a/.gitignore b/.gitignore
index 94c0c78..6719be8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -84,6 +84,7 @@ unit/test-gdbus-client
unit/test-sdp
unit/test-lib
unit/test-mgmt
+unit/test-hfp
tools/mgmt-tester
tools/smp-tester
tools/gap-tester
diff --git a/Makefile.am b/Makefile.am
index 0c79e58..0107cef 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -293,6 +293,18 @@ unit_test_avrcp_SOURCES = unit/test-avrcp.c \
android/avrcp-lib.c android/avrcp-lib.h
unit_test_avrcp_LDADD = @GLIB_LIBS@ lib/libbluetooth-internal.la
+unit_tests += unit/test-hfp
+
+unit_test_hfp_SOURCES = unit/test-hfp.c \
+ src/shared/io.h src/shared/io-glib.c \
+ src/shared/queue.h src/shared/queue.c \
+ src/shared/util.h src/shared/util.c \
+ src/shared/mgmt.h src/shared/mgmt.c \
+ src/shared/ringbuf.h src/shared/ringbuf.c \
+ src/shared/hfp.h src/shared/hfp.c
+
+unit_test_hfp_LDADD = @GLIB_LIBS@
+
unit_tests += unit/test-gdbus-client
unit_test_gdbus_client_SOURCES = unit/test-gdbus-client.c
diff --git a/unit/test-hfp.c b/unit/test-hfp.c
new file mode 100644
index 0000000..f220569
--- /dev/null
+++ b/unit/test-hfp.c
@@ -0,0 +1,173 @@
+/*
+ *
+ * BlueZ - Bluetooth protocol stack for Linux
+ *
+ * Copyright (C) 2014 Intel Corporation. All rights reserved.
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#include <sys/socket.h>
+#include <unistd.h>
+#include <stdint.h>
+#include <stdio.h>
+#include <string.h>
+
+#include <glib.h>
+#include "src/shared/hfp.h"
+
+struct context {
+ GMainLoop *main_loop;
+ guint watch_id;
+ int fd_server;
+ int fd_client;
+ struct hfp_gw *hfp;
+ const struct test_data *data;
+ unsigned int pdu_offset;
+};
+
+struct test_pdu {
+ bool valid;
+ const uint8_t *data;
+ size_t size;
+};
+
+struct test_data {
+ char *test_name;
+ struct test_pdu *pdu_list;
+};
+
+#define data(args...) ((const unsigned char[]) { args })
+
+#define raw_pdu(args...) \
+ { \
+ .valid = true, \
+ .data = data(args), \
+ .size = sizeof(data(args)), \
+ }
+
+#define data_end() \
+ { \
+ .valid = false, \
+ }
+
+#define define_test(name, function, args...) \
+ do { \
+ const struct test_pdu pdus[] = { \
+ args, { } \
+ }; \
+ static struct test_data data; \
+ data.test_name = g_strdup(name); \
+ data.pdu_list = g_malloc(sizeof(pdus)); \
+ memcpy(data.pdu_list, pdus, sizeof(pdus)); \
+ g_test_add_data_func(name, &data, function); \
+ } while (0)
+
+static void context_quit(struct context *context)
+{
+ g_main_loop_quit(context->main_loop);
+}
+
+static void test_free(gconstpointer user_data)
+{
+ const struct test_data *data = user_data;
+
+ g_free(data->test_name);
+ g_free(data->pdu_list);
+}
+
+static gboolean test_handler(GIOChannel *channel, GIOCondition cond,
+ gpointer user_data)
+{
+ struct context *context = user_data;
+ const struct test_pdu *pdu;
+
+ pdu = &context->data->pdu_list[context->pdu_offset++];
+
+ g_assert(!pdu->valid);
+ context_quit(context);
+
+ return FALSE;
+}
+
+static struct context *create_context(gconstpointer data)
+{
+ struct context *context = g_new0(struct context, 1);
+ GIOChannel *channel;
+ int err, sv[2];
+
+ context->main_loop = g_main_loop_new(NULL, FALSE);
+ g_assert(context->main_loop);
+
+ err = socketpair(AF_UNIX, SOCK_SEQPACKET | SOCK_CLOEXEC, 0, sv);
+ g_assert(err == 0);
+
+ channel = g_io_channel_unix_new(sv[1]);
+
+ g_io_channel_set_close_on_unref(channel, TRUE);
+ g_io_channel_set_encoding(channel, NULL, NULL);
+ g_io_channel_set_buffered(channel, FALSE);
+
+ context->watch_id = g_io_add_watch(channel,
+ G_IO_IN | G_IO_HUP | G_IO_ERR | G_IO_NVAL,
+ test_handler, context);
+ g_assert(context->watch_id > 0);
+
+ g_io_channel_unref(channel);
+
+ context->fd_server = sv[1];
+ context->fd_client = sv[0];
+ context->data = data;
+
+ return context;
+}
+
+static void execute_context(struct context *context)
+{
+ g_main_loop_run(context->main_loop);
+
+ g_source_remove(context->watch_id);
+
+ g_main_loop_unref(context->main_loop);
+
+ test_free(context->data);
+
+ g_free(context);
+}
+
+static void test_init(gconstpointer data)
+{
+ struct context *context = create_context(data);
+
+ context->hfp = hfp_gw_new(context->fd_client);
+
+ g_assert(context->hfp);
+ g_assert(hfp_gw_set_close_on_unref(context->hfp, true));
+
+ hfp_gw_unref(context->hfp);
+
+ execute_context(context);
+}
+
+int main(int argc, char *argv[])
+{
+ g_test_init(&argc, &argv, NULL);
+
+ define_test("/hfp/test_init", test_init, data_end());
+
+ return g_test_run();
+}
--
1.8.3.1
^ permalink raw reply related
* [PATCHv2 01/11] shared/hfp: Fix not freeing cmd_handler prefix
From: Marcin Kraglak @ 2014-03-05 19:22 UTC (permalink / raw)
To: linux-bluetooth
It should be freed while destroy.
---
src/shared/hfp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/shared/hfp.c b/src/shared/hfp.c
index 08393d8..9523243 100644
--- a/src/shared/hfp.c
+++ b/src/shared/hfp.c
@@ -82,6 +82,8 @@ static void destroy_cmd_handler(void *data)
if (handler->destroy)
handler->destroy(handler->user_data);
+ free(handler->prefix);
+
free(handler);
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] Revert "Bluetooth: Use devname:vhci module alias for virtual HCI driver"
From: Marcel Holtmann @ 2014-03-05 19:02 UTC (permalink / raw)
To: Josh Boyer
Cc: Thomas Bächler, Gustavo F. Padovan, Johan Hedberg,
bluez mailin list (linux-bluetooth@vger.kernel.org),
Linux-Kernel@Vger. Kernel. Org
In-Reply-To: <CA+5PVA6vkGHJGMgEYCTSdvqOuMb-fHURVvP-sHAofd6840TLOQ@mail.gmail.com>
Hi Josh,
>>>>>> This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
>>>>>
>>>>> NAK. We allocated a static minor for this.
>>>>
>>>> Johan mentioned that. Commit b075dd40c95d11c2c8690f6c4d6232fc,
>>>> correct?
>>
>> I am sorry Marcel, I only looked at the Linus tree, not at bluetooth or
>> bluetooth-next. This commit should indeed fix the problem. Disregard my
>> patch.
>>
>>> Why isn't that headed into 3.14 right now, and CC'd to
>>>> stable? Currently you have a somewhat broken driver in 3.13 and
>>>> 3.14-rcX that seems to have a pretty clear fix.
>>>
>>> somewhat broken? kmod prints this as an error, but it is not a regression in user functionality. The driver works just as before. The error message can be ignored.
>>
>> It's a regression in my sanity, since numerous users blame all kernel
>> bugs on this error message and I am tired of explaining the situation
>> (problem + error message == problem found *sigh*). I only sent this
>> patch since I hadn't found the correct fix.
>
> Exactly.
>
>>> So if anybody feels strongly that the static device node assignment should be put into -stable, then I am fine with it. However I do not see this as passing requirement for a -stable fix since it is really not affecting anyone (minus the misleading message from kmod).
>>
>> Since b075dd4 will end up in the Linus tree eventually, I have no
>> trouble backporting it myself.
>
> I don't have any difficulty doing that either, but if it was in stable
> every distro getting bugs about it wouldn't have to carry the fix on
> their own.
the patch is currently in wireless-next and will eventually end up in net-next. Maybe it is better to have it cherry picked once it reaches net-next.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Add a new PID/VID 0cf3/e005 for AR3012.
From: Johan Hedberg @ 2014-03-05 18:59 UTC (permalink / raw)
To: Peng Chen; +Cc: gustavo, linux-bluetooth, marcel, kumo, taowang
In-Reply-To: <1377853792-17589-1-git-send-email-pengchen@qca.qualcomm.com>
Hi,
On Fri, Aug 30, 2013, Peng Chen wrote:
> usb devices info:
>
> T: Bus=06 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 13 Spd=12 MxCh= 0
> D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=0cf3 ProdID=e005 Rev= 0.02
> C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
> I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
> E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
> E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
> E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
> E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
> E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
> E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
> E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
> E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
>
> Signed-off-by: Peng Chen <pengchen@qca.qualcomm.com>
> ---
> drivers/bluetooth/ath3k.c | 2 ++
> drivers/bluetooth/btusb.c | 1 +
> 2 files changed, 3 insertions(+)
Applied to bluetooth-next. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: Remove assignment in if
From: Johan Hedberg @ 2014-03-05 18:58 UTC (permalink / raw)
To: Valentin Ilie; +Cc: marcel, gustavo, Dean_Jenkins, linux-bluetooth
In-Reply-To: <1376322360-28824-1-git-send-email-valentin.ilie@gmail.com>
Hi Valentin,
On Mon, Aug 12, 2013, Valentin Ilie wrote:
> Remove assignment in if
>
> Signed-off-by: Valentin Ilie <valentin.ilie@gmail.com>
> ---
> drivers/bluetooth/ath3k.c | 7 +++----
> drivers/bluetooth/bfusb.c | 14 ++++++++++----
> drivers/bluetooth/bluecard_cs.c | 9 ++++++---
> drivers/bluetooth/bt3c_cs.c | 7 ++++---
> drivers/bluetooth/btuart_cs.c | 6 ++++--
> drivers/bluetooth/dtl1_cs.c | 9 ++++++---
> drivers/bluetooth/hci_bcsp.c | 26 +++++++++++++++-----------
> drivers/bluetooth/hci_h5.c | 6 ++++--
> drivers/bluetooth/hci_ldisc.c | 9 ++++++---
> 9 files changed, 58 insertions(+), 35 deletions(-)
Applied (with a minor coding style fix) to the bluetooth-next tree.
Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix removing Long Term Key
From: Johan Hedberg @ 2014-03-05 18:58 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1374780864-8529-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Thu, Jul 25, 2013, Claudio Takahasi wrote:
> This patch fixes authentication failure on LE link re-connection when
> BlueZ acts as slave (peripheral). LTK is removed from the internal list
> after its first use causing PIN or Key missing reply when re-connecting
> the link. The LE Long Term Key Request event indicates that the master
> is attempting to encrypt or re-encrypt the link.
>
> Pre-condition: BlueZ host paired and running as slave.
> How to reproduce(master):
> 1) Establish an ACL LE encrypted link
> 2) Disconnect the link
> 3) Try to re-establish the ACL LE encrypted link (fails)
>
> > HCI Event: LE Meta Event (0x3e) plen 19
> LE Connection Complete (0x01)
> Status: Success (0x00)
> Handle: 64
> Role: Slave (0x01)
> ...
> @ Device Connected: 00:02:72:DC:29:C9 (1) flags 0x0000
> > HCI Event: LE Meta Event (0x3e) plen 13
> LE Long Term Key Request (0x05)
> Handle: 64
> Random number: 875be18439d9aa37
> Encryption diversifier: 0x76ed
> < HCI Command: LE Long Term Key Request Reply (0x08|0x001a) plen 18
> Handle: 64
> Long term key: 2aa531db2fce9f00a0569c7d23d17409
> > HCI Event: Command Complete (0x0e) plen 6
> LE Long Term Key Request Reply (0x08|0x001a) ncmd 1
> Status: Success (0x00)
> Handle: 64
> > HCI Event: Encryption Change (0x08) plen 4
> Status: Success (0x00)
> Handle: 64
> Encryption: Enabled with AES-CCM (0x01)
> ...
> @ Device Disconnected: 00:02:72:DC:29:C9 (1) reason 3
> < HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1
> Advertising: Enabled (0x01)
> > HCI Event: Command Complete (0x0e) plen 4
> LE Set Advertise Enable (0x08|0x000a) ncmd 1
> Status: Success (0x00)
> > HCI Event: LE Meta Event (0x3e) plen 19
> LE Connection Complete (0x01)
> Status: Success (0x00)
> Handle: 64
> Role: Slave (0x01)
> ...
> @ Device Connected: 00:02:72:DC:29:C9 (1) flags 0x0000
> > HCI Event: LE Meta Event (0x3e) plen 13
> LE Long Term Key Request (0x05)
> Handle: 64
> Random number: 875be18439d9aa37
> Encryption diversifier: 0x76ed
> < HCI Command: LE Long Term Key Request Neg Reply (0x08|0x001b) plen 2
> Handle: 64
> > HCI Event: Command Complete (0x0e) plen 6
> LE Long Term Key Request Neg Reply (0x08|0x001b) ncmd 1
> Status: Success (0x00)
> Handle: 64
> > HCI Event: Disconnect Complete (0x05) plen 4
> Status: Success (0x00)
> Handle: 64
> Reason: Authentication Failure (0x05)
> @ Device Disconnected: 00:02:72:DC:29:C9 (1) reason 0
>
> Signed-off-by: Claudio Takahasi <claudio.takahasi@openbossa.org>
> ---
> net/bluetooth/hci_event.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
The patch has now (finally) been applied to the bluetooth-next tree.
I also added a Cc: stable flag to it since this is a fairly severe issue
at least for any kernel with the advertising mgmt setting.
Johan
^ permalink raw reply
* Re: [PATCH] Revert "Bluetooth: Use devname:vhci module alias for virtual HCI driver"
From: Josh Boyer @ 2014-03-05 18:53 UTC (permalink / raw)
To: Thomas Bächler
Cc: Marcel Holtmann, Gustavo F. Padovan, Johan Hedberg,
linux-bluetooth, Linux-Kernel@Vger. Kernel. Org
In-Reply-To: <53177187.3040009@archlinux.org>
On Wed, Mar 5, 2014 at 1:48 PM, Thomas B=E4chler <thomas@archlinux.org> wro=
te:
> Am 05.03.2014 19:36, schrieb Marcel Holtmann:
>>>>> This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
>>>>
>>>> NAK. We allocated a static minor for this.
>>>
>>> Johan mentioned that. Commit b075dd40c95d11c2c8690f6c4d6232fc,
>>> correct?
>
> I am sorry Marcel, I only looked at the Linus tree, not at bluetooth or
> bluetooth-next. This commit should indeed fix the problem. Disregard my
> patch.
>
>> Why isn't that headed into 3.14 right now, and CC'd to
>>> stable? Currently you have a somewhat broken driver in 3.13 and
>>> 3.14-rcX that seems to have a pretty clear fix.
>>
>> somewhat broken? kmod prints this as an error, but it is not a regressio=
n in user functionality. The driver works just as before. The error message=
can be ignored.
>
> It's a regression in my sanity, since numerous users blame all kernel
> bugs on this error message and I am tired of explaining the situation
> (problem + error message =3D=3D problem found *sigh*). I only sent this
> patch since I hadn't found the correct fix.
Exactly.
>> So if anybody feels strongly that the static device node assignment shou=
ld be put into -stable, then I am fine with it. However I do not see this a=
s passing requirement for a -stable fix since it is really not affecting an=
yone (minus the misleading message from kmod).
>
> Since b075dd4 will end up in the Linus tree eventually, I have no
> trouble backporting it myself.
I don't have any difficulty doing that either, but if it was in stable
every distro getting bugs about it wouldn't have to carry the fix on
their own.
josh
^ permalink raw reply
* Re: [PATCH] Revert "Bluetooth: Use devname:vhci module alias for virtual HCI driver"
From: Thomas Bächler @ 2014-03-05 18:48 UTC (permalink / raw)
To: Marcel Holtmann, Josh Boyer
Cc: Gustavo F. Padovan, Johan Hedberg, linux-bluetooth,
Linux-Kernel@Vger. Kernel. Org
In-Reply-To: <424A74F3-7646-449C-9F72-A0F4E9A28551@holtmann.org>
[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]
Am 05.03.2014 19:36, schrieb Marcel Holtmann:
>>>> This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
>>>
>>> NAK. We allocated a static minor for this.
>>
>> Johan mentioned that. Commit b075dd40c95d11c2c8690f6c4d6232fc,
>> correct?
I am sorry Marcel, I only looked at the Linus tree, not at bluetooth or
bluetooth-next. This commit should indeed fix the problem. Disregard my
patch.
> Why isn't that headed into 3.14 right now, and CC'd to
>> stable? Currently you have a somewhat broken driver in 3.13 and
>> 3.14-rcX that seems to have a pretty clear fix.
>
> somewhat broken? kmod prints this as an error, but it is not a regression in user functionality. The driver works just as before. The error message can be ignored.
It's a regression in my sanity, since numerous users blame all kernel
bugs on this error message and I am tired of explaining the situation
(problem + error message == problem found *sigh*). I only sent this
patch since I hadn't found the correct fix.
> So if anybody feels strongly that the static device node assignment should be put into -stable, then I am fine with it. However I do not see this as passing requirement for a -stable fix since it is really not affecting anyone (minus the misleading message from kmod).
Since b075dd4 will end up in the Linus tree eventually, I have no
trouble backporting it myself.
Sorry for the disturbance.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] Revert "Bluetooth: Use devname:vhci module alias for virtual HCI driver"
From: Marcel Holtmann @ 2014-03-05 18:36 UTC (permalink / raw)
To: Josh Boyer
Cc: Thomas Bächler, Gustavo F. Padovan, Johan Hedberg,
linux-bluetooth, Linux-Kernel@Vger. Kernel. Org
In-Reply-To: <CA+5PVA56oO6FS2pG+D7yJtNrTqBGZ1CtPygjid4E0f3cPPi83g@mail.gmail.com>
Hi Josh,
>>> Adding the devname:vhci alias and thus adding a static /dev/vhci device node
>>> only works when assigning a fixed major/minor number. However, the code
>>> currently uses a dynamically assigned minor number. It is therefore impossible
>>> to create a static device and to autoload the module when accessing it.
>>>
>>> Reverting this fixes the kmod error message
>>> depmod: ERROR: Module 'hci_vhci' has devname (vhci) but lacks major and minor information. Ignoring.
>>>
>>> This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
>>
>> NAK. We allocated a static minor for this.
>
> Johan mentioned that. Commit b075dd40c95d11c2c8690f6c4d6232fc,
> correct? Why isn't that headed into 3.14 right now, and CC'd to
> stable? Currently you have a somewhat broken driver in 3.13 and
> 3.14-rcX that seems to have a pretty clear fix.
somewhat broken? kmod prints this as an error, but it is not a regression in user functionality. The driver works just as before. The error message can be ignored.
So if anybody feels strongly that the static device node assignment should be put into -stable, then I am fine with it. However I do not see this as passing requirement for a -stable fix since it is really not affecting anyone (minus the misleading message from kmod).
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Revert "Bluetooth: Use devname:vhci module alias for virtual HCI driver"
From: Josh Boyer @ 2014-03-05 17:50 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Thomas Bächler, Gustavo F. Padovan, Johan Hedberg,
linux-bluetooth, Linux-Kernel@Vger. Kernel. Org
In-Reply-To: <7E804DF3-E191-427E-8E20-FE6ECDC490EA@holtmann.org>
On Wed, Mar 5, 2014 at 11:46 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Thomas,
>
>> Adding the devname:vhci alias and thus adding a static /dev/vhci device node
>> only works when assigning a fixed major/minor number. However, the code
>> currently uses a dynamically assigned minor number. It is therefore impossible
>> to create a static device and to autoload the module when accessing it.
>>
>> Reverting this fixes the kmod error message
>> depmod: ERROR: Module 'hci_vhci' has devname (vhci) but lacks major and minor information. Ignoring.
>>
>> This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
>
> NAK. We allocated a static minor for this.
Johan mentioned that. Commit b075dd40c95d11c2c8690f6c4d6232fc,
correct? Why isn't that headed into 3.14 right now, and CC'd to
stable? Currently you have a somewhat broken driver in 3.13 and
3.14-rcX that seems to have a pretty clear fix.
josh
^ permalink raw reply
* Re: [PATCH BlueZ] autopair: Remove time(NULL) fallback when seeding rand()
From: Johan Hedberg @ 2014-03-05 16:55 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <1381179924-19529-1-git-send-email-anderson.lizardo@openbossa.org>
Hi Lizardo,
On Mon, Oct 07, 2013, Anderson Lizardo wrote:
> If /dev/urandom cannot be opened or read, just fail the plugin
> initialization, as it is very unlikely that a fully working Linux system
> does not have a working /dev/urandom. This also simplifies the code
> logic.
> ---
> plugins/autopair.c | 27 ++++++++++++++++++---------
> 1 file changed, 18 insertions(+), 9 deletions(-)
Applied. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Revert "Bluetooth: Use devname:vhci module alias for virtual HCI driver"
From: Marcel Holtmann @ 2014-03-05 16:46 UTC (permalink / raw)
To: Thomas Bächler
Cc: Gustavo F. Padovan, Johan Hedberg, linux-bluetooth, linux-kernel
In-Reply-To: <1394020752-6186-1-git-send-email-thomas@archlinux.org>
Hi Thomas,
> Adding the devname:vhci alias and thus adding a static /dev/vhci device node
> only works when assigning a fixed major/minor number. However, the code
> currently uses a dynamically assigned minor number. It is therefore impossible
> to create a static device and to autoload the module when accessing it.
>
> Reverting this fixes the kmod error message
> depmod: ERROR: Module 'hci_vhci' has devname (vhci) but lacks major and minor information. Ignoring.
>
> This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
NAK. We allocated a static minor for this.
Regards
Marcel
^ 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