* [bluez-5.14] connect fails with 'org.bluez.Error.NotAvailable' @ 2014-02-27 22:25 Tobias Jakobi 2014-02-28 12:16 ` Anderson Lizardo 0 siblings, 1 reply; 8+ messages in thread From: Tobias Jakobi @ 2014-02-27 22:25 UTC (permalink / raw) To: linux-bluetooth 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bluez-5.14] connect fails with 'org.bluez.Error.NotAvailable' 2014-02-27 22:25 [bluez-5.14] connect fails with 'org.bluez.Error.NotAvailable' Tobias Jakobi @ 2014-02-28 12:16 ` Anderson Lizardo 2014-02-28 16:57 ` Tobias Jakobi 0 siblings, 1 reply; 8+ messages in thread From: Anderson Lizardo @ 2014-02-28 12:16 UTC (permalink / raw) To: Tobias Jakobi; +Cc: BlueZ development 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bluez-5.14] connect fails with 'org.bluez.Error.NotAvailable' 2014-02-28 12:16 ` Anderson Lizardo @ 2014-02-28 16:57 ` Tobias Jakobi 2014-02-28 17:11 ` Anderson Lizardo 0 siblings, 1 reply; 8+ messages in thread From: Tobias Jakobi @ 2014-02-28 16:57 UTC (permalink / raw) To: Anderson Lizardo; +Cc: BlueZ development 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bluez-5.14] connect fails with 'org.bluez.Error.NotAvailable' 2014-02-28 16:57 ` Tobias Jakobi @ 2014-02-28 17:11 ` Anderson Lizardo 2014-03-02 18:54 ` Tobias Jakobi 0 siblings, 1 reply; 8+ messages in thread From: Anderson Lizardo @ 2014-02-28 17:11 UTC (permalink / raw) To: Tobias Jakobi; +Cc: BlueZ development 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bluez-5.14] connect fails with 'org.bluez.Error.NotAvailable' 2014-02-28 17:11 ` Anderson Lizardo @ 2014-03-02 18:54 ` Tobias Jakobi 2014-04-06 15:59 ` Tobias Jakobi 0 siblings, 1 reply; 8+ messages in thread From: Tobias Jakobi @ 2014-03-02 18:54 UTC (permalink / raw) To: Anderson Lizardo; +Cc: BlueZ development 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bluez-5.14] connect fails with 'org.bluez.Error.NotAvailable' 2014-03-02 18:54 ` Tobias Jakobi @ 2014-04-06 15:59 ` Tobias Jakobi 2014-04-06 22:24 ` Tobias Jakobi 0 siblings, 1 reply; 8+ messages in thread From: Tobias Jakobi @ 2014-04-06 15:59 UTC (permalink / raw) To: Anderson Lizardo; +Cc: BlueZ development 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bluez-5.14] connect fails with 'org.bluez.Error.NotAvailable' 2014-04-06 15:59 ` Tobias Jakobi @ 2014-04-06 22:24 ` Tobias Jakobi 2014-04-07 7:45 ` Johan Hedberg 0 siblings, 1 reply; 8+ messages in thread From: Tobias Jakobi @ 2014-04-06 22:24 UTC (permalink / raw) To: Anderson Lizardo; +Cc: BlueZ development [-- 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 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [bluez-5.14] connect fails with 'org.bluez.Error.NotAvailable' 2014-04-06 22:24 ` Tobias Jakobi @ 2014-04-07 7:45 ` Johan Hedberg 0 siblings, 0 replies; 8+ messages in thread From: Johan Hedberg @ 2014-04-07 7:45 UTC (permalink / raw) To: Tobias Jakobi; +Cc: Anderson Lizardo, BlueZ development 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-04-07 7:45 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-02-27 22:25 [bluez-5.14] connect fails with 'org.bluez.Error.NotAvailable' Tobias Jakobi 2014-02-28 12:16 ` Anderson Lizardo 2014-02-28 16:57 ` Tobias Jakobi 2014-02-28 17:11 ` Anderson Lizardo 2014-03-02 18:54 ` Tobias Jakobi 2014-04-06 15:59 ` Tobias Jakobi 2014-04-06 22:24 ` Tobias Jakobi 2014-04-07 7:45 ` Johan Hedberg
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.