connect fails with 'org.bluez.Error.NotAvailable'

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

Hi Tobias,

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

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

Hi Tobias,

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

I see. Any idea how to isolate where the NotAvailable error origins from?

With best wishes,
Tobias

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

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

From: Tobias Jakobi <[email protected]>
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(+)

index 0fe98a0..9b501a3 100644
@@ -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

Hi Tobias,

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