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,
On Fri, Feb 28, 2014 at 12:57 PM, Tobias Jakobi <[email protected]> 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
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
Hi Tobias,
On Thu, Feb 27, 2014 at 6:25 PM, Tobias Jakobi <[email protected]> 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
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
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
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 [email protected]
> 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
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 [email protected]
> 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