[bluez-5.14] connect fails with 'org.bluez.Error.NotAvailable'

[bluez-5.14] connect fails with 'org.bluez.Error.NotAvailable'

[Tobias Jakobi]

Hello,

I'm trying to establish a BT connection between two systems. The client
is running bluez-5.14 and I'm using bluetoothctl to interface with the
daemon.

The server system provides a NAP, plus dnsmasq, so that connecting
clients receive an IP. For reference, this works perfectly on an Android
smartphone. When connecting to the server system, the bnep device is
created on the server and added to the bridge. The Android bluetooth
stack then gets an IP via dnsmasq and voila... TCP/IP connection.

On this client however, this doesn't work at all. Plus, I'm not getting
any kind of meaningful error message.

That's the server:
[bluetooth]# info 00:02:72:C6:43:11
Device 00:02:72:C6:43:11
	Name: chidori-bt
	Alias: chidori-bt
	Class: 0x020000
	Paired: yes
	Trusted: yes
	Blocked: no
	Connected: no
	LegacyPairing: no
	UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
	UUID: A/V Remote Control        (0000110e-0000-1000-8000-00805f9b34fb)
	UUID: NAP                       (00001116-0000-1000-8000-00805f9b34fb)
	UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
	UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
	UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
	Modalias: usb:v1D6Bp0246d0509


And here's how connecting goes:
[bluetooth]# connect 00:02:72:C6:43:11
Attempting to connect to 00:02:72:C6:43:11
[CHG] Device 00:02:72:C6:43:11 Connected: yes
[CHG] Device 00:02:72:C6:43:11 Modalias: usb:v1D6Bp0246d0509
Failed to connect: org.bluez.Error.NotAvailable
[CHG] Device 00:02:72:C6:43:11 Connected: no

So, it looks like that it briefly connect, but then drops the connection
again. I haven't been able to figure out what exaclty is 'NotAvailable'
at this moment. The server at least is.


This is something from the bt daemon (client):
leena bluetoothd[26910]: Bluetooth daemon 5.14
leena bluetoothd[26910]: Starting SDP server
leena bluetoothd[26910]: Bluetooth management interface 1.3 initialized
leena bluetoothd[26910]: Sap driver initialization failed.
leena bluetoothd[26910]: sap-server: Operation not permitted (1)
leena bluetoothd[26910]: Can't add /org/bluez/hci0/dev_00_02_72_C6_43_11
to non-LE capable adapter connect list

I'm not sure if the 'non-LE' message has something to do with the issue.

Any idea on how to proceed here?

Greets,
Tobias

PS: More info:
[bluetooth]# show
Controller B4:82:FE:65:22:8E
	Name: leena-bt
	Alias: leena-bt
	Class: 0x00010c
	Powered: yes
	Discoverable: no
	Pairable: yes
	UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
	UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
	UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
	UUID: A/V Remote Control        (0000110e-0000-1000-8000-00805f9b34fb)
	UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
	Modalias: usb:v1D6Bp0246d050E
	Discovering: no

Re: [bluez-5.14] connect fails with 'org.bluez.Error.NotAvailable'

[Anderson Lizardo]

Hi Tobias,

On Thu, Feb 27, 2014 at 6:25 PM, Tobias Jakobi <liquid.acid@gmx.net> wrote:
> That's the server:
> [bluetooth]# info 00:02:72:C6:43:11
> Device 00:02:72:C6:43:11
>         Name: chidori-bt
>         Alias: chidori-bt
>         Class: 0x020000
>         Paired: yes
>         Trusted: yes
>         Blocked: no
>         Connected: no
>         LegacyPairing: no
>         UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
>         UUID: A/V Remote Control        (0000110e-0000-1000-8000-00805f9b34fb)
>         UUID: NAP                       (00001116-0000-1000-8000-00805f9b34fb)
>         UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
>         UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
>         UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
>         Modalias: usb:v1D6Bp0246d0509

Looks like you are missing a "power on" on the server side. Notice
that the client side shows "Powered: yes" on the info command.

Best Regards,
-- 
Anderson Lizardo
http://www.indt.org/?lang=en
INdT - Manaus - Brazil

Re: [bluez-5.14] connect fails with 'org.bluez.Error.NotAvailable'

[Tobias Jakobi]

Anderson Lizardo wrote:
> Looks like you are missing a "power on" on the server side. Notice
> that the client side shows "Powered: yes" on the info command.
> 
> Best Regards,
> 
Hello Anderson!

Sadly this doesn't solve the issue. The BT device on the server side is
already powered on. Otherwise I wouldn't be able to establish the
connection with the Android smartphone in the first place.

With best wishes,
Tobias

Re: [bluez-5.14] connect fails with 'org.bluez.Error.NotAvailable'

[Anderson Lizardo]

Hi Tobias,

On Fri, Feb 28, 2014 at 12:57 PM, Tobias Jakobi <liquid.acid@gmx.net> wrote:
> Anderson Lizardo wrote:
>> Looks like you are missing a "power on" on the server side. Notice
>> that the client side shows "Powered: yes" on the info command.
>>
>> Best Regards,
>>
> Hello Anderson!
>
> Sadly this doesn't solve the issue. The BT device on the server side is
> already powered on. Otherwise I wouldn't be able to establish the
> connection with the Android smartphone in the first place.

I misunderstood the first output, it was actually the "info" command
for the server from the client side. I thought it was the "show"
command on the server side. That explains the missing "Powered"
property :)

-- 
Anderson Lizardo
http://www.indt.org/?lang=en
INdT - Manaus - Brazil

Re: [bluez-5.14] connect fails with 'org.bluez.Error.NotAvailable'

[Tobias Jakobi]

Anderson Lizardo wrote:
> I misunderstood the first output, it was actually the "info" command
> for the server from the client side. I thought it was the "show"
> command on the server side. That explains the missing "Powered"
> property :)
> 
I see. Any idea how to isolate where the NotAvailable error origins from?

With best wishes,
Tobias

Re: [bluez-5.14] connect fails with 'org.bluez.Error.NotAvailable'

[Tobias Jakobi]

Tobias Jakobi wrote:
> Anderson Lizardo wrote:
>> I misunderstood the first output, it was actually the "info" command
>> for the server from the client side. I thought it was the "show"
>> command on the server side. That explains the missing "Powered"
>> property :)
>>
> I see. Any idea how to isolate where the NotAvailable error origins from?
> 
> With best wishes,
> Tobias
> 
> --
> 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
> 

Just a small note that I updated the bluez stacks (both on the server
and the client) to 5.17. However the issue remains.

I've also created log from the debug output of bluetoothd on both sides:
http://www.math.uni-bielefeld.de/~tjakobi/bt-client.log
http://www.math.uni-bielefeld.de/~tjakobi/bt-server.log

Has anyone here actually managed to get a working TCP/IP network with
recent bluez stack?

Greets,
Tobias

Re: [bluez-5.14] connect fails with 'org.bluez.Error.NotAvailable'

[Tobias Jakobi]

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

Tobias Jakobi wrote:
> Just a small note that I updated the bluez stacks (both on the server
> and the client) to 5.17. However the issue remains.
> 
> I've also created log from the debug output of bluetoothd on both sides:
> http://www.math.uni-bielefeld.de/~tjakobi/bt-client.log
> http://www.math.uni-bielefeld.de/~tjakobi/bt-server.log
> 
> Has anyone here actually managed to get a working TCP/IP network with
> recent bluez stack?
> 
> Greets,
> Tobias
> 
> --
> 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
> 

I think I isolated the issue. The problem is that the profiles that are
associated to the NAP, PANU and GN services haven't got the auto_connect
flag set.

So during connect_profiles() they're never considered, and there is no
way to change this via the cmdline tools. Which effectively disables
this functionality.

Maybe the DBus interface can change these setting for built-in profiles,
but you honestly can't expect the enduser to fiddle around with that.

I attached a patch which enables autoconnect for all the above services.
This finally establishes the TCP/IP connection for me.

Greets,
Tobias


[-- Attachment #2: 0001-network-enable-autoconnect-for-NAP-PANU-and-GN.patch --]
[-- Type: text/x-patch, Size: 1311 bytes --]

>From 25f98aa8bbce7763fc68402c7aeedf90f431e7de Mon Sep 17 00:00:00 2001
From: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Date: Sun, 6 Apr 2014 23:58:32 +0200
Subject: network: enable autoconnect for NAP, PANU and GN

---
 profiles/network/manager.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/profiles/network/manager.c b/profiles/network/manager.c
index 0fe98a0..9b501a3 100644
--- a/profiles/network/manager.c
+++ b/profiles/network/manager.c
@@ -137,6 +137,7 @@ static struct btd_profile panu_profile = {
 	.name		= "network-panu",
 	.local_uuid	= NAP_UUID,
 	.remote_uuid	= PANU_UUID,
+	.auto_connect	= true,
 	.device_probe	= connection_register,
 	.device_remove	= connection_unregister,
 	.connect	= connection_connect,
@@ -149,6 +150,7 @@ static struct btd_profile gn_profile = {
 	.name		= "network-gn",
 	.local_uuid	= PANU_UUID,
 	.remote_uuid	= GN_UUID,
+	.auto_connect	= true,
 	.device_probe	= connection_register,
 	.device_remove	= connection_unregister,
 	.connect	= connection_connect,
@@ -161,6 +163,7 @@ static struct btd_profile nap_profile = {
 	.name		= "network-nap",
 	.local_uuid	= PANU_UUID,
 	.remote_uuid	= NAP_UUID,
+	.auto_connect	= true,
 	.device_probe	= connection_register,
 	.device_remove	= connection_unregister,
 	.connect	= connection_connect,
-- 
1.8.3.2

Re: [bluez-5.14] connect fails with 'org.bluez.Error.NotAvailable'

[Johan Hedberg]

Hi Tobias,

On Mon, Apr 07, 2014, Tobias Jakobi wrote:
> I think I isolated the issue. The problem is that the profiles that are
> associated to the NAP, PANU and GN services haven't got the auto_connect
> flag set.
> 
> So during connect_profiles() they're never considered, and there is no
> way to change this via the cmdline tools. Which effectively disables
> this functionality.
> 
> Maybe the DBus interface can change these setting for built-in profiles,
> but you honestly can't expect the enduser to fiddle around with that.

There is actually another D-Bus method that can be used to connect any
profile, regardless of the auto_connect value: Device1.ConnectProfile().

The test-device script already supports it by doing something like
"test-device connect <addr> nap" instead of "test-device connect <addr>".
I think it might be a good idea to extend bluetoothctl to support the
same.

Johan