* [PATCH v3 1/2] Bluetooth: Introduce a new HCI_RFKILLED flag
From: johan.hedberg @ 2013-09-13 5:58 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1379051898-2630-1-git-send-email-johan.hedberg@gmail.com>
From: Johan Hedberg <johan.hedberg@intel.com>
This makes it more convenient to check for rfkill (no need to check for
dev->rfkill before calling rfkill_blocked()) and also avoids potential
races if the RFKILL state needs to be checked from within the rfkill
callback.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Cc: stable@vger.kernel.org
Acked-by: Marcel Holtmann <marcel@holtmann.org>
---
v3: no changes
v2: Explicitly intialize HCI_RFKILLED flag after calling rfkill_register
include/net/bluetooth/hci.h | 1 +
net/bluetooth/hci_core.c | 15 ++++++++++-----
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 30c88b5..ba008d5 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -104,6 +104,7 @@ enum {
enum {
HCI_SETUP,
HCI_AUTO_OFF,
+ HCI_RFKILLED,
HCI_MGMT,
HCI_PAIRABLE,
HCI_SERVICE_CACHE,
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 4dbb6cb..d0d6cf8 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1148,7 +1148,7 @@ int hci_dev_open(__u16 dev)
goto done;
}
- if (hdev->rfkill && rfkill_blocked(hdev->rfkill)) {
+ if (test_bit(HCI_RFKILLED, &hdev->dev_flags)) {
ret = -ERFKILL;
goto done;
}
@@ -1597,10 +1597,12 @@ static int hci_rfkill_set_block(void *data, bool blocked)
if (test_bit(HCI_USER_CHANNEL, &hdev->dev_flags))
return -EBUSY;
- if (!blocked)
- return 0;
-
- hci_dev_do_close(hdev);
+ if (blocked) {
+ set_bit(HCI_RFKILLED, &hdev->dev_flags);
+ hci_dev_do_close(hdev);
+ } else {
+ clear_bit(HCI_RFKILLED, &hdev->dev_flags);
+ }
return 0;
}
@@ -2244,6 +2246,9 @@ int hci_register_dev(struct hci_dev *hdev)
}
}
+ if (hdev->rfkill && rfkill_blocked(hdev->rfkill))
+ set_bit(HCI_RFKILLED, &hdev->dev_flags);
+
set_bit(HCI_SETUP, &hdev->dev_flags);
if (hdev->dev_type != HCI_AMP)
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH v3 0/2] Bluetooth: Fix race condition with rfkill handling
From: johan.hedberg @ 2013-09-13 5:58 UTC (permalink / raw)
To: linux-bluetooth
Hi,
Once again updated based on feedback for patch 2/2 from Marcel.
Johan
----------------------------------------------------------------
Johan Hedberg (2):
Bluetooth: Introduce a new HCI_RFKILLED flag
Bluetooth: Fix rfkill functionality during the HCI setup stage
include/net/bluetooth/hci.h | 1 +
net/bluetooth/hci_core.c | 26 ++++++++++++++++++++------
2 files changed, 21 insertions(+), 6 deletions(-)
^ permalink raw reply
* Re: Linux Wireless Mini-Summit in New Orleans -- 19-20 September
From: Daniel Wagner @ 2013-09-12 19:31 UTC (permalink / raw)
To: John W. Linville
Cc: Dan Williams, linux-wireless, johannes, marcel, Samuel Ortiz,
Gustavo Padovan, linux-bluetooth, linux-nfc
In-Reply-To: <20130912184835.GC14253@tuxdriver.com>
On 09/12/2013 08:48 PM, John W. Linville wrote:
>> On 09/09/2013 09:23 PM, John W. Linville wrote:
>>> Dan Williams, Daniel Wagner, etc -- anyone got some user stories
>>> to share?
>>
>> Not much news from the user front, though I could give a short
>> update what's happening on ConnMan if you like.
>
> I think that Patrik Flykt is going to handle that...
Great.
> Surely there is some infotainment angle to be discussed?? :-)
Sure, if that is of any interest. There is also the automotive
uconf during the LPC which wireless (BT and Wifi) is shortly
discussed. Repeating/summarizing wouldn't be a problem, I guess.
cheers,
daniel
^ permalink raw reply
* Re: Linux Wireless Mini-Summit in New Orleans -- 19-20 September
From: Dan Williams @ 2013-09-12 19:26 UTC (permalink / raw)
To: John W. Linville
Cc: Daniel Wagner, linux-wireless, johannes, marcel, Samuel Ortiz,
Gustavo Padovan, linux-bluetooth, linux-nfc
In-Reply-To: <20130912184835.GC14253@tuxdriver.com>
On Thu, 2013-09-12 at 14:48 -0400, John W. Linville wrote:
> On Thu, Sep 12, 2013 at 08:38:26PM +0200, Daniel Wagner wrote:
> > Hi John,
> >
> > On 09/09/2013 09:23 PM, John W. Linville wrote:
>
> > >Dan Williams, Daniel Wagner, etc -- anyone got some user stories
> > >to share?
> >
> > Not much news from the user front, though I could give a short
> > update what's happening on ConnMan if you like.
>
> I think that Patrik Flykt is going to handle that...
>
> Surely there is some infotainment angle to be discussed?? :-)
I can do a short update on NetworkManager too, but there's no
infotainment angle to it at all :)
Dan
^ permalink raw reply
* Re: Linux Wireless Mini-Summit in New Orleans -- 19-20 September
From: John W. Linville @ 2013-09-12 18:48 UTC (permalink / raw)
To: Daniel Wagner
Cc: Dan Williams, linux-wireless, johannes, marcel, Samuel Ortiz,
Gustavo Padovan, linux-bluetooth, linux-nfc
In-Reply-To: <52320A22.1040609@monom.org>
On Thu, Sep 12, 2013 at 08:38:26PM +0200, Daniel Wagner wrote:
> Hi John,
>
> On 09/09/2013 09:23 PM, John W. Linville wrote:
> >Dan Williams, Daniel Wagner, etc -- anyone got some user stories
> >to share?
>
> Not much news from the user front, though I could give a short
> update what's happening on ConnMan if you like.
I think that Patrik Flykt is going to handle that...
Surely there is some infotainment angle to be discussed?? :-)
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: Linux Wireless Mini-Summit in New Orleans -- 19-20 September
From: Daniel Wagner @ 2013-09-12 18:38 UTC (permalink / raw)
To: John W. Linville
Cc: Dan Williams, linux-wireless, johannes, marcel, Samuel Ortiz,
Gustavo Padovan, linux-bluetooth, linux-nfc
In-Reply-To: <20130909192346.GC1955@tuxdriver.com>
Hi John,
On 09/09/2013 09:23 PM, John W. Linville wrote:
> On Thu, Sep 05, 2013 at 11:04:52AM -0500, Dan Williams wrote:
>> On Thu, 2013-09-05 at 09:39 -0400, John W. Linville wrote:
>>> On Thu, Aug 08, 2013 at 03:04:29PM -0400, John W. Linville wrote:
>>>> Sorry, forgot to copy linux-bluetooth and linux-nfc...
>>>>
>>>> On Thu, Aug 08, 2013 at 02:54:11PM -0400, John W. Linville wrote:
>>>>> Greetings!
>>>>>
>>>>> This is a reminder that we will have a Linux Wireless Mini-Summit in
>>>>> New Orleans this year on 19-20 September. This will immediately follow
>>>>> LinuxCon and will run concurrently with Linux Plumber's Conference.
>>>>> This event includes Linux developers for wireless LAN (802.11),
>>>>> Bluetooth, and NFC technologies. Both kernel and userland developers
>>>>> are welcomed and heartily encouraged to attend!
>>>>>
>>>>> http://wireless.kernel.org/en/developers/Summits/New-Orleans-2013
>>>>>
>>>>> The link above is a Wiki. We are using it to collect discussion
>>>>> topics and to negotiate agenda/scheduling options for the event.
>>>>> Please go there to record your intent to attend the event and to
>>>>> propopse topics for discussion.
>>>>>
>>>>> Please be aware that in order to attend the event above one must
>>>>> register for either LinuxCon or for Linux Plumbers Conference.
>>>>> Act now, before those events fill-up and close their registrations!
>>>>>
>>>>> We are allotted one "large" room (up to ~80 people "theater style"), and
>>>>> two "small" rooms (up to ~25 people) for this event. Based on history
>>>>> and the numbers of contributors, the larger room will primarily be
>>>>> for the 802.11 discussions and any "plenary" topics while the smaller
>>>>> rooms will be for Bluetooth, NFC, and any "breakout" topics.
>>>>>
>>>>> So...thoughts? Topics to discuss?
>>>
>>> Ping? We're now just 2 weeks away!
>>>
>>> Is our topic list complete? It looks a bit light...
>>>
>>> Anyone have any input on scheduling the topics? Are there any
>>> overlapping LPC sessions that it would make sense to work around?
>>
>> I'm attending though I haven't put my name on the wiki yet.
>>
>> Random thoughts; it doesn't look like any of these are covered in the
>> regular LinuxConf or LPC sessions.
>>
>> 1) State of the Union (maybe by multiple people in the same session per
>> their expertise), since perhaps not everyone doing eg 802.11 stuff knows
>> what's happening in BT or NFC land, or not everyone working on a
>> specific driver may know what new stuff their driver might need to be
>> fixed up for. Maybe 5 minutes or less for things like:
>>
>> * what's under the most active development right now?
>> * upcoming new driver, hardware, and new capabilities
>> * new 802.11 standards
>> * and what's coming up in the next year from the standards orgs
>> * what people will start working on soon
>> * what will 3.13 or 3.14 look like from a wireless perspective?
>> * 11s mesh status?
>> * anything interesting in wpa_supplicant land?
>> * anything new/interesting on the Android front?
>>
>> 2) Bluetooth - update about what's new and what's coming up in Bluez
>> land, and interaction with kernel 802.11 if any,
>>
>> 3) NFC - update about what's new and what's coming up in NFC land, where
>> it's getting used, what the stack looks like
>>
>> 4) What are users having the most problems with and how these problems
>> be fixed better/more quickly? Are they driver bugs? Are they stack
>> bugs? Supplicant bugs? NM/GUI/etc bugs? Is there anything in our
>> development processes that's not working as smoothly as it could be?
>
> Thanks, Dan -- those all look like decent discussion points.
> I've added most of the points above to the topic list:
>
> http://wireless.kernel.org/en/developers/Summits/New-Orleans-2013
>
> Now, we need a few volunteers...
>
> Gustavo, can you do a session on Bluetooth developments?
>
> Samuel, can you cover NFC?
>
> Jouni, would you mind doing your usual update on the standards
> activities? Also, is there anything new/interesting to report on
> wpa_suppliant and/or hostapd?
>
> Johannes, would you cover your vision for mac80211 for the next year
> or so? Anything in progress now that needs to be discussed?
>
> Who should cover any Android topics?
>
> Arend, Kalle, Johannes, Luca, etc -- anyone want to talk about driver
> developments and/or issues between drivers and mac80211 or other
> parts of the stack?
>
> Seth, Stanislaw, etc -- anyone want to cover issues dealing with
> supporting wireless in distributions?
>
> Dan Williams, Daniel Wagner, etc -- anyone got some user stories
> to share?
Not much news from the user front, though I could give a short
update what's happening on ConnMan if you like.
cheers,
daniel
^ permalink raw reply
* RE: [Bluetooth Low Energy] Pairing and writing characteristic property issue
From: Nedim Hadzic @ 2013-09-12 16:55 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
In-Reply-To: <285F7E29A611CC4197B552ED66CC20B8CE7EBA@XMB102ADS.rim.net>
Hi again,
I am not sure if I sent mail to wrong list, but if I did can someone inform me. I am still having a problems with this issues so I would appreciate some help.
Kind regards,
Nedim
________________________________________
From: linux-bluetooth-owner@vger.kernel.org [linux-bluetooth-owner@vger.kernel.org] on behalf of Nedim Hadzic [nhadzic@blackberry.com]
Sent: 11 September 2013 07:34
To: linux-bluetooth@vger.kernel.org
Subject: [Bluetooth Low Energy] Pairing and writing characteristic property issue
Hello everyone,
Recently I started working with Bluetooth Low Energy devices on Linux (developing some applications, testing devices etc). I am using two Bluetooth Low Energy devices SensorTag from Texas Instruments and HearRateMonitor BlueHR.
Bluez version: 4.101-0ubuntu8b1
SensorTag: I can connect to the device, read and write characteristic values using gatttool and I can pair with the device using a simple-agent tool for this. After I pair with the device, I want to change value of the characteristic using org.bluez.Characteristic interface and SetProperty method, but it does not change; nor PropertyChanged signal is emitted nor I get any error. I checked hcidump:
2013-09-11 12:07:15.827211 < ACL data: handle 75 flags 0x00 dlen 8
ATT: Write cmd (0x52)
handle 0x0029 value 0x01
In case of changing the characteristic value with gatttool hcidump is following:
2013-09-11 12:20:07.239012 < ACL data: handle 75 flags 0x00 dlen 8
ATT: Write req (0x12)
handle 0x0029 value 0x01
Difference is in part of write cmd and req. Only difference between these two approaches is that with gatttool, you first connect to LE device (LE Create Connection in hcidump), and in hcdump when accessing through interface and using method SetProperty there is no interface or method for connecting. Any guesses what can be done?
HearRateMonitor: I can connect to the device, read characteristic values using gatttool ( with adding "-t random" part to the command), but I can not pair with the device using simple-agent: Error: Creating device failed: org.bluez.Error.AuthenticationFailed: Authentication Failed.
Hcidump is the following:
2013-09-11 11:58:41.747749 < HCI Command: LE Create Connection (0x08|0x000d) plen 25
bdaddr D5:EA:8B:A9:EC:70 type 1
2013-09-11 11:58:41.751989 > HCI Event: Command Status (0x0f) plen 4
LE Create Connection (0x08|0x000d) status 0x00 ncmd 1
2013-09-11 11:58:44.311996 > HCI Event: LE Meta Event (0x3e) plen 19
LE Connection Complete
status 0x00 handle 75, role master
bdaddr D5:EA:8B:A9:EC:70 (Random)
2013-09-11 11:58:44.312173 < ACL data: handle 75 flags 0x00 dlen 11
SMP: Pairing Request (0x01)
capability 0x04 oob 0x00 auth req 0x01
max key size 0x10 init key dist 0x00 resp key dist 0x01
Capability: KeyboardDisplay (OOB data not present)
Authentication: Bonding (No MITM Protection)
Initiator Key Distribution:
Responder Key Distribution: LTK
2013-09-11 11:58:44.348985 > HCI Event: Number of Completed Packets (0x13) plen 5
handle 75 packets 1
2013-09-11 11:58:44.418969 > ACL data: handle 75 flags 0x02 dlen 6
SMP: Pairing Failed (0x05)
reason 0x05
Reason Pairing Not Supported
2013-09-11 11:58:44.560004 > HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 75 reason 0x13
Reason: Remote User Terminated Connection
This device is using random device address, but I do not know how to pair with it in that case. I try to pair with it using a smartphone with support and it is working. Any help, or input on this?
Looking forward to reply;
Kind regards,
Nedim Hadzic
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
--
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
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
^ permalink raw reply
* Re: [PATCH v2 2/2] Bluetooth: Fix rfkill functionality during the HCI setup stage
From: Marcel Holtmann @ 2013-09-12 16:18 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth
In-Reply-To: <1378978153-5683-3-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> We need to let the setup stage complete cleanly even when the HCI device
> is rfkilled. Otherwise the HCI device will stay in an undefined state
> and never get notified to user space through mgmt (even when it gets
> unblocked through rfkill).
>
> This patch makes sure that hci_dev_open() can be called in the HCI_SETUP
> stage, that blocking the device doesn't abort the setup stage, and that
> the device gets proper powered down as soon as the setup stage completes
> in case it was blocked meanwhile.
>
> The bug that this patch fixed can be very easily reproduced using e.g.
> the rfkill command line too. By running "rfkill block all" before
> inserting a Bluetooth dongle the resulting HCI device goes into a state
> where it is never announced over mgmt, not even when "rfkill unblock all"
> is run.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> Cc: stable@vger.kernel.org
> ---
> net/bluetooth/hci_core.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index d0d6cf8..433820a 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -1148,7 +1148,11 @@ int hci_dev_open(__u16 dev)
> goto done;
> }
>
> - if (test_bit(HCI_RFKILLED, &hdev->dev_flags)) {
> + /* Check for rfkill but allow the HCI setup stage to proceed
> + * (which in itself doesn't cause any RF activity).
> + */
> + if (test_bit(HCI_RFKILLED, &hdev->dev_flags) &&
> + !test_bit(HCI_SETUP, &hdev->dev_flags)) {
> ret = -ERFKILL;
> goto done;
> }
> @@ -1599,7 +1603,8 @@ static int hci_rfkill_set_block(void *data, bool blocked)
>
> if (blocked) {
> set_bit(HCI_RFKILLED, &hdev->dev_flags);
> - hci_dev_do_close(hdev);
> + if (!test_bit(HCI_SETUP, &hdev->dev_flags))
> + hci_dev_do_close(hdev);
> } else {
> clear_bit(HCI_RFKILLED, &hdev->dev_flags);
> }
> @@ -1624,6 +1629,11 @@ static void hci_power_on(struct work_struct *work)
> return;
> }
>
> + if (test_bit(HCI_RFKILLED, &hdev->dev_flags)) {
> + clear_bit(HCI_AUTO_OFF, &hdev->dev_flags);
> + hci_dev_do_close(hdev);
> + }
> +
this might be better extend with
} else if (test_bit(HCI_AUTO_OFF, ...)
> if (test_bit(HCI_AUTO_OFF, &hdev->dev_flags))
> queue_delayed_work(hdev->req_workqueue, &hdev->power_off,
> HCI_AUTO_OFF_TIMEOUT);
Makes the code a little bit more readable for the reason that I want to add a return from the function to the HCI_RFKILLED check every time I read it, but that would be actually wrong.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v2 1/2] Bluetooth: Introduce a new HCI_RFKILLED flag
From: Marcel Holtmann @ 2013-09-12 16:13 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth
In-Reply-To: <1378978153-5683-2-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> This makes it more convenient to check for rfkill (no need to check for
> dev->rfkill before calling rfkill_blocked()) and also avoids potential
> races if the RFKILL state needs to be checked from within the rfkill
> callback.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> Cc: stable@vger.kernel.org
> ---
> v2: Explicitly intialize HCI_RFKILLED flag after calling rfkill_register
>
> include/net/bluetooth/hci.h | 1 +
> net/bluetooth/hci_core.c | 15 ++++++++++-----
> 2 files changed, 11 insertions(+), 5 deletions(-)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH BlueZ 1/8] unit: Add gdbus/client_proxy_removed
From: Luiz Augusto von Dentz @ 2013-09-12 11:01 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
In-Reply-To: <1378738179-21047-1-git-send-email-luiz.dentz@gmail.com>
Hi,
On Mon, Sep 9, 2013 at 5:49 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>
> This tests if watches created using g_dbus_proxy_set_removed_watch works
> when the interface is removed.
> ---
> unit/test-gdbus-client.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
>
> diff --git a/unit/test-gdbus-client.c b/unit/test-gdbus-client.c
> index 488d4ec..30b0ce3 100644
> --- a/unit/test-gdbus-client.c
> +++ b/unit/test-gdbus-client.c
> @@ -848,6 +848,61 @@ static void client_check_order(void)
> destroy_context(context);
> }
>
> +static void proxy_removed(GDBusProxy *proxy, void *user_data)
> +{
> + struct context *context = user_data;
> +
> + if (g_test_verbose())
> + g_print("proxy removed\n");
> +
> + g_main_loop_quit(context->main_loop);
> +}
> +
> +static void proxy_set_removed(GDBusProxy *proxy, void *user_data)
> +{
> + struct context *context = user_data;
> +
> + if (g_test_verbose())
> + g_print("proxy %s found\n",
> + g_dbus_proxy_get_interface(proxy));
> +
> + g_assert(g_dbus_proxy_set_removed_watch(proxy, proxy_removed, context));
> +
> + context->timeout_source = g_timeout_add_seconds(2, timeout_test,
> + context);
> +
> + g_dbus_unregister_interface(context->dbus_conn, SERVICE_PATH,
> + SERVICE_NAME);
> +}
> +
> +static void client_proxy_removed(void)
> +{
> + struct context *context = create_context();
> + static const GDBusPropertyTable string_properties[] = {
> + { "String", "s", get_string, set_string, string_exists },
> + { },
> + };
> +
> + if (context == NULL)
> + return;
> +
> + g_dbus_register_interface(context->dbus_conn,
> + SERVICE_PATH, SERVICE_NAME,
> + methods, signals, string_properties,
> + context, NULL);
> +
> + context->dbus_client = g_dbus_client_new(context->dbus_conn,
> + SERVICE_NAME, SERVICE_PATH);
> +
> + g_dbus_client_set_proxy_handlers(context->dbus_client,
> + proxy_set_removed, NULL, NULL,
> + context);
> +
> + g_main_loop_run(context->main_loop);
> +
> + destroy_context(context);
> +}
> +
> int main(int argc, char *argv[])
> {
> g_test_init(&argc, &argv, NULL);
> @@ -880,5 +935,7 @@ int main(int argc, char *argv[])
>
> g_test_add_func("/gdbus/client_check_order", client_check_order);
>
> + g_test_add_func("/gdbus/client_proxy_removed", client_proxy_removed);
> +
> return g_test_run();
> }
> --
> 1.8.3.1
This patch-set has been pushed upstream.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: Device discovery/pairing issue w/ BlueZ on Debian
From: Anderson Lizardo @ 2013-09-12 10:31 UTC (permalink / raw)
To: Clemens Vasters; +Cc: BlueZ development
In-Reply-To: <CAGMh8s_RNftv8X32ayf4L-ZjBqSGv3HYxPAR28GthVPWUht-xw@mail.gmail.com>
Hi Clemens,
On Tue, Sep 10, 2013 at 2:47 PM, Clemens Vasters <clemensv@gmail.com> wrote:
> I’ve got a cheap Bluetooth car diagnostics dongle (OBD-2, ELM327) that
> gets discovered by and pairs with Windows 8, Windows Phone 8, OSX
> Mountain Lion, iOS 6, and Android Jelly Bean.
>
> I can’t get it to be either discovered or paired with BlueZ on Debian
> Wheezy on my Notebook (bare metal, ThinkPad W510) or Raspbian Wheezy
> on the Raspberry Pi. On the latter I even went so far to pull the
> source for BlueZ 5.8 and install it from source. No dice.
Your description of the problem is a little vague. Which tools did you
use on BlueZ 5.8 to attempt to discover/pair with the device? Which
errors did you see (if any)?
Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* [PATCH v2 2/2] Bluetooth: Fix rfkill functionality during the HCI setup stage
From: johan.hedberg @ 2013-09-12 9:29 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1378978153-5683-1-git-send-email-johan.hedberg@gmail.com>
From: Johan Hedberg <johan.hedberg@intel.com>
We need to let the setup stage complete cleanly even when the HCI device
is rfkilled. Otherwise the HCI device will stay in an undefined state
and never get notified to user space through mgmt (even when it gets
unblocked through rfkill).
This patch makes sure that hci_dev_open() can be called in the HCI_SETUP
stage, that blocking the device doesn't abort the setup stage, and that
the device gets proper powered down as soon as the setup stage completes
in case it was blocked meanwhile.
The bug that this patch fixed can be very easily reproduced using e.g.
the rfkill command line too. By running "rfkill block all" before
inserting a Bluetooth dongle the resulting HCI device goes into a state
where it is never announced over mgmt, not even when "rfkill unblock all"
is run.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Cc: stable@vger.kernel.org
---
net/bluetooth/hci_core.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index d0d6cf8..433820a 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1148,7 +1148,11 @@ int hci_dev_open(__u16 dev)
goto done;
}
- if (test_bit(HCI_RFKILLED, &hdev->dev_flags)) {
+ /* Check for rfkill but allow the HCI setup stage to proceed
+ * (which in itself doesn't cause any RF activity).
+ */
+ if (test_bit(HCI_RFKILLED, &hdev->dev_flags) &&
+ !test_bit(HCI_SETUP, &hdev->dev_flags)) {
ret = -ERFKILL;
goto done;
}
@@ -1599,7 +1603,8 @@ static int hci_rfkill_set_block(void *data, bool blocked)
if (blocked) {
set_bit(HCI_RFKILLED, &hdev->dev_flags);
- hci_dev_do_close(hdev);
+ if (!test_bit(HCI_SETUP, &hdev->dev_flags))
+ hci_dev_do_close(hdev);
} else {
clear_bit(HCI_RFKILLED, &hdev->dev_flags);
}
@@ -1624,6 +1629,11 @@ static void hci_power_on(struct work_struct *work)
return;
}
+ if (test_bit(HCI_RFKILLED, &hdev->dev_flags)) {
+ clear_bit(HCI_AUTO_OFF, &hdev->dev_flags);
+ hci_dev_do_close(hdev);
+ }
+
if (test_bit(HCI_AUTO_OFF, &hdev->dev_flags))
queue_delayed_work(hdev->req_workqueue, &hdev->power_off,
HCI_AUTO_OFF_TIMEOUT);
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH v2 1/2] Bluetooth: Introduce a new HCI_RFKILLED flag
From: johan.hedberg @ 2013-09-12 9:29 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1378978153-5683-1-git-send-email-johan.hedberg@gmail.com>
From: Johan Hedberg <johan.hedberg@intel.com>
This makes it more convenient to check for rfkill (no need to check for
dev->rfkill before calling rfkill_blocked()) and also avoids potential
races if the RFKILL state needs to be checked from within the rfkill
callback.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Cc: stable@vger.kernel.org
---
v2: Explicitly intialize HCI_RFKILLED flag after calling rfkill_register
include/net/bluetooth/hci.h | 1 +
net/bluetooth/hci_core.c | 15 ++++++++++-----
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 30c88b5..ba008d5 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -104,6 +104,7 @@ enum {
enum {
HCI_SETUP,
HCI_AUTO_OFF,
+ HCI_RFKILLED,
HCI_MGMT,
HCI_PAIRABLE,
HCI_SERVICE_CACHE,
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 4dbb6cb..d0d6cf8 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1148,7 +1148,7 @@ int hci_dev_open(__u16 dev)
goto done;
}
- if (hdev->rfkill && rfkill_blocked(hdev->rfkill)) {
+ if (test_bit(HCI_RFKILLED, &hdev->dev_flags)) {
ret = -ERFKILL;
goto done;
}
@@ -1597,10 +1597,12 @@ static int hci_rfkill_set_block(void *data, bool blocked)
if (test_bit(HCI_USER_CHANNEL, &hdev->dev_flags))
return -EBUSY;
- if (!blocked)
- return 0;
-
- hci_dev_do_close(hdev);
+ if (blocked) {
+ set_bit(HCI_RFKILLED, &hdev->dev_flags);
+ hci_dev_do_close(hdev);
+ } else {
+ clear_bit(HCI_RFKILLED, &hdev->dev_flags);
+ }
return 0;
}
@@ -2244,6 +2246,9 @@ int hci_register_dev(struct hci_dev *hdev)
}
}
+ if (hdev->rfkill && rfkill_blocked(hdev->rfkill))
+ set_bit(HCI_RFKILLED, &hdev->dev_flags);
+
set_bit(HCI_SETUP, &hdev->dev_flags);
if (hdev->dev_type != HCI_AMP)
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH v2 0/2] Bluetooth: Fix race condition with rfkill handling
From: johan.hedberg @ 2013-09-12 9:29 UTC (permalink / raw)
To: linux-bluetooth
Hi,
Here's an updated patch set for the rfkill issue. The only change is the
added explicit initialization of the HCI_RFKILLED flag by checking the
return value of rfkill_blocked() once rfkill_register() has succeeded.
Johan
----------------------------------------------------------------
Johan Hedberg (2):
Bluetooth: Introduce a new HCI_RFKILLED flag
Bluetooth: Fix rfkill functionality during the HCI setup stage
include/net/bluetooth/hci.h | 1 +
net/bluetooth/hci_core.c | 25 ++++++++++++++++++++-----
2 files changed, 21 insertions(+), 5 deletions(-)
^ permalink raw reply
* Re: Device discovery/pairing issue w/ BlueZ on Debian
From: Clemens Vasters @ 2013-09-12 9:20 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <CAGMh8s_RNftv8X32ayf4L-ZjBqSGv3HYxPAR28GthVPWUht-xw@mail.gmail.com>
On Tue, Sep 10, 2013 at 8:47 PM, Clemens Vasters <clemensv@gmail.com> wrote:
> I’ve got a cheap Bluetooth car diagnostics dongle (OBD-2, ELM327) that
> gets discovered by and pairs with Windows 8, Windows Phone 8, OSX
> Mountain Lion, iOS 6, and Android Jelly Bean.
>
> I can’t get it to be either discovered or paired with BlueZ on Debian
> Wheezy on my Notebook (bare metal, ThinkPad W510) or Raspbian Wheezy
> on the Raspberry Pi. On the latter I even went so far to pull the
> source for BlueZ 5.8 and install it from source. No dice.
>
> I’m pretty puzzled about this. How would I go about debugging or,
> rather, what data do I need to gather (and how) for someone to help me
> with this.
If this isn't the right list for this sort of question, could someone
point me to a more appropriate one?
^ permalink raw reply
* Re: [PATCH] monitor: Add missing include
From: Johan Hedberg @ 2013-09-12 6:55 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <1378908208-17063-1-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
On Wed, Sep 11, 2013, Szymon Janc wrote:
> Bionic library requires explicit include for data types used in ioctl
> call. This fix following build error with bionic:
>
> target C: btmon <= external/bluetooth/bluez/monitor/display.c
> external/bluetooth/bluez/monitor/display.c: In function 'num_columns':
> external/bluetooth/bluez/monitor/display.c:59:18: error: storage size
> of 'ws' isn't known
> ---
> monitor/display.c | 1 +
> 1 file changed, 1 insertion(+)
Applied. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 2/2] Bluetooth: Fix rfkill functionality during the HCI setup stage
From: Johan Hedberg @ 2013-09-12 6:28 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <32FA1E78-97FE-42C1-9FA6-3DB0EED32BD8@holtmann.org>
Hi Marcel,
On Wed, Sep 11, 2013, Marcel Holtmann wrote:
> > We need to let the setup stage complete cleanly even when the HCI device
> > is rfkilled. Otherwise the HCI device will stay in an undefined state
> > and never get notified to user space through mgmt (even when it gets
> > unblocked through rfkill).
> >
> > This patch makes sure that hci_dev_open() can be called in the HCI_SETUP
> > stage, that blocking the device doesn't abort the setup stage, and that
> > the device gets proper powered down as soon as the setup stage completes
> > in case it was blocked meanwhile.
> >
> > The bug that this patch fixed can be very easily reproduced using e.g.
> > the rfkill command line too. By running "rfkill block all" before
> > inserting a Bluetooth dongle the resulting HCI device goes into a state
> > where it is never announced over mgmt, not even when "rfkill unblock all"
> > is run.
> >
> > Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> > Cc: stable@vger.kernel.org
> > ---
> > net/bluetooth/hci_core.c | 14 ++++++++++++--
> > 1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> > index 70efa16..3ff99f2 100644
> > --- a/net/bluetooth/hci_core.c
> > +++ b/net/bluetooth/hci_core.c
> > @@ -1148,7 +1148,11 @@ int hci_dev_open(__u16 dev)
> > goto done;
> > }
> >
> > - if (test_bit(HCI_RFKILLED, &hdev->dev_flags)) {
> > + /* Check for rfkill but allow the HCI setup stage to proceed
> > + * (which in itself doesn't cause any RF activity).
> > + */
> > + if (test_bit(HCI_RFKILLED, &hdev->dev_flags) &&
> > + !test_bit(HCI_SETUP, &hdev->dev_flags)) {
> > ret = -ERFKILL;
> > goto done;
> > }
>
> so explain to me how this actually works. If we add a HCI controller
> when RFKILL is currently blocking all radios. Which part is setting
> HCI_RFKILLED initially? Or does the RFKILL subsystem is calling into
> set_blocked by itself during registration?
Yes, the rfkill subsystem almost immediately calls our
hci_rfkill_set_block() function after we've registered the hdev but
before the hci_power_on() work callback that eventually calls
hci_dev_open() gets called. That's why I didn't think to initialize
HCI_RFKILLED after calling rfkill_register() (instead it defaults to
being unset). I will add this extra initialization in v2.
Considering that the situation is really simple to reproduce I'd
recommend just trying yourself and you'll see how the function calls go.
Johan
^ permalink raw reply
* Re: [PATCH 2/2] Bluetooth: Fix rfkill functionality during the HCI setup stage
From: Marcel Holtmann @ 2013-09-11 20:33 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth
In-Reply-To: <1378899239-5138-3-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> We need to let the setup stage complete cleanly even when the HCI device
> is rfkilled. Otherwise the HCI device will stay in an undefined state
> and never get notified to user space through mgmt (even when it gets
> unblocked through rfkill).
>
> This patch makes sure that hci_dev_open() can be called in the HCI_SETUP
> stage, that blocking the device doesn't abort the setup stage, and that
> the device gets proper powered down as soon as the setup stage completes
> in case it was blocked meanwhile.
>
> The bug that this patch fixed can be very easily reproduced using e.g.
> the rfkill command line too. By running "rfkill block all" before
> inserting a Bluetooth dongle the resulting HCI device goes into a state
> where it is never announced over mgmt, not even when "rfkill unblock all"
> is run.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> Cc: stable@vger.kernel.org
> ---
> net/bluetooth/hci_core.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index 70efa16..3ff99f2 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -1148,7 +1148,11 @@ int hci_dev_open(__u16 dev)
> goto done;
> }
>
> - if (test_bit(HCI_RFKILLED, &hdev->dev_flags)) {
> + /* Check for rfkill but allow the HCI setup stage to proceed
> + * (which in itself doesn't cause any RF activity).
> + */
> + if (test_bit(HCI_RFKILLED, &hdev->dev_flags) &&
> + !test_bit(HCI_SETUP, &hdev->dev_flags)) {
> ret = -ERFKILL;
> goto done;
> }
so explain to me how this actually works. If we add a HCI controller when RFKILL is currently blocking all radios. Which part is setting HCI_RFKILLED initially? Or does the RFKILL subsystem is calling into set_blocked by itself during registration?
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 1/2] Bluetooth: Introduce a new HCI_RFKILLED flag
From: Marcel Holtmann @ 2013-09-11 20:30 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth
In-Reply-To: <1378899239-5138-2-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> This makes it more convenient to check for rfkill (no need to check for
> dev->rfkill before calling rfkill_blocked()) and also avoids potential
> races if the RFKILL state needs to be checked from within the rfkill
> callback.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> Cc: stable@vger.kernel.org
> ---
> include/net/bluetooth/hci.h | 1 +
> net/bluetooth/hci_core.c | 12 +++++++-----
> 2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index 30c88b5..ba008d5 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -104,6 +104,7 @@ enum {
> enum {
> HCI_SETUP,
> HCI_AUTO_OFF,
> + HCI_RFKILLED,
> HCI_MGMT,
> HCI_PAIRABLE,
> HCI_SERVICE_CACHE,
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index 4dbb6cb..70efa16 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -1148,7 +1148,7 @@ int hci_dev_open(__u16 dev)
> goto done;
> }
>
> - if (hdev->rfkill && rfkill_blocked(hdev->rfkill)) {
> + if (test_bit(HCI_RFKILLED, &hdev->dev_flags)) {
> ret = -ERFKILL;
> goto done;
> }
the problem here is that we never set the initial value of HCI_RFKILLED properly. To make the patch fully equivalent, we should do that.
> @@ -1597,10 +1597,12 @@ static int hci_rfkill_set_block(void *data, bool blocked)
> if (test_bit(HCI_USER_CHANNEL, &hdev->dev_flags))
> return -EBUSY;
>
> - if (!blocked)
> - return 0;
> -
> - hci_dev_do_close(hdev);
> + if (blocked) {
> + set_bit(HCI_RFKILLED, &hdev->dev_flags);
> + hci_dev_do_close(hdev);
> + } else {
> + clear_bit(HCI_RFKILLED, &hdev->dev_flags);
> + }
>
> return 0;
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 1/3] doc: Label Profile1.Release() method as no reply
From: Johan Hedberg @ 2013-09-11 18:49 UTC (permalink / raw)
To: Denis Kenzior; +Cc: linux-bluetooth
In-Reply-To: <1378831343-3534-1-git-send-email-denkenz@gmail.com>
Hi Denis,
On Tue, Sep 10, 2013, Denis Kenzior wrote:
> The current implementation does not expect a reply, nor would it make
> sense for BlueZ to wait for one from the agent. So explicitly label
> this method as noreply.
> ---
> doc/profile-api.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
All three patches have been applied. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 1/3] avdtp: Remove not used pending_auth from struct avdtp
From: Johan Hedberg @ 2013-09-11 14:41 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <1378907534-6899-1-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
On Wed, Sep 11, 2013, Szymon Janc wrote:
> ---
> profiles/audio/avdtp.c | 11 ++---------
> 1 file changed, 2 insertions(+), 9 deletions(-)
All three patches have been applied. Thanks.
Johan
^ permalink raw reply
* [PATCH] monitor: Add missing include
From: Szymon Janc @ 2013-09-11 14:03 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
Bionic library requires explicit include for data types used in ioctl
call. This fix following build error with bionic:
target C: btmon <= external/bluetooth/bluez/monitor/display.c
external/bluetooth/bluez/monitor/display.c: In function 'num_columns':
external/bluetooth/bluez/monitor/display.c:59:18: error: storage size
of 'ws' isn't known
---
monitor/display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/monitor/display.c b/monitor/display.c
index 7b6fc98..b8dce1f 100644
--- a/monitor/display.c
+++ b/monitor/display.c
@@ -35,6 +35,7 @@
#include <sys/wait.h>
#include <sys/prctl.h>
#include <sys/ioctl.h>
+#include <termios.h>
#include "display.h"
--
1.8.4
^ permalink raw reply related
* [PATCH 3/3] avdtp: Remove unused STREAM_TIMEOUT define
From: Szymon Janc @ 2013-09-11 13:52 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
In-Reply-To: <1378907534-6899-1-git-send-email-szymon.janc@tieto.com>
---
profiles/audio/avdtp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/profiles/audio/avdtp.c b/profiles/audio/avdtp.c
index 5422ca3..fe63a40 100644
--- a/profiles/audio/avdtp.c
+++ b/profiles/audio/avdtp.c
@@ -86,7 +86,6 @@
#define REQ_TIMEOUT 6
#define ABORT_TIMEOUT 2
#define DISCONNECT_TIMEOUT 1
-#define STREAM_TIMEOUT 20
#define START_TIMEOUT 1
#if __BYTE_ORDER == __LITTLE_ENDIAN
--
1.8.4
^ permalink raw reply related
* [PATCH 2/3] avdtp: Remove not used includes
From: Szymon Janc @ 2013-09-11 13:52 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
In-Reply-To: <1378907534-6899-1-git-send-email-szymon.janc@tieto.com>
---
profiles/audio/avdtp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/profiles/audio/avdtp.c b/profiles/audio/avdtp.c
index 61f55d6..5422ca3 100644
--- a/profiles/audio/avdtp.c
+++ b/profiles/audio/avdtp.c
@@ -33,8 +33,6 @@
#include <errno.h>
#include <unistd.h>
#include <assert.h>
-#include <signal.h>
-#include <netinet/in.h>
#include <bluetooth/bluetooth.h>
#include <bluetooth/sdp.h>
@@ -49,7 +47,6 @@
#include "src/adapter.h"
#include "src/device.h"
-#include "control.h"
#include "avdtp.h"
#include "sink.h"
#include "source.h"
--
1.8.4
^ permalink raw reply related
* [PATCH 1/3] avdtp: Remove not used pending_auth from struct avdtp
From: Szymon Janc @ 2013-09-11 13:52 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
---
profiles/audio/avdtp.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/profiles/audio/avdtp.c b/profiles/audio/avdtp.c
index 818dbdd..61f55d6 100644
--- a/profiles/audio/avdtp.c
+++ b/profiles/audio/avdtp.c
@@ -41,7 +41,6 @@
#include <bluetooth/sdp_lib.h>
#include <glib.h>
-#include <dbus/dbus.h>
#include <btio/btio.h>
#include "log.h"
@@ -426,8 +425,6 @@ struct avdtp {
/* Attempt stream setup instead of disconnecting */
gboolean stream_setup;
-
- DBusPendingCall *pending_auth;
};
static GSList *servers = NULL;
@@ -2325,12 +2322,8 @@ static struct avdtp *avdtp_get_internal(struct btd_device *device)
return NULL;
session = find_session(server->sessions, device);
- if (session) {
- if (session->pending_auth)
- return NULL;
- else
- return session;
- }
+ if (session)
+ return session;
session = g_new0(struct avdtp, 1);
--
1.8.4
^ 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