Linux bluetooth development
 help / color / mirror / Atom feed
* Re: [REGRESSION] rfcomm (userland) broken by commit 29cd718b
From: Gianluca Anzolin @ 2013-12-15 11:24 UTC (permalink / raw)
  To: Alexander Holler
  Cc: Peter Hurley, Gustavo Padovan, marcel, linux-bluetooth, gregkh,
	jslaby, linux-kernel
In-Reply-To: <52AA483E.4080706@ahsoftware.de>

On Fri, Dec 13, 2013 at 12:35:26AM +0100, Alexander Holler wrote:
> Am 12.12.2013 21:36, schrieb Peter Hurley:
> 
> >> What currently happens is that when one kills rfcomm (and any other
> >> terminal which might use that tty), the entry in /dev doesn't
> >> disappear. That means the same call to refcomm with the same device
> >> (e.g. [/dev/]rfcomm1 doesn't work.
> > 
> > Thanks for the report, Alexander.
> > 
> > Point 4 above details a different situation; something else is
> > happening.
> > 
> > Would you please detail the necessary steps to reproduce this regression?
> > (How do you 'kill' rfcomm? etc.  Shell command lines would be best.)
> 
> Just call
> 
> rfcomm connect rfcomm9 01:23:45:67:89:ab
> 
> wait until the connection happened  (a message will appear) and then
> press ctrl-c. This still terminates the bluetooth connection, but the
> device in /dev is now left.

Yes I'm able to reproduce the regression which is indeed caused by that
commit.

However I'm puzzled. Surely there is a fifth case I didn't cover because
when rfcomm_dev_state_change() is called, the tty_port is there but the tty is
not, and therefore I cannot get a reference to it and send the HUP.

I'll let you know when I have something working.

> 
> Regards,
> 
> Alexander Holler

^ permalink raw reply

* Re: Shouldn't bluez serialize connection/authorization attempts?
From: Alexander Holler @ 2013-12-14 15:48 UTC (permalink / raw)
  To: linux-bluetooth
In-Reply-To: <52AC7237.10306@ahsoftware.de>

Am 14.12.2013 15:59, schrieb Alexander Holler:
> Am 14.12.2013 14:36, schrieb Johan Hedberg:
>> Hi Alexander,
>>
>> On Sat, Dec 14, 2013, Alexander Holler wrote:
>>> So besides the first connection attempt, all others do die somewhere
>>> where userspace has no control over.
>>>
>>> What happens is likely that connection attempts are refused by the
>>> remote side, because an ongoing connection or authorization attempt
>>> isn't finished while a new one arrives.
>>
>>  From the HCI logs you showed on IRC it was quite clear that the (remote
>> side) authorization phase for each connect attempt was finished before
>> the next connect attempt started, i.e. there was an L2CAP Connect
>> Response with an error status before the next L2CAP Connect Request. So
>> from this perspective there didn't seem to be any lack of serialization.
>
> That wasn't so clear for me as I've seen different responses from the
> remote device, but still nothing ended up at the local agent afer the
> first connection attempt failed (regardless how many retries).
>
> So there is no solution to this problem and one local user can easily
> DOS all local bluetooth communicaton?

Ok, that might be the wrong question. But I see two problems here:

First, an application can't be sure why a connection attempt failed. 
Second, how should an application behave if a connection attempt failed 
because of unknown reasons? Just retrying doesn't seem work.

Regards,

Alexander Holler


^ permalink raw reply

* Re: Shouldn't bluez serialize connection/authorization attempts?
From: Alexander Holler @ 2013-12-14 14:59 UTC (permalink / raw)
  To: linux-bluetooth
In-Reply-To: <20131214133625.GA27187@x220.p-661hnu-f1>

Am 14.12.2013 14:36, schrieb Johan Hedberg:
> Hi Alexander,
> 
> On Sat, Dec 14, 2013, Alexander Holler wrote:
>> So besides the first connection attempt, all others do die somewhere
>> where userspace has no control over.
>>
>> What happens is likely that connection attempts are refused by the
>> remote side, because an ongoing connection or authorization attempt
>> isn't finished while a new one arrives.
> 
> From the HCI logs you showed on IRC it was quite clear that the (remote
> side) authorization phase for each connect attempt was finished before
> the next connect attempt started, i.e. there was an L2CAP Connect
> Response with an error status before the next L2CAP Connect Request. So
> from this perspective there didn't seem to be any lack of serialization.

That wasn't so clear for me as I've seen different responses from the
remote device, but still nothing ended up at the local agent afer the
first connection attempt failed (regardless how many retries).

So there is no solution to this problem and one local user can easily
DOS all local bluetooth communicaton?

Regards,

Alexander Holler

^ permalink raw reply

* Re: [PATCH -next v2] Bluetooth: fix return value check
From: Marcel Holtmann @ 2013-12-14 14:50 UTC (permalink / raw)
  To: Wei Yongjun
  Cc: Gustavo F. Padovan, Johan Hedberg, yongjun_wei,
	linux-bluetooth@vger.kernel.org development
In-Reply-To: <CAPgLHd-RYQ14ZoEKZGm0iO5JVkPmr5s1k+H6nh4OR=Wr=r8EfQ@mail.gmail.com>

Hi Wei,

> In case of error, the function bt_skb_alloc() returns NULL pointer
> not ERR_PTR(). The IS_ERR() test in the return value check should
> be replaced with NULL test.
> 
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> ---
> net/bluetooth/6lowpan.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)

patch has been applied to bluetooth-next tree.

Regards

Marcel


^ permalink raw reply

* [PATCH -next v2] Bluetooth: fix return value check
From: Wei Yongjun @ 2013-12-14 13:55 UTC (permalink / raw)
  To: marcel, gustavo, johan.hedberg; +Cc: yongjun_wei, linux-bluetooth

From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>

In case of error, the function bt_skb_alloc() returns NULL pointer
not ERR_PTR(). The IS_ERR() test in the return value check should
be replaced with NULL test.

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
 net/bluetooth/6lowpan.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index 37239db..fb38c78 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -337,8 +337,8 @@ static inline int skbuff_copy(void *msg, int len, int count, int mtu,
 		count = min_t(unsigned int, mtu, len);
 
 		tmp = bt_skb_alloc(count, GFP_ATOMIC);
-		if (IS_ERR(tmp))
-			return PTR_ERR(tmp);
+		if (!tmp)
+			return -ENOMEM;
 
 		*frag = tmp;
 
@@ -384,8 +384,8 @@ static struct sk_buff *create_pdu(struct l2cap_conn *conn, void *msg,
 	BT_DBG("conn %p len %zu mtu %d count %d", conn, len, conn->mtu, count);
 
 	skb = bt_skb_alloc(count + L2CAP_HDR_SIZE, GFP_ATOMIC);
-	if (IS_ERR(skb))
-		return skb;
+	if (!skb)
+		return ERR_PTR(-ENOMEM);
 
 	skb->priority = priority;
 

^ permalink raw reply related

* Re: Shouldn't bluez serialize connection/authorization attempts?
From: Johan Hedberg @ 2013-12-14 13:36 UTC (permalink / raw)
  To: Alexander Holler; +Cc: linux-bluetooth
In-Reply-To: <52AC4425.7080109@ahsoftware.de>

Hi Alexander,

On Sat, Dec 14, 2013, Alexander Holler wrote:
> So besides the first connection attempt, all others do die somewhere
> where userspace has no control over.
> 
> What happens is likely that connection attempts are refused by the
> remote side, because an ongoing connection or authorization attempt
> isn't finished while a new one arrives.

>From the HCI logs you showed on IRC it was quite clear that the (remote
side) authorization phase for each connect attempt was finished before
the next connect attempt started, i.e. there was an L2CAP Connect
Response with an error status before the next L2CAP Connect Request. So
from this perspective there didn't seem to be any lack of serialization.

Johan

^ permalink raw reply

* Re: Shouldn't bluez serialize connection/authorization attempts?
From: Alexander Holler @ 2013-12-14 11:55 UTC (permalink / raw)
  To: linux-bluetooth
In-Reply-To: <52AC4425.7080109@ahsoftware.de>

Am 14.12.2013 12:42, schrieb Alexander Holler:
> Hello,
>
> I've experienced a small problem which makes me wonder how userspace is
> expected to handle that.
>
> To explain the problem, I use simple-agent and rfcomm on the local side
> (Linux with bluez) and a remote device with a fixed pin (without user
> interaction, it refuses or allows connections based on the pin), but I
> think the underlying problem is independent of that configuration.
>
> Furthermore, I did a small patch to the local simple-agent:
> -----------------
> diff --git a/test/simple-agent b/test/simple-agent
> index 854e1af..63b705b 100755
> --- a/test/simple-agent
> +++ b/test/simple-agent
> @@ -64,8 +64,9 @@ class Agent(dbus.service.Object):
>                                          in_signature="o",
> out_signature="s")
>          def RequestPinCode(self, device):
>                  print("RequestPinCode (%s)" % (device))
> -               set_trusted(device)
> -               return ask("Enter PIN Code: ")
> +               #set_trusted(device)
> +               #return ask("Enter PIN Code: ")
> +               return "666"
>
>          @dbus.service.method(AGENT_INTERFACE,
>                                          in_signature="o",
> out_signature="u")
> -----------------
>
> That means it now always returns 666 as pin without asking the user.
> This pin doesn't match the pin of the remote device.
>
> If I now call
>
> for i in $(seq 1 100); do rfcomm connect rfcomm666 aa:bb:cc:dd:ee:ff ; done
>
> in a shell, only one Pin request (the first) ends up at simple-agent but
> all connection attempts are refused.
>
> So besides the first connection attempt, all others do die somewhere
> where userspace has no control over.
>
> What happens is likely that connection attempts are refused by the
> remote side, because an ongoing connection or authorization attempt
> isn't finished while a new one arrives.
>
> The problem I see here is, that userspace has no control about what
> happens during a connection attempt. And userspace doesn't know if any
> other process just did a connection attempt too. How should userspace
> behave to make sure every connection attempt ends up in a pin-request
> for the user?
>
> Shouldn't those connection/pairing/authorization attempts to the same
> remote device be serialized by bluez?
>

Sorry, I forget to mention the local system: Linux 3.12.5 and bluez 5.12.

Regards,

Alexander Holler


^ permalink raw reply

* Shouldn't bluez serialize connection/authorization attempts?
From: Alexander Holler @ 2013-12-14 11:42 UTC (permalink / raw)
  To: linux-bluetooth

Hello,

I've experienced a small problem which makes me wonder how userspace is 
expected to handle that.

To explain the problem, I use simple-agent and rfcomm on the local side 
(Linux with bluez) and a remote device with a fixed pin (without user 
interaction, it refuses or allows connections based on the pin), but I 
think the underlying problem is independent of that configuration.

Furthermore, I did a small patch to the local simple-agent:
-----------------
diff --git a/test/simple-agent b/test/simple-agent
index 854e1af..63b705b 100755
--- a/test/simple-agent
+++ b/test/simple-agent
@@ -64,8 +64,9 @@ class Agent(dbus.service.Object):
                                         in_signature="o", 
out_signature="s")
         def RequestPinCode(self, device):
                 print("RequestPinCode (%s)" % (device))
-               set_trusted(device)
-               return ask("Enter PIN Code: ")
+               #set_trusted(device)
+               #return ask("Enter PIN Code: ")
+               return "666"

         @dbus.service.method(AGENT_INTERFACE,
                                         in_signature="o", 
out_signature="u")
-----------------

That means it now always returns 666 as pin without asking the user. 
This pin doesn't match the pin of the remote device.

If I now call

for i in $(seq 1 100); do rfcomm connect rfcomm666 aa:bb:cc:dd:ee:ff ; done

in a shell, only one Pin request (the first) ends up at simple-agent but 
all connection attempts are refused.

So besides the first connection attempt, all others do die somewhere 
where userspace has no control over.

What happens is likely that connection attempts are refused by the 
remote side, because an ongoing connection or authorization attempt 
isn't finished while a new one arrives.

The problem I see here is, that userspace has no control about what 
happens during a connection attempt. And userspace doesn't know if any 
other process just did a connection attempt too. How should userspace 
behave to make sure every connection attempt ends up in a pin-request 
for the user?

Shouldn't those connection/pairing/authorization attempts to the same 
remote device be serialized by bluez?

Regards,

Alexander Holler

^ permalink raw reply related

* Re: [PATCH -next] Bluetooth: fix return value check
From: Marcel Holtmann @ 2013-12-14  9:49 UTC (permalink / raw)
  To: Wei Yongjun
  Cc: Gustavo F. Padovan, Johan Hedberg, yongjun_wei,
	linux-bluetooth@vger.kernel.org development
In-Reply-To: <CAPgLHd_1w0SJy3oc7NYgRRzsCZEEZc7SR+RBSz8zjaZsYAPFWg@mail.gmail.com>

Hi Wei,

> In case of error, the function bt_skb_alloc() returns NULL pointer
> not ERR_PTR(). The IS_ERR() test in the return value check should
> be replaced with NULL test.
> 
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> ---
> net/bluetooth/6lowpan.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
> index 37239db..fb38c78 100644
> --- a/net/bluetooth/6lowpan.c
> +++ b/net/bluetooth/6lowpan.c
> @@ -337,8 +337,8 @@ static inline int skbuff_copy(void *msg, int len, int count, int mtu,
> 		count = min_t(unsigned int, mtu, len);
> 
> 		tmp = bt_skb_alloc(count, GFP_ATOMIC);
> -		if (IS_ERR(tmp))
> -			return PTR_ERR(tmp);
> +		if (!tmp)
> +			return PTR_ERR(-ENOMEM);
> 
> 		*frag = tmp;

net/bluetooth/6lowpan.c: In function ‘skbuff_copy’:
net/bluetooth/6lowpan.c:340:4: warning: passing argument 1 of ‘PTR_ERR’ makes pointer from integer without a cast [enabled by default]
    return PTR_ERR(-ENOMEM);
    ^
In file included from /data/kernel/bluetooth-next/arch/x86/include/asm/processor.h:31:0,
                 from /data/kernel/bluetooth-next/arch/x86/include/asm/thread_info.h:22,
                 from include/linux/thread_info.h:54,
                 from /data/kernel/bluetooth-next/arch/x86/include/asm/preempt.h:6,
                 from include/linux/preempt.h:18,
                 from include/linux/spinlock.h:50,
                 from include/linux/mm_types.h:8,
                 from include/linux/kmemcheck.h:4,
                 from include/linux/skbuff.h:18,
                 from include/linux/if_arp.h:26,
                 from net/bluetooth/6lowpan.c:14:
include/linux/err.h:27:127: note: expected ‘const void *’ but argument is of type ‘int’
 static inline long __must_check PTR_ERR(__force const void *ptr)

Have you actually compiled your code?
                                                                                  
> 
> @@ -384,8 +384,8 @@ static struct sk_buff *create_pdu(struct l2cap_conn *conn, void *msg,
> 	BT_DBG("conn %p len %zu mtu %d count %d", conn, len, conn->mtu, count);
> 
> 	skb = bt_skb_alloc(count + L2CAP_HDR_SIZE, GFP_ATOMIC);
> -	if (IS_ERR(skb))
> -		return skb;
> +	if (!skb)
> +		return ERR_PTR(-ENOMEM);
> 
> 	skb->priority = priority;

Regards

Marcel


^ permalink raw reply

* Re: [PATCH -next] Bluetooth: remove unused including <linux/version.h>
From: Marcel Holtmann @ 2013-12-14  9:42 UTC (permalink / raw)
  To: Wei Yongjun
  Cc: Gustavo F. Padovan, Johan Hedberg, yongjun_wei,
	linux-bluetooth@vger.kernel.org development
In-Reply-To: <CAPgLHd9zXw3039hXeoRPMt-0k7E1MRbrhS1tsKoWDvLU1ooV5w@mail.gmail.com>

Hi Wei,

> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> 
> Remove including <linux/version.h> that don't need it.
> 
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> ---
> net/bluetooth/6lowpan.c | 1 -
> 1 file changed, 1 deletion(-)

patch has been applied to bluetooth-next tree.

Regards

Marcel


^ permalink raw reply

* [PATCH -next] Bluetooth: fix return value check
From: Wei Yongjun @ 2013-12-14  4:43 UTC (permalink / raw)
  To: marcel, gustavo, johan.hedberg; +Cc: yongjun_wei, linux-bluetooth

From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>

In case of error, the function bt_skb_alloc() returns NULL pointer
not ERR_PTR(). The IS_ERR() test in the return value check should
be replaced with NULL test.

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
 net/bluetooth/6lowpan.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index 37239db..fb38c78 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -337,8 +337,8 @@ static inline int skbuff_copy(void *msg, int len, int count, int mtu,
 		count = min_t(unsigned int, mtu, len);
 
 		tmp = bt_skb_alloc(count, GFP_ATOMIC);
-		if (IS_ERR(tmp))
-			return PTR_ERR(tmp);
+		if (!tmp)
+			return PTR_ERR(-ENOMEM);
 
 		*frag = tmp;
 
@@ -384,8 +384,8 @@ static struct sk_buff *create_pdu(struct l2cap_conn *conn, void *msg,
 	BT_DBG("conn %p len %zu mtu %d count %d", conn, len, conn->mtu, count);
 
 	skb = bt_skb_alloc(count + L2CAP_HDR_SIZE, GFP_ATOMIC);
-	if (IS_ERR(skb))
-		return skb;
+	if (!skb)
+		return ERR_PTR(-ENOMEM);
 
 	skb->priority = priority;
 

^ permalink raw reply related

* [PATCH -next] Bluetooth: remove unused including <linux/version.h>
From: Wei Yongjun @ 2013-12-14  4:43 UTC (permalink / raw)
  To: marcel, gustavo, johan.hedberg; +Cc: yongjun_wei, linux-bluetooth

From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>

Remove including <linux/version.h> that don't need it.

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
 net/bluetooth/6lowpan.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index ba840fe..18c48e1 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -11,7 +11,6 @@
    GNU General Public License for more details.
 */
 
-#include <linux/version.h>
 #include <linux/if_arp.h>
 #include <linux/netdevice.h>
 #include <linux/etherdevice.h>

^ permalink raw reply related

* Re: Failed to connect: org.bluez.Error.NotReady
From: Brian J. Murrell @ 2013-12-13 17:36 UTC (permalink / raw)
  To: Anderson Lizardo; +Cc: Szymon Janc, Bastien Nocera, BlueZ development
In-Reply-To: <CAJdJm_NMUP3gd1oABgXL9iYJPSwez=1DGCF2b8uKwVNosRS0ZQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

On Fri, 2013-12-13 at 15:09 -0200, Anderson Lizardo wrote:
> Hi Brian,

Hi Anderson,

> Since BlueZ 5, the adapter power state (on/off) is not saved anymore
> by bluetoothd (on BlueZ 4, there were InitiallyPowered/RememberPowered
> options in main.conf that took care of powering up adapters; these
> options are gone in BlueZ 5). There should be an external component
> that takes care of powering up the adapter after it is attached.

Interesting.  I wonder if F20 itself is supposed to be doing this or if
it's expecting the desktop (i.e. via applet or whatever) to do it.

> As Bastien mentioned, it is built-in for GNOME.

Ahh.

> I don't use GNOME,

Me either.  I use MATE.  GNOME[3] is incapable of handling my video
configuration.  GNOME2 and thus MATE handles it just fine, FWIW.

> but
> in theory, once you enable Bluetooth on its settings, the adapter will
> be powered on once it is attached.

So, it seems that F20 *is* expecting the desktop model to handle that.

I wonder what the model is supposed to be for the likes of MATE.  I'm
not at all convinced that the MATE that's in F20 has been
bluetooth-enabled to handle this.

Cheers,
b.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply

* Re: Failed to connect: org.bluez.Error.NotReady
From: Anderson Lizardo @ 2013-12-13 17:09 UTC (permalink / raw)
  To: Brian J. Murrell; +Cc: Szymon Janc, Bastien Nocera, BlueZ development
In-Reply-To: <1386951737.23365.19.camel@pc.interlinx.bc.ca>

Hi Brian,

On Fri, Dec 13, 2013 at 2:22 PM, Brian J. Murrell <brian@interlinx.bc.ca> wrote:
> [bluetooth]# power on
> [CHG] Controller 00:02:72:1E:E0:12 Class: 0x0c0104
> Changing power on succeeded
> [CHG] Controller 00:02:72:1E:E0:12 Powered: yes
> [CHG] Device 7C:1E:52:6E:59:D2 Connected: yes
>
> And now the mouse works.  I wonder what happened in the first place to
> make it stop running.  Certainly the unplugging/plugging in of the
> dongle might have been enough to need it powering on so it's not clear
> that it just spontaneously lost power or anything like that.

Since BlueZ 5, the adapter power state (on/off) is not saved anymore
by bluetoothd (on BlueZ 4, there were InitiallyPowered/RememberPowered
options in main.conf that took care of powering up adapters; these
options are gone in BlueZ 5). There should be an external component
that takes care of powering up the adapter after it is attached.

>
>> (assuming there is no UI applet running that should take care of
>> powering it up automatically.)
>
> Which is an interesting point.  What is the UI applet for all of this
> supposed to be now in F20?

As Bastien mentioned, it is built-in for GNOME. I don't use GNOME, but
in theory, once you enable Bluetooth on its settings, the adapter will
be powered on once it is attached.

Best Regards,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil

^ permalink raw reply

* Re: Failed to connect: org.bluez.Error.NotReady
From: Bastien Nocera @ 2013-12-13 16:24 UTC (permalink / raw)
  To: Brian J. Murrell; +Cc: Anderson Lizardo, Szymon Janc, BlueZ development
In-Reply-To: <1386951737.23365.19.camel@pc.interlinx.bc.ca>

On Fri, 2013-12-13 at 11:22 -0500, Brian J. Murrell wrote:
<snip>
> > (assuming there is no UI applet running that should take care of
> > powering it up automatically.)
> 
> Which is an interesting point.  What is the UI applet for all of this
> supposed to be now in F20?

There's no "applet" in GNOME 3.10. Launch the Settings -> Bluetooth and
turn Bluetooth on there, in the titlebar.


^ permalink raw reply

* Re: Failed to connect: org.bluez.Error.NotReady
From: Brian J. Murrell @ 2013-12-13 16:22 UTC (permalink / raw)
  To: Anderson Lizardo; +Cc: Szymon Janc, Bastien Nocera, BlueZ development
In-Reply-To: <CAJdJm_POfMm8mtbRAWdG9W3F2PwT8kNYkiHYToVZeVz+D1F+TQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]

On Fri, 2013-12-13 at 14:17 -0200, Anderson Lizardo wrote:
> Hi,
> 
> On Fri, Dec 13, 2013 at 1:56 PM, Szymon Janc <szymon.janc@tieto.com> wrote:
> >> [bluetooth]# connect 7C:1E:52:6E:59:D2
> >> Attempting to connect to 7C:1E:52:6E:59:D2
> >> Failed to connect: org.bluez.Error.NotReady
> >>
> >> I have this same problem with my previously paired headset also.  Not
> >> connected and won't connect.
> >
> > Is your adapter powered?:)
> 
> I agree it looks like it's missing "power on" command on bluetoothctl
> here

Hrm.

[bluetooth]# power on
[CHG] Controller 00:02:72:1E:E0:12 Class: 0x0c0104
Changing power on succeeded
[CHG] Controller 00:02:72:1E:E0:12 Powered: yes
[CHG] Device 7C:1E:52:6E:59:D2 Connected: yes

And now the mouse works.  I wonder what happened in the first place to
make it stop running.  Certainly the unplugging/plugging in of the
dongle might have been enough to need it powering on so it's not clear
that it just spontaneously lost power or anything like that.

> (assuming there is no UI applet running that should take care of
> powering it up automatically.)

Which is an interesting point.  What is the UI applet for all of this
supposed to be now in F20?

b.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply

* Re: Failed to connect: org.bluez.Error.NotReady
From: Brian J. Murrell @ 2013-12-13 16:18 UTC (permalink / raw)
  To: Bastien Nocera; +Cc: linux-bluetooth
In-Reply-To: <1386950230.6234.2.camel@nuvo>

[-- Attachment #1: Type: text/plain, Size: 16769 bytes --]

On Fri, 2013-12-13 at 16:57 +0100, Bastien Nocera wrote:
> 
> Then use btmon

It doesn't report anything:

= New Index: 00:02:72:1E:E0:12 (BR/EDR,USB,hci0)                [hci0] 0.981520

That's it.  I tried turning the mouse off and on while running that.
Headset too.

>  to gather some debug information, or even use "journalctl
> -b | grep bluetooth"

Dec 11 11:51:57 pc.interlinx.bc.ca bluetoothd[1405]: Bluetooth daemon 5.11
Dec 11 11:51:57 pc.interlinx.bc.ca bluetoothd[1405]: Starting SDP server
Dec 11 11:51:57 pc.interlinx.bc.ca bluetoothd[1405]: Bluetooth management interface 1.3 initialized
Dec 11 11:52:36 pc.interlinx.bc.ca bluetoothd[1405]: Endpoint registered: sender=:1.40 path=/MediaEndpoint/A2DPSource
Dec 11 11:52:36 pc.interlinx.bc.ca bluetoothd[1405]: Endpoint registered: sender=:1.40 path=/MediaEndpoint/A2DPSink
Dec 11 15:06:51 pc.interlinx.bc.ca bluetoothd[1405]: Endpoint unregistered: sender=:1.40 path=/MediaEndpoint/A2DPSource
Dec 11 15:06:51 pc.interlinx.bc.ca bluetoothd[1405]: Endpoint unregistered: sender=:1.40 path=/MediaEndpoint/A2DPSink
Dec 11 15:06:51 pc.interlinx.bc.ca dbus[1232]: [system] Rejected send message, 4 matched rules; type="error", sender=":1.40" (uid=1001 pid=1962 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.14" (uid=0 pid=1405 comm="/usr/libexec/bluetooth/bluetoothd ")
Dec 11 15:06:51 pc.interlinx.bc.ca dbus[1232]: [system] Rejected send message, 4 matched rules; type="error", sender=":1.40" (uid=1001 pid=1962 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.14" (uid=0 pid=1405 comm="/usr/libexec/bluetooth/bluetoothd ")
Dec 11 15:06:51 pc.interlinx.bc.ca dbus[1232]: [system] Rejected send message, 4 matched rules; type="error", sender=":1.40" (uid=1001 pid=1962 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.14" (uid=0 pid=1405 comm="/usr/libexec/bluetooth/bluetoothd ")
Dec 11 15:06:51 pc.interlinx.bc.ca dbus[1232]: [system] Rejected send message, 4 matched rules; type="error", sender=":1.40" (uid=1001 pid=1962 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.14" (uid=0 pid=1405 comm="/usr/libexec/bluetooth/bluetoothd ")
Dec 11 15:06:51 pc.interlinx.bc.ca dbus-daemon[1232]: dbus[1232]: [system] Rejected send message, 4 matched rules; type="error", sender=":1.40" (uid=1001 pid=1962 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.14" (uid=0 pid=1405 comm="/usr/libexec/bluetooth/bluetoothd ")
Dec 11 15:06:51 pc.interlinx.bc.ca dbus-daemon[1232]: dbus[1232]: [system] Rejected send message, 4 matched rules; type="error", sender=":1.40" (uid=1001 pid=1962 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.14" (uid=0 pid=1405 comm="/usr/libexec/bluetooth/bluetoothd ")
Dec 11 15:06:52 pc.interlinx.bc.ca dbus-daemon[1232]: dbus[1232]: [system] Rejected send message, 4 matched rules; type="error", sender=":1.40" (uid=1001 pid=1962 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.14" (uid=0 pid=1405 comm="/usr/libexec/bluetooth/bluetoothd ")
Dec 11 15:06:52 pc.interlinx.bc.ca dbus-daemon[1232]: dbus[1232]: [system] Rejected send message, 4 matched rules; type="error", sender=":1.40" (uid=1001 pid=1962 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.14" (uid=0 pid=1405 comm="/usr/libexec/bluetooth/bluetoothd ")
Dec 11 15:07:05 pc.interlinx.bc.ca bluetoothd[1405]: Endpoint registered: sender=:1.40 path=/MediaEndpoint/A2DPSource
Dec 11 15:07:05 pc.interlinx.bc.ca bluetoothd[1405]: Endpoint registered: sender=:1.40 path=/MediaEndpoint/A2DPSink
Dec 11 15:07:07 pc.interlinx.bc.ca bluetoothd[1405]: No supported peripheral found
Dec 11 15:07:07 pc.interlinx.bc.ca bluetoothd[1405]: No supported peripheral found
Dec 11 15:11:06 pc.interlinx.bc.ca kernel: input: Microsoft Sculpt Touch Mouse as /devices/pci0000:00/0000:00:02.0/usb2/2-1/2-1.3/2-1.3:1.0/bluetooth/hci0/hci0:11/input15
Dec 11 15:11:07 pc.interlinx.bc.ca bluetoothd[1405]: No supported peripheral found
Dec 11 18:51:38 pc.interlinx.bc.ca kernel: input: Microsoft Sculpt Touch Mouse as /devices/pci0000:00/0000:00:02.0/usb2/2-1/2-1.3/2-1.3:1.0/bluetooth/hci0/hci0:11/input16
Dec 11 18:51:40 pc.interlinx.bc.ca bluetoothd[1405]: No supported peripheral found
Dec 12 05:49:53 pc.interlinx.bc.ca kernel: input: Microsoft Sculpt Touch Mouse as /devices/pci0000:00/0000:00:02.0/usb2/2-1/2-1.3/2-1.3:1.0/bluetooth/hci0/hci0:11/input17
Dec 12 05:49:55 pc.interlinx.bc.ca bluetoothd[1405]: No supported peripheral found
Dec 12 06:44:22 pc.interlinx.bc.ca bluetoothd[1405]: No supported peripheral found
Dec 12 06:44:25 pc.interlinx.bc.ca kernel: input: Microsoft Sculpt Touch Mouse as /devices/pci0000:00/0000:00:02.0/usb2/2-1/2-1.3/2-1.3:1.0/bluetooth/hci0/hci0:11/input18
Dec 12 11:23:37 pc.interlinx.bc.ca kernel: input: Microsoft Sculpt Touch Mouse as /devices/pci0000:00/0000:00:02.0/usb2/2-1/2-1.3/2-1.3:1.0/bluetooth/hci0/hci0:11/input19
Dec 12 11:23:42 pc.interlinx.bc.ca bluetoothd[1405]: No supported peripheral found
Dec 12 13:53:30 pc.interlinx.bc.ca kernel: input: Microsoft Sculpt Touch Mouse as /devices/pci0000:00/0000:00:02.0/usb2/2-1/2-1.3/2-1.3:1.0/bluetooth/hci0/hci0:11/input20
Dec 12 13:53:32 pc.interlinx.bc.ca bluetoothd[1405]: No supported peripheral found
Dec 12 15:32:47 pc.interlinx.bc.ca kernel: input: Microsoft Sculpt Touch Mouse as /devices/pci0000:00/0000:00:02.0/usb2/2-1/2-1.3/2-1.3:1.0/bluetooth/hci0/hci0:11/input21
Dec 12 15:32:49 pc.interlinx.bc.ca bluetoothd[1405]: No supported peripheral found
Dec 13 05:46:01 pc.interlinx.bc.ca kernel: input: Microsoft Sculpt Touch Mouse as /devices/pci0000:00/0000:00:02.0/usb2/2-1/2-1.3/2-1.3:1.0/bluetooth/hci0/hci0:11/input22
Dec 13 05:46:02 pc.interlinx.bc.ca bluetoothd[1405]: No supported peripheral found
Dec 13 10:00:19 pc.interlinx.bc.ca bluetoothd[1405]: Endpoint unregistered: sender=:1.40 path=/MediaEndpoint/A2DPSource
Dec 13 10:00:19 pc.interlinx.bc.ca bluetoothd[1405]: Endpoint unregistered: sender=:1.40 path=/MediaEndpoint/A2DPSink
Dec 13 10:01:00 pc.interlinx.bc.ca bluetoothd[1405]: Endpoint registered: sender=:1.243 path=/MediaEndpoint/A2DPSource
Dec 13 10:01:00 pc.interlinx.bc.ca bluetoothd[1405]: Endpoint registered: sender=:1.243 path=/MediaEndpoint/A2DPSink
Dec 13 10:16:57 pc.interlinx.bc.ca bluetoothd[1405]: Terminating
Dec 13 10:16:59 pc.interlinx.bc.ca bluetoothd[1405]: Endpoint unregistered: sender=:1.243 path=/MediaEndpoint/A2DPSource
Dec 13 10:16:59 pc.interlinx.bc.ca bluetoothd[1405]: Endpoint unregistered: sender=:1.243 path=/MediaEndpoint/A2DPSink
Dec 13 10:16:59 pc.interlinx.bc.ca bluetoothd[1405]: Stopping SDP server
Dec 13 10:16:59 pc.interlinx.bc.ca bluetoothd[1405]: Exit
Dec 13 10:17:01 pc.interlinx.bc.ca bluetoothd[27809]: Bluetooth daemon 5.12
Dec 13 10:17:02 pc.interlinx.bc.ca bluetoothd[27809]: Starting SDP server
Dec 13 10:17:02 pc.interlinx.bc.ca bluetoothd[27809]: Bluetooth management interface 1.3 initialized
Dec 13 10:17:05 pc.interlinx.bc.ca bluetoothd[27809]: Endpoint registered: sender=:1.243 path=/MediaEndpoint/A2DPSource
Dec 13 10:17:05 pc.interlinx.bc.ca bluetoothd[27809]: Endpoint registered: sender=:1.243 path=/MediaEndpoint/A2DPSink
Dec 13 10:21:11 pc.interlinx.bc.ca sudo[28307]: brian : TTY=pts/1 ; PWD=/home/brian ; USER=root ; COMMAND=/sbin/service bluetooth restart
Dec 13 10:21:12 pc.interlinx.bc.ca bluetoothd[27809]: Terminating
Dec 13 10:21:12 pc.interlinx.bc.ca dbus[1232]: [system] Rejected send message, 4 matched rules; type="error", sender=":1.243" (uid=1001 pid=24392 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.256" (uid=0 pid=27809 comm="/usr/libexec/bluetooth/bluetoothd ")
Dec 13 10:21:12 pc.interlinx.bc.ca bluetoothd[27809]: Endpoint unregistered: sender=:1.243 path=/MediaEndpoint/A2DPSource
Dec 13 10:21:12 pc.interlinx.bc.ca bluetoothd[27809]: Endpoint unregistered: sender=:1.243 path=/MediaEndpoint/A2DPSink
Dec 13 10:21:12 pc.interlinx.bc.ca dbus[1232]: [system] Rejected send message, 4 matched rules; type="error", sender=":1.243" (uid=1001 pid=24392 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.256" (uid=0 pid=27809 comm="/usr/libexec/bluetooth/bluetoothd ")
Dec 13 10:21:12 pc.interlinx.bc.ca dbus[1232]: [system] Rejected send message, 4 matched rules; type="error", sender=":1.243" (uid=1001 pid=24392 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.256" (uid=0 pid=27809 comm="/usr/libexec/bluetooth/bluetoothd ")
Dec 13 10:21:12 pc.interlinx.bc.ca dbus[1232]: [system] Rejected send message, 4 matched rules; type="error", sender=":1.243" (uid=1001 pid=24392 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.256" (uid=0 pid=27809 comm="/usr/libexec/bluetooth/bluetoothd ")
Dec 13 10:21:12 pc.interlinx.bc.ca bluetoothd[27809]: Stopping SDP server
Dec 13 10:21:12 pc.interlinx.bc.ca bluetoothd[27809]: Exit
Dec 13 10:21:12 pc.interlinx.bc.ca bluetoothd[28339]: Bluetooth daemon 5.12
Dec 13 10:21:12 pc.interlinx.bc.ca bluetoothd[28339]: Starting SDP server
Dec 13 10:21:13 pc.interlinx.bc.ca bluetoothd[28339]: Bluetooth management interface 1.3 initialized
Dec 13 10:21:13 pc.interlinx.bc.ca bluetoothd[28339]: Endpoint registered: sender=:1.243 path=/MediaEndpoint/A2DPSource
Dec 13 10:21:13 pc.interlinx.bc.ca bluetoothd[28339]: Endpoint registered: sender=:1.243 path=/MediaEndpoint/A2DPSink
Dec 13 10:21:14 pc.interlinx.bc.ca dbus-daemon[1232]: dbus[1232]: [system] Rejected send message, 4 matched rules; type="error", sender=":1.243" (uid=1001 pid=24392 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.256" (uid=0 pid=27809 comm="/usr/libexec/bluetooth/bluetoothd ")
Dec 13 10:21:14 pc.interlinx.bc.ca dbus-daemon[1232]: dbus[1232]: [system] Rejected send message, 4 matched rules; type="error", sender=":1.243" (uid=1001 pid=24392 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.256" (uid=0 pid=27809 comm="/usr/libexec/bluetooth/bluetoothd ")
Dec 13 10:21:14 pc.interlinx.bc.ca dbus-daemon[1232]: dbus[1232]: [system] Rejected send message, 4 matched rules; type="error", sender=":1.243" (uid=1001 pid=24392 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.256" (uid=0 pid=27809 comm="/usr/libexec/bluetooth/bluetoothd ")
Dec 13 10:21:14 pc.interlinx.bc.ca dbus-daemon[1232]: dbus[1232]: [system] Rejected send message, 4 matched rules; type="error", sender=":1.243" (uid=1001 pid=24392 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.256" (uid=0 pid=27809 comm="/usr/libexec/bluetooth/bluetoothd ")
Dec 13 10:24:03 pc.interlinx.bc.ca bluetoothd[28339]: Endpoint unregistered: sender=:1.243 path=/MediaEndpoint/A2DPSource
Dec 13 10:24:03 pc.interlinx.bc.ca bluetoothd[28339]: Endpoint unregistered: sender=:1.243 path=/MediaEndpoint/A2DPSink
Dec 13 10:24:03 pc.interlinx.bc.ca dbus[1232]: [system] Rejected send message, 4 matched rules; type="error", sender=":1.243" (uid=1001 pid=24392 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.261" (uid=0 pid=28339 comm="/usr/libexec/bluetooth/bluetoothd ")
Dec 13 10:24:03 pc.interlinx.bc.ca dbus[1232]: [system] Rejected send message, 4 matched rules; type="error", sender=":1.243" (uid=1001 pid=24392 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.261" (uid=0 pid=28339 comm="/usr/libexec/bluetooth/bluetoothd ")
Dec 13 10:24:03 pc.interlinx.bc.ca dbus[1232]: [system] Rejected send message, 4 matched rules; type="error", sender=":1.243" (uid=1001 pid=24392 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.261" (uid=0 pid=28339 comm="/usr/libexec/bluetooth/bluetoothd ")
Dec 13 10:24:03 pc.interlinx.bc.ca dbus[1232]: [system] Rejected send message, 4 matched rules; type="error", sender=":1.243" (uid=1001 pid=24392 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.261" (uid=0 pid=28339 comm="/usr/libexec/bluetooth/bluetoothd ")
Dec 13 10:24:03 pc.interlinx.bc.ca dbus-daemon[1232]: dbus[1232]: [system] Rejected send message, 4 matched rules; type="error", sender=":1.243" (uid=1001 pid=24392 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.261" (uid=0 pid=28339 comm="/usr/libexec/bluetooth/bluetoothd ")
Dec 13 10:24:03 pc.interlinx.bc.ca dbus-daemon[1232]: dbus[1232]: [system] Rejected send message, 4 matched rules; type="error", sender=":1.243" (uid=1001 pid=24392 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.261" (uid=0 pid=28339 comm="/usr/libexec/bluetooth/bluetoothd ")
Dec 13 10:24:03 pc.interlinx.bc.ca dbus-daemon[1232]: dbus[1232]: [system] Rejected send message, 4 matched rules; type="error", sender=":1.243" (uid=1001 pid=24392 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.261" (uid=0 pid=28339 comm="/usr/libexec/bluetooth/bluetoothd ")
Dec 13 10:24:03 pc.interlinx.bc.ca dbus-daemon[1232]: dbus[1232]: [system] Rejected send message, 4 matched rules; type="error", sender=":1.243" (uid=1001 pid=24392 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.261" (uid=0 pid=28339 comm="/usr/libexec/bluetooth/bluetoothd ")
Dec 13 10:24:03 pc.interlinx.bc.ca systemd[1]: Service bluetooth.target is not needed anymore. Stopping.
Dec 13 10:24:13 pc.interlinx.bc.ca bluetoothd[28339]: Endpoint registered: sender=:1.243 path=/MediaEndpoint/A2DPSource
Dec 13 10:24:13 pc.interlinx.bc.ca bluetoothd[28339]: Endpoint registered: sender=:1.243 path=/MediaEndpoint/A2DPSink

Earlier today I did a "service bluetooth restart" as well as
unplugging/plugging the dongle, so those are probably reflected in
there.

> to see if there's more debug output from the
> daemon.
> 
> The mouse should be trying to reconnect, no idea why it wouldn't be able
> to...

Indeed.  :-)

b.




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply

* Re: Failed to connect: org.bluez.Error.NotReady
From: Anderson Lizardo @ 2013-12-13 16:17 UTC (permalink / raw)
  To: Szymon Janc; +Cc: Brian J. Murrell, Bastien Nocera, BlueZ development
In-Reply-To: <1691350.CipnhsEWy0@uw000953>

Hi,

On Fri, Dec 13, 2013 at 1:56 PM, Szymon Janc <szymon.janc@tieto.com> wrote:
>> [bluetooth]# connect 7C:1E:52:6E:59:D2
>> Attempting to connect to 7C:1E:52:6E:59:D2
>> Failed to connect: org.bluez.Error.NotReady
>>
>> I have this same problem with my previously paired headset also.  Not
>> connected and won't connect.
>
> Is your adapter powered?:)

I agree it looks like it's missing "power on" command on bluetoothctl
here (assuming there is no UI applet running that should take care of
powering it up automatically.)

Best Regards,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil

^ permalink raw reply

* Re: Failed to connect: org.bluez.Error.NotReady
From: Bastien Nocera @ 2013-12-13 15:57 UTC (permalink / raw)
  To: Brian J. Murrell; +Cc: linux-bluetooth
In-Reply-To: <1386949827.23365.9.camel@pc.interlinx.bc.ca>

On Fri, 2013-12-13 at 10:50 -0500, Brian J. Murrell wrote:
> On Fri, 2013-12-13 at 16:42 +0100, Bastien Nocera wrote:
> > Looks like the mouse doesn't accept to be connected through remotely.
> 
> But why would it (a) all of a sudden become disconnected while I was
> using it and (b) a problem today, after having been using this mouse
> successfully for a few days now, including have it reconnect after being
> idle for long periods of time (i.e. overnight)?
> 
> > Turning it off an on should make it connect back to the machine
> 
> Unfortunately not.  After turning it off and then on again, still no
> connection and none possible:
> 
> # info 7C:1E:52:6E:59:D2
> Device 7C:1E:52:6E:59:D2
> 	Name: Microsoft Sculpt Touch Mouse
> 	Alias: Microsoft Sculpt Touch Mouse
> 	Class: 0x000580
> 	Icon: input-mouse
> 	Paired: yes
> 	Trusted: yes
> 	Blocked: no
> 	Connected: no
> 	LegacyPairing: no
> 	UUID: Service Discovery Serve.. (00001000-0000-1000-8000-00805f9b34fb)
> 	UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
> 	UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
> 	Modalias: usb:v045Ep077Cd011E
> [bluetooth]# connect 7C:1E:52:6E:59:D2
> Attempting to connect to 7C:1E:52:6E:59:D2
> Failed to connect: org.bluez.Error.NotReady
> 
> I have this same problem with my previously paired headset also.  Not
> connected and won't connect.

Then use btmon to gather some debug information, or even use "journalctl
-b | grep bluetooth" to see if there's more debug output from the
daemon.

The mouse should be trying to reconnect, no idea why it wouldn't be able
to...


^ permalink raw reply

* Re: Failed to connect: org.bluez.Error.NotReady
From: Szymon Janc @ 2013-12-13 15:56 UTC (permalink / raw)
  To: Brian J. Murrell; +Cc: Bastien Nocera, linux-bluetooth
In-Reply-To: <1386949827.23365.9.camel@pc.interlinx.bc.ca>

Hi Brian,

> On Fri, 2013-12-13 at 16:42 +0100, Bastien Nocera wrote:
> > Looks like the mouse doesn't accept to be connected through remotely.
> 
> But why would it (a) all of a sudden become disconnected while I was
> using it and (b) a problem today, after having been using this mouse
> successfully for a few days now, including have it reconnect after being
> idle for long periods of time (i.e. overnight)?
> 
> > Turning it off an on should make it connect back to the machine
> 
> Unfortunately not.  After turning it off and then on again, still no
> connection and none possible:
> 
> # info 7C:1E:52:6E:59:D2
> Device 7C:1E:52:6E:59:D2
> 	Name: Microsoft Sculpt Touch Mouse
> 	Alias: Microsoft Sculpt Touch Mouse
> 	Class: 0x000580
> 	Icon: input-mouse
> 	Paired: yes
> 	Trusted: yes
> 	Blocked: no
> 	Connected: no
> 	LegacyPairing: no
> 	UUID: Service Discovery Serve.. (00001000-0000-1000-8000-00805f9b34fb)
> 	UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
> 	UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
> 	Modalias: usb:v045Ep077Cd011E
> [bluetooth]# connect 7C:1E:52:6E:59:D2
> Attempting to connect to 7C:1E:52:6E:59:D2
> Failed to connect: org.bluez.Error.NotReady
> 
> I have this same problem with my previously paired headset also.  Not
> connected and won't connect.

Is your adapter powered?:)

-- 
BR
Szymon Janc



^ permalink raw reply

* Re: Failed to connect: org.bluez.Error.NotReady
From: Brian J. Murrell @ 2013-12-13 15:50 UTC (permalink / raw)
  To: Bastien Nocera; +Cc: linux-bluetooth
In-Reply-To: <1386949351.6234.0.camel@nuvo>

[-- Attachment #1: Type: text/plain, Size: 1314 bytes --]

On Fri, 2013-12-13 at 16:42 +0100, Bastien Nocera wrote:
> Looks like the mouse doesn't accept to be connected through remotely.

But why would it (a) all of a sudden become disconnected while I was
using it and (b) a problem today, after having been using this mouse
successfully for a few days now, including have it reconnect after being
idle for long periods of time (i.e. overnight)?

> Turning it off an on should make it connect back to the machine

Unfortunately not.  After turning it off and then on again, still no
connection and none possible:

# info 7C:1E:52:6E:59:D2
Device 7C:1E:52:6E:59:D2
	Name: Microsoft Sculpt Touch Mouse
	Alias: Microsoft Sculpt Touch Mouse
	Class: 0x000580
	Icon: input-mouse
	Paired: yes
	Trusted: yes
	Blocked: no
	Connected: no
	LegacyPairing: no
	UUID: Service Discovery Serve.. (00001000-0000-1000-8000-00805f9b34fb)
	UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
	UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
	Modalias: usb:v045Ep077Cd011E
[bluetooth]# connect 7C:1E:52:6E:59:D2
Attempting to connect to 7C:1E:52:6E:59:D2
Failed to connect: org.bluez.Error.NotReady

I have this same problem with my previously paired headset also.  Not
connected and won't connect.

Cheers,
b.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply

* Re: Failed to connect: org.bluez.Error.NotReady
From: Bastien Nocera @ 2013-12-13 15:42 UTC (permalink / raw)
  To: Brian J. Murrell; +Cc: linux-bluetooth
In-Reply-To: <1386948800.23365.2.camel@pc.interlinx.bc.ca>

On Fri, 2013-12-13 at 10:33 -0500, Brian J. Murrell wrote:
> So I was happily chugging along using bluez5 on F20 with the previously
> mentioned mouse and all of a sudden it stopped working.  So to
> bluetoothctl I go:
> 
> $ bluetoothctl 
> [NEW] Controller 00:02:72:1E:E0:12 pc.interlinx.bc.ca-0 [default]
> [NEW] Device 00:0D:E6:68:B4:6F Samsung WEP850
> [NEW] Device 70:F3:95:3E:92:34 brian-laptop
> [NEW] Device 7C:1E:52:6E:59:D2 Microsoft Sculpt Touch Mouse
> [bluetooth]# info 7C:1E:52:6E:59:D2
> Device 7C:1E:52:6E:59:D2
> 	Name: Microsoft Sculpt Touch Mouse
> 	Alias: Microsoft Sculpt Touch Mouse
> 	Class: 0x000580
> 	Icon: input-mouse
> 	Paired: yes
> 	Trusted: yes
> 	Blocked: no
> 	Connected: no
> 	LegacyPairing: no
> 	UUID: Service Discovery Serve.. (00001000-0000-1000-8000-00805f9b34fb)
> 	UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
> 	UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
> 	Modalias: usb:v045Ep077Cd011E
> [bluetooth]# connect 7C:1E:52:6E:59:D2
> Attempting to connect to 7C:1E:52:6E:59:D2
> Failed to connect: org.bluez.Error.NotReady
> 
> I've tried unplugging and plugging in the dongle.  Not sure what else to
> do at this point.

Looks like the mouse doesn't accept to be connected through remotely.
Turning it off an on should make it connect back to the machine (that's
how it behaves with the MS Wireless presenter mouse).

Cheers


^ permalink raw reply

* Failed to connect: org.bluez.Error.NotReady
From: Brian J. Murrell @ 2013-12-13 15:33 UTC (permalink / raw)
  To: linux-bluetooth

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

So I was happily chugging along using bluez5 on F20 with the previously
mentioned mouse and all of a sudden it stopped working.  So to
bluetoothctl I go:

$ bluetoothctl 
[NEW] Controller 00:02:72:1E:E0:12 pc.interlinx.bc.ca-0 [default]
[NEW] Device 00:0D:E6:68:B4:6F Samsung WEP850
[NEW] Device 70:F3:95:3E:92:34 brian-laptop
[NEW] Device 7C:1E:52:6E:59:D2 Microsoft Sculpt Touch Mouse
[bluetooth]# info 7C:1E:52:6E:59:D2
Device 7C:1E:52:6E:59:D2
	Name: Microsoft Sculpt Touch Mouse
	Alias: Microsoft Sculpt Touch Mouse
	Class: 0x000580
	Icon: input-mouse
	Paired: yes
	Trusted: yes
	Blocked: no
	Connected: no
	LegacyPairing: no
	UUID: Service Discovery Serve.. (00001000-0000-1000-8000-00805f9b34fb)
	UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
	UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
	Modalias: usb:v045Ep077Cd011E
[bluetooth]# connect 7C:1E:52:6E:59:D2
Attempting to connect to 7C:1E:52:6E:59:D2
Failed to connect: org.bluez.Error.NotReady

I've tried unplugging and plugging in the dongle.  Not sure what else to
do at this point.

Any ideas?

Cheers,
b.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply

* Re: [PATCH BlueZ] android: Add initial Android Bluetooth Audio protocol API doc
From: Luiz Augusto von Dentz @ 2013-12-13 15:28 UTC (permalink / raw)
  To: Luiz Augusto von Dentz, linux-bluetooth@vger.kernel.org
In-Reply-To: <20131213144922.GE30037@x220.p-661hnu-f1>

Hi Johan,

On Fri, Dec 13, 2013 at 4:49 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Luiz,
>
> On Fri, Dec 13, 2013, Luiz Augusto von Dentz wrote:
>> This IPC is used to communicate Android BlueZ daemon and AudioFlinger
>> plugin.
>> ---
>>  android/audio-ipc-api.txt | 50 +++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 50 insertions(+)
>>  create mode 100644 android/audio-ipc-api.txt
>
> This seems to be missing an addition to EXTRA_DIST. Once you've fixed
> that feel free to push this yourself.

Will fix it.

> Also, I assume you've got missing bits, like those for suspending and
> resuming streams planned for later patches?

It seems this is handled by upper layer, we just have to make sure the
events are propagated by using the audia state notification, anyway if
we latter find out it is still necessary to synchronize via Audio IPC
we can extend the IPC with some extra bits like you said.


-- 
Luiz Augusto von Dentz

^ permalink raw reply

* Re: [PATCH] android/bluetooth: Add support for getting remote device UUIDs property
From: Johan Hedberg @ 2013-12-13 14:54 UTC (permalink / raw)
  To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <1386944441-785-1-git-send-email-szymon.janc@tieto.com>

Hi Szymon,

On Fri, Dec 13, 2013, Szymon Janc wrote:
> This allows to query for remote device UUIDs property.
> ---
>  android/bluetooth.c | 91 ++++++++++++++++++++++++++---------------------------
>  1 file changed, 45 insertions(+), 46 deletions(-)

Applied. Thanks.

Johan

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox