* Serial Port connection with DBus API
From: Barry Byford @ 2017-04-07 13:47 UTC (permalink / raw)
To: Bluez mailing list
Hello,
I am trying to create a serial port server that can be connected to by
an already existing Android app.
The app is trying connect on channel 1. I am taking the
test/test-profile example as my starting point.
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/test/test-profile?h=5.43
My code is far from finished but I thought it would be enough to
accept the connection (or at least print that a new connection attempt
had happened.) However I am getting an access denied error and I'm
concerned that I'm going down the wrong route on this and it might be
simpler than I am making it.
Error message
$ python3 BTspp.py
Traceback (most recent call last):
File "BTclassic.py", line 54, in <module>
dbus.publish('org.bluez.Profile1', Profile('x', 'y'))
File "/usr/local/lib/python3.5/dist-packages/pydbus/publication.py",
line 42, in publish
return Publication(self, bus_name, *objects)
File "/usr/local/lib/python3.5/dist-packages/pydbus/publication.py",
line 35, in __init__
self._at_exit(bus.request_name(bus_name,
allow_replacement=allow_replacement, replace=replace).__exit__)
File "/usr/local/lib/python3.5/dist-packages/pydbus/request_name.py",
line 29, in request_name
return NameOwner(self, name, allow_replacement, replace)
File "/usr/local/lib/python3.5/dist-packages/pydbus/request_name.py",
line 8, in __init__
res = bus.dbus.RequestName(name, flags)
File "/usr/local/lib/python3.5/dist-packages/pydbus/proxy_method.py",
line 75, in __call__
0, timeout_to_glib(timeout), None).unpack()
GLib.Error: g-dbus-error-quark:
GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Connection
":1.47" is not allowed to own the service "org.bluez.Profile1" due to
security policies in the configuration file (9
Python code so far:
from pydbus import SystemBus
from gi.repository import GLib
loop = GLib.MainLoop()
dbus = SystemBus()
class Profile(object):
"""
<node>
<interface name='org.bluez.Profile1'>
<method name='Release'>
</method>
<method name='Cancel'>
</method>
<method name='NewConnection'>
<arg type='o' name='path' direction='in'/>
<arg type='h' name='fd' direction='in'/>
<arg type='a{sv}' name='properties' direction='in'/>
</method>
<method name='RequestDisconnection'>
<arg type='o' name='path' direction='in'/>
</method>
</interface>
</node>
"""
def __init__(self, x, y):
pass
def Release(self):
pass
def Cancel(self):
pass
def NewConnection(self, path, fd, properties):
print('New connection', path, fd, properties)
def RequestDisconnection(self, path):
pass
if __name__ == '__main__':
profile_mngr = dbus.get('org.bluez', '/org/bluez')
uuid = "00001101-0000-1000-8000-00805f9b34fb"
opts = {
"AutoConnect": GLib.Variant('b', True),
'Channel': GLib.Variant('i', 1),
'Service': GLib.Variant('s', uuid),
'Name': GLib.Variant('s', 'Serial Port')
}
# my_profile = Profile(dbus, '/org/bluez/example')
dbus.publish('org.bluez.Profile1', Profile('x', 'y'))
profile_mngr.RegisterProfile('/foo/bar/profile', uuid, opts)
loop.run()
Is there a simpler way of doing this?
Thanks,
Barry
^ permalink raw reply
* Fw: [Bug 195269] New: Bluetooth - 6lowpan -- RFC7668 vs. draft - IPv6 addressing
From: Stephen Hemminger @ 2017-04-06 21:19 UTC (permalink / raw)
To: marcel, gustavo, johan.hedberg; +Cc: linux-bluetooth
Any bugzilla entries networking related ends up (forwarding to MAINTAINERS)
Begin forwarded message:
Date: Thu, 06 Apr 2017 11:37:40 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 195269] New: Bluetooth - 6lowpan -- RFC7668 vs. draft - IPv6 addressing
https://bugzilla.kernel.org/show_bug.cgi?id=195269
Bug ID: 195269
Summary: Bluetooth - 6lowpan -- RFC7668 vs. draft - IPv6
addressing
Product: Networking
Version: 2.5
Kernel Version: 4.9.0-2-amd64 (Debian)
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
Assignee: stephen@networkplumber.org
Reporter: aignerb@technikum-wien.at
Regression: No
Dear all,
my first bug report (hopefully :-)) for the Kernel ^^
Citing 6lowpan.c:675:
/* Universal/local bit set, BT 6lowpan draft ch. 3.2.1 */
If the address is identified as a public address, the original address byte
get's a set bit at 2^1.
Otherwise, it will be deleted.
so far, so good. That works well, BUT:
the current RFC7668 does NOT state anything like that. Neither in ch. 3.2.1 or
any other chapters I looked through.
Please tell me, am I wrong or is this a non-conform implementation?
Anyway, thank you very much for this rock-stable piece of software :-)
Best wishes, Benjamin
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: Regression in bluez 5.44, bluetoothd crashes
From: Luiz Augusto von Dentz @ 2017-04-06 20:46 UTC (permalink / raw)
To: Konrad Zapalowicz; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <20170406125150.GF12069@annapurna>
Hi Konrad,
On Thu, Apr 6, 2017 at 3:51 PM, Konrad Zapalowicz
<konrad.zapalowicz@canonical.com> wrote:
> Hey,
>
> I see a regression in 5.44 when testing Sony SBH52 headset. It fails to
> connect profiles but the worst thing is that the bluetoothd crashes
> (logs below).
>
> I have git bisect'ed it down to the commit f2483bbfd. It works fine if
> I remove it.
That is because the very next patch fix it:
commit 4a8c33b1f76edf2dfe33b9956014cc2746ae71d8
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Mon Nov 14 13:30:09 2016 +0200
core/adapter: Fix using wrong address type to listen ATT
bdaddr_type shall only matter for controllers supporting LE otherwise
it may cause BDADDR_BREDR to be used for things like LE ATT socket
listen breaking reconnections.
> Stacktrace:
>
> (gdb) c
> Continuing.
>
> Program received signal SIGSEGV, Segmentation fault.
> strlen () at ../sysdeps/x86_64/strlen.S:106
> 106 ../sysdeps/x86_64/strlen.S: No such file or directory.
> (gdb) bt
> #0 strlen () at ../sysdeps/x86_64/strlen.S:106
> #1 0x00007f92806179a1 in _IO_vfprintf_internal (s=s@entry=0x557f37ad5520, format=<optimized out>, format@entry=0x557f36cd515c "%s:%s() %s err %d", ap=0x7ffc0b7a86d0)
> at vfprintf.c:1637
> #2 0x00007f92806dffc6 in ___vfprintf_chk (fp=fp@entry=0x557f37ad5520, flag=flag@entry=1, format=format@entry=0x557f36cd515c "%s:%s() %s err %d",
> ap=ap@entry=0x7ffc0b7a86d0) at vfprintf_chk.c:33
> #3 0x00007f92806c9028 in __GI___vsyslog_chk (pri=<optimized out>, pri@entry=7, flag=flag@entry=1, fmt=fmt@entry=0x557f36cd515c "%s:%s() %s err %d",
> ap=ap@entry=0x7ffc0b7a86d0) at ../misc/syslog.c:222
> #4 0x0000557f36c6735b in vsyslog (__ap=0x7ffc0b7a86d0, __fmt=0x557f36cd515c "%s:%s() %s err %d", __pri=7) at /usr/include/x86_64-linux-gnu/bits/syslog.h:47
> #5 btd_debug (index=index@entry=65535, format=format@entry=0x557f36cd515c "%s:%s() %s err %d") at src/log.c:252
> #6 0x0000557f36c94d88 in device_svc_resolved (dev=0x557f36c90e60 <browse_request_exit>, bdaddr_type=0 '\000', err=-111) at src/device.c:2214
> #7 0x0000557f36c97adb in search_cb (user_data=<optimized out>, err=-111, recs=<optimized out>) at src/device.c:4516
> #8 browse_cb (recs=<optimized out>, err=-111, user_data=<optimized out>) at src/device.c:4549
> #9 0x0000557f36c73551 in connect_watch (chan=0x557f37ae0350, cond=<optimized out>, user_data=0x557f37ae0060) at src/sdp-client.c:286
> #10 0x00007f928124f6ea in g_main_context_dispatch () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
> #11 0x00007f928124faa0 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
> #12 0x00007f928124fdc2 in g_main_loop_run () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
> #13 0x0000557f36c353cc in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:708
> (gdb)
Ok, so this seem to be SDP causing and error, 111 connection refused.
> Syslog:
>
> bluetoothd: src/device.c:bonding_request_new() Requesting bonding for 68:76:4F:6C:31:E9
> bluetoothd: src/agent.c:agent_ref() 0x557f37ae5120: ref=3
> bluetoothd: src/agent.c:agent_unref() 0x557f37ae5120: ref=2
> bluetoothd: src/adapter.c:suspend_discovery()
> bluetoothd: src/adapter.c:adapter_bonding_attempt() hci0 bdaddr 68:76:4F:6C:31:E9 type 0 io_cap 0x01
> bluetoothd: src/adapter.c:add_whitelist_complete() 68:76:4F:6C:31:E9 added to kernel whitelist
> bluetoothd: src/adapter.c:connected_callback() hci0 device 68:76:4F:6C:31:E9 connected eir_len 12
> bluetoothd: src/adapter.c:new_link_key_callback() hci0 new key for 68:76:4F:6C:31:E9 type 4 pin_len 0 store_hint 1
> bluetoothd: src/device.c:device_set_bonded()
> bluetoothd: src/device.c:device_bonding_complete() bonding 0x557f37acc860 status 0x00
> bluetoothd: src/device.c:device_bonding_complete() Proceeding with service discovery
> bluetoothd: src/agent.c:agent_unref() 0x557f37ae5120: ref=1
> bluetoothd: src/adapter.c:resume_discovery()
> bluetoothd: src/adapter.c:pair_device_complete() Success (0x00)
> bluetoothd: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 68:76:4F:6C:31:E9 type 0 status 0x0
> bluetoothd: src/device.c:device_bonding_complete() bonding (nil) status 0x00
> bluetoothd: src/adapter.c:resume_discovery()
> bluetoothd: src/gatt-database.c:connect_cb() New incoming BR/EDR ATT connection
> bluetoothd: attrib/gattrib.c:g_attrib_ref() 0x557f37ae4b40: g_attrib_ref=1
> bluetoothd: src/device.c:load_gatt_db() Restoring 68:76:4F:6C:31:E9 gatt database from file
> bluetoothd: No cache for 68:76:4F:6C:31:E9
> bluetoothd: src/gatt-client.c:btd_gatt_client_connected() Device connected.
> bluetoothd: src/adapter.c:dev_disconnected() Device 68:76:4F:6C:31:E9 disconnected, reason 3
> bluetoothd: src/adapter.c:adapter_remove_connection()
> bluetoothd: plugins/policy.c:disconnect_cb() reason 3
> bluetoothd: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 68:76:4F:6C:31:E9 type 0 status 0xe
> bluetoothd: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
> bluetoothd: src/device.c:device_bonding_failed() status 14
> bluetoothd: src/adapter.c:resume_discovery()
> bluetoothd: src/device.c:gatt_debug() Primary service discovery failed. ATT ECODE: 0x00
> bluetoothd: src/device.c:gatt_debug() Failed to initialize gatt-client
> bluetoothd: src/device.c:gatt_client_ready_cb() status: failed, error: 0
> bluetoothd: src/device.c:device_svc_resolved() /org/bluez/hci0/dev_68_76_4F_6C_31_E9 err -5
> bluetoothd: src/device.c:att_disconnected_cb()
> bluetoothd: src/device.c:att_disconnected_cb() Connection reset by peer (104)
> bluetoothd: src/gatt-client.c:btd_gatt_client_disconnected() Device disconnected. Cleaning up.
> bluetoothd: src/device.c:att_disconnected_cb() Automatic connection disabled
> bluetoothd: attrib/gattrib.c:g_attrib_unref() 0x557f37ae4b40: g_attrib_unref=0
> bluetoothd: src/device.c:btd_device_set_trusted() trusted 1
> bluetoothd: src/device.c:connect_profiles() /org/bluez/hci0/dev_68_76_4F_6C_31_E9 (all), client :1.256
> bluetoothd: src/device.c:connect_profiles() Resolving services for /org/bluez/hci0/dev_68_76_4F_6C_31_E9
> bluetoothd: src/gatt-database.c:connect_cb() New incoming BR/EDR ATT connection
> bluetoothd: attrib/gattrib.c:g_attrib_ref() 0x557f37ae4b40: g_attrib_ref=1
> bluetoothd: src/device.c:load_gatt_db() Restoring 68:76:4F:6C:31:E9 gatt database from file
> bluetoothd: No cache for 68:76:4F:6C:31:E9
> bluetoothd: src/gatt-client.c:btd_gatt_client_connected() Device connected.
> bluetoothd: 89:48:53:01:00:27: error updating services: Connection refused (111)
Interesting, the device is connecting ATT over BR/EDR which is weird
if that is a headset, and we can see the 111, though the address
printed seems wrong, I wonder if that is why it crashes.
> There is one interestig thing that I have noticed examining the the
> btmon output. The bluez is repeatedly (literally till the end) sending
> the Information Request (Extended Feature Mask) and the headset is
> answering Not Supported. For the same headset bluez 5.43 sends this
> request only once. The bluez 5.44 works fine with a Phillips headset
> that answers Success to this knd of Information Response.
Well this is the information request is sent by the kernel, so if you
haven't change it between versions that should not change between
daemon versions, but ATT is not a fixed channel on BR/EDR so I wonder
if the information request is actually sent because ATT is being
connected.
> Additionaly to Information Request (Ext Feature Mask) bluez 5.44 keeps
> repeating ATT Read By Group Type Request, GATT Primary Service
> Declaration which in case of Phillips device happens only once. Bluez
> 5.43 does not send it whatsoever.
I suspect it doesn't even connect over ATT in 5.43, anyway that should
only happen once but I can see from the logs that it fails and
disconnects and then connects again.
> Let me know if I can in any way help debugging this issue further.
>
> Thanks,
> Konrad
> --
> 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
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH] monitor: Add support for decoding LE Channel Selection Algorithm Event
From: Szymon Janc @ 2017-04-06 13:41 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
> HCI Event: LE Meta Event (0x3e) plen 4 44.589780
LE Channel Selection Algorithm (0x14)
Handle: 1
LE Channel Selection Algorithm #2 (0x01)
---
monitor/bt.h | 6 ++++++
monitor/packet.c | 30 +++++++++++++++++++++++++++++-
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/monitor/bt.h b/monitor/bt.h
index 1a21592..0b77a10 100644
--- a/monitor/bt.h
+++ b/monitor/bt.h
@@ -2736,6 +2736,12 @@ struct bt_hci_evt_le_direct_adv_report {
int8_t rssi;
} __attribute__ ((packed));
+#define BT_HCI_EVT_LE_CHAN_SELECT_ALG 0x14
+struct bt_hci_evt_le_chan_select_alg {
+ uint16_t handle;
+ uint8_t algorithm;
+} __attribute__ ((packed));
+
#define BT_HCI_ERR_SUCCESS 0x00
#define BT_HCI_ERR_UNKNOWN_COMMAND 0x01
#define BT_HCI_ERR_UNKNOWN_CONN_ID 0x02
diff --git a/monitor/packet.c b/monitor/packet.c
index 0cae6d7..5d927f5 100644
--- a/monitor/packet.c
+++ b/monitor/packet.c
@@ -3754,6 +3754,25 @@ static void print_3d_broadcast(const void *data, uint8_t size)
period, period_frac);
}
+static void print_le_channel_select_alg(uint8_t alg)
+{
+ const char *str;
+
+ switch (alg) {
+ case 0x00:
+ str = "LE Channel Selection Algorithm #1";
+ break;
+ case 0x01:
+ str = "LE Channel Selection Algorithm #2";
+ break;
+ default:
+ str = "Reserved";
+ break;
+ }
+
+ print_field("%s (0x%2.2x)", str, alg);
+}
+
void packet_hexdump(const unsigned char *buf, uint16_t len)
{
static const char hexdigits[] = "0123456789abcdef";
@@ -8531,6 +8550,14 @@ static void le_direct_adv_report_evt(const void *data, uint8_t size)
packet_hexdump(data + sizeof(*evt), size - sizeof(*evt));
}
+static void le_chan_select_alg_evt(const void *data, uint8_t size)
+{
+ const struct bt_hci_evt_le_chan_select_alg *evt = data;
+
+ print_handle(evt->handle);
+ print_le_channel_select_alg(evt->algorithm);
+}
+
struct subevent_data {
uint8_t subevent;
const char *str;
@@ -8605,7 +8632,8 @@ static const struct subevent_data le_meta_event_table[] = {
{ 0x11, "LE Scan Timeout" },
{ 0x12, "LE Advertising Set Terminated" },
{ 0x13, "LE Scan Request Received" },
- { 0x14, "LE Channel Selection Algorithm" },
+ { 0x14, "LE Channel Selection Algorithm",
+ le_chan_select_alg_evt, 3, true},
{ }
};
--
2.9.3
^ permalink raw reply related
* Regression in bluez 5.44, bluetoothd crashes
From: Konrad Zapalowicz @ 2017-04-06 12:51 UTC (permalink / raw)
To: linux-bluetooth
Hey,
I see a regression in 5.44 when testing Sony SBH52 headset. It fails to
connect profiles but the worst thing is that the bluetoothd crashes
(logs below).
I have git bisect'ed it down to the commit f2483bbfd. It works fine if
I remove it.
Stacktrace:
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) bt
#0 strlen () at ../sysdeps/x86_64/strlen.S:106
#1 0x00007f92806179a1 in _IO_vfprintf_internal (s=s@entry=0x557f37ad5520, format=<optimized out>, format@entry=0x557f36cd515c "%s:%s() %s err %d", ap=0x7ffc0b7a86d0)
at vfprintf.c:1637
#2 0x00007f92806dffc6 in ___vfprintf_chk (fp=fp@entry=0x557f37ad5520, flag=flag@entry=1, format=format@entry=0x557f36cd515c "%s:%s() %s err %d",
ap=ap@entry=0x7ffc0b7a86d0) at vfprintf_chk.c:33
#3 0x00007f92806c9028 in __GI___vsyslog_chk (pri=<optimized out>, pri@entry=7, flag=flag@entry=1, fmt=fmt@entry=0x557f36cd515c "%s:%s() %s err %d",
ap=ap@entry=0x7ffc0b7a86d0) at ../misc/syslog.c:222
#4 0x0000557f36c6735b in vsyslog (__ap=0x7ffc0b7a86d0, __fmt=0x557f36cd515c "%s:%s() %s err %d", __pri=7) at /usr/include/x86_64-linux-gnu/bits/syslog.h:47
#5 btd_debug (index=index@entry=65535, format=format@entry=0x557f36cd515c "%s:%s() %s err %d") at src/log.c:252
#6 0x0000557f36c94d88 in device_svc_resolved (dev=0x557f36c90e60 <browse_request_exit>, bdaddr_type=0 '\000', err=-111) at src/device.c:2214
#7 0x0000557f36c97adb in search_cb (user_data=<optimized out>, err=-111, recs=<optimized out>) at src/device.c:4516
#8 browse_cb (recs=<optimized out>, err=-111, user_data=<optimized out>) at src/device.c:4549
#9 0x0000557f36c73551 in connect_watch (chan=0x557f37ae0350, cond=<optimized out>, user_data=0x557f37ae0060) at src/sdp-client.c:286
#10 0x00007f928124f6ea in g_main_context_dispatch () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x00007f928124faa0 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007f928124fdc2 in g_main_loop_run () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x0000557f36c353cc in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:708
(gdb)
Syslog:
bluetoothd: src/device.c:bonding_request_new() Requesting bonding for 68:76:4F:6C:31:E9
bluetoothd: src/agent.c:agent_ref() 0x557f37ae5120: ref=3
bluetoothd: src/agent.c:agent_unref() 0x557f37ae5120: ref=2
bluetoothd: src/adapter.c:suspend_discovery()
bluetoothd: src/adapter.c:adapter_bonding_attempt() hci0 bdaddr 68:76:4F:6C:31:E9 type 0 io_cap 0x01
bluetoothd: src/adapter.c:add_whitelist_complete() 68:76:4F:6C:31:E9 added to kernel whitelist
bluetoothd: src/adapter.c:connected_callback() hci0 device 68:76:4F:6C:31:E9 connected eir_len 12
bluetoothd: src/adapter.c:new_link_key_callback() hci0 new key for 68:76:4F:6C:31:E9 type 4 pin_len 0 store_hint 1
bluetoothd: src/device.c:device_set_bonded()
bluetoothd: src/device.c:device_bonding_complete() bonding 0x557f37acc860 status 0x00
bluetoothd: src/device.c:device_bonding_complete() Proceeding with service discovery
bluetoothd: src/agent.c:agent_unref() 0x557f37ae5120: ref=1
bluetoothd: src/adapter.c:resume_discovery()
bluetoothd: src/adapter.c:pair_device_complete() Success (0x00)
bluetoothd: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 68:76:4F:6C:31:E9 type 0 status 0x0
bluetoothd: src/device.c:device_bonding_complete() bonding (nil) status 0x00
bluetoothd: src/adapter.c:resume_discovery()
bluetoothd: src/gatt-database.c:connect_cb() New incoming BR/EDR ATT connection
bluetoothd: attrib/gattrib.c:g_attrib_ref() 0x557f37ae4b40: g_attrib_ref=1
bluetoothd: src/device.c:load_gatt_db() Restoring 68:76:4F:6C:31:E9 gatt database from file
bluetoothd: No cache for 68:76:4F:6C:31:E9
bluetoothd: src/gatt-client.c:btd_gatt_client_connected() Device connected.
bluetoothd: src/adapter.c:dev_disconnected() Device 68:76:4F:6C:31:E9 disconnected, reason 3
bluetoothd: src/adapter.c:adapter_remove_connection()
bluetoothd: plugins/policy.c:disconnect_cb() reason 3
bluetoothd: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 68:76:4F:6C:31:E9 type 0 status 0xe
bluetoothd: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
bluetoothd: src/device.c:device_bonding_failed() status 14
bluetoothd: src/adapter.c:resume_discovery()
bluetoothd: src/device.c:gatt_debug() Primary service discovery failed. ATT ECODE: 0x00
bluetoothd: src/device.c:gatt_debug() Failed to initialize gatt-client
bluetoothd: src/device.c:gatt_client_ready_cb() status: failed, error: 0
bluetoothd: src/device.c:device_svc_resolved() /org/bluez/hci0/dev_68_76_4F_6C_31_E9 err -5
bluetoothd: src/device.c:att_disconnected_cb()
bluetoothd: src/device.c:att_disconnected_cb() Connection reset by peer (104)
bluetoothd: src/gatt-client.c:btd_gatt_client_disconnected() Device disconnected. Cleaning up.
bluetoothd: src/device.c:att_disconnected_cb() Automatic connection disabled
bluetoothd: attrib/gattrib.c:g_attrib_unref() 0x557f37ae4b40: g_attrib_unref=0
bluetoothd: src/device.c:btd_device_set_trusted() trusted 1
bluetoothd: src/device.c:connect_profiles() /org/bluez/hci0/dev_68_76_4F_6C_31_E9 (all), client :1.256
bluetoothd: src/device.c:connect_profiles() Resolving services for /org/bluez/hci0/dev_68_76_4F_6C_31_E9
bluetoothd: src/gatt-database.c:connect_cb() New incoming BR/EDR ATT connection
bluetoothd: attrib/gattrib.c:g_attrib_ref() 0x557f37ae4b40: g_attrib_ref=1
bluetoothd: src/device.c:load_gatt_db() Restoring 68:76:4F:6C:31:E9 gatt database from file
bluetoothd: No cache for 68:76:4F:6C:31:E9
bluetoothd: src/gatt-client.c:btd_gatt_client_connected() Device connected.
bluetoothd: 89:48:53:01:00:27: error updating services: Connection refused (111)
There is one interestig thing that I have noticed examining the the
btmon output. The bluez is repeatedly (literally till the end) sending
the Information Request (Extended Feature Mask) and the headset is
answering Not Supported. For the same headset bluez 5.43 sends this
request only once. The bluez 5.44 works fine with a Phillips headset
that answers Success to this knd of Information Response.
Additionaly to Information Request (Ext Feature Mask) bluez 5.44 keeps
repeating ATT Read By Group Type Request, GATT Primary Service
Declaration which in case of Phillips device happens only once. Bluez
5.43 does not send it whatsoever.
Let me know if I can in any way help debugging this issue further.
Thanks,
Konrad
^ permalink raw reply
* Re: [RFC V1 00/16] hci_ldisc hci_uart_tty_close() fixes
From: Marcel Holtmann @ 2017-04-06 7:23 UTC (permalink / raw)
To: Dean Jenkins; +Cc: Gustavo F. Padovan, Johan Hedberg, linux-bluetooth
In-Reply-To: <ca51d648-55b9-fca8-d4b4-f19aa637197f@mentor.com>
Hi Dean,
>>> If this is an issue in 4.10, then lets get this fixed / hardened.
>>>
>>
>> If I manage to produce some more useful results then I will post them.
>>
>
> I have now managed to crash the h4 Data Link protocol layer via hci_uart_tty_close().
>
> This confirms that there is a design flaw in hci_uart_tty_close() which is independent of the Bluetooth Data Link protocol layers.
>
> I don't have a Bluetooth Radio Module that uses h4 protocol so I used my BCSP enabled Bluetooth Radio Module that has a USB to serial interface. I realise that this is a weird setup but it is OK for this testcase because we need the h4 protocol to be timing out for transmissions. Also the BCSP Bluetooth Radio Module may send BCSP frames which will exercise the h4 receive path although rejection of the frames should occur which is as expected.
can you send me a patch set with my minor comments addressed. Then I have another look at it.
Regards
Marcel
^ permalink raw reply
* Re: [PATCHv3 00/10] Nokia H4+ support
From: Pavel Machek @ 2017-04-05 20:28 UTC (permalink / raw)
To: Rob Herring
Cc: Greg Kroah-Hartman, Marcel Holtmann, Sebastian Reichel,
Gustavo F. Padovan, Johan Hedberg, Samuel Thibault, Tony Lindgren,
Jiri Slaby, Mark Rutland, open list:BLUETOOTH DRIVERS,
linux-serial@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, David S. Miller
In-Reply-To: <CAL_Jsq+NU3M5yuBpK1UGgzCVvq0eABMApCqEe3_d5+tDaABsgQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1734 bytes --]
On Wed 2017-04-05 13:16:58, Rob Herring wrote:
> On Fri, Mar 31, 2017 at 8:33 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Wed, Mar 29, 2017 at 11:33:26PM +0200, Marcel Holtmann wrote:
> >> Hi Rob,
> >>
> >> >> Here is PATCHv3 for the Nokia bluetooth patchset. I addressed all comments from
> >> >> Rob and Pavel regarding the serdev patches and dropped the *.dts patches, since
> >> >> they were queued by Tony. I also changed the patch order, so that the serdev
> >> >> patches come first. All of them have Acked-by from Rob, so I think it makes
> >> >> sense to merge them to serdev subsystem (now) and provide an immutable branch
> >> >> for the bluetooth subsystem.
> >> >
> >> > Greg doesn't read cover letters generally and since the serdev patches
> >> > are Cc rather than To him, he's probably not planning to pick them up.
> >>
> >> I wonder actually if we should merge all of these via bluetooth-next
> >> tree with proper Ack from Greg. However it would be good to also get
> >> buy in from Dave for merging this ultimately through net-next.
> >
> > I don't really care where it goes. I can take the whole thing in my
> > tty/serial tree now if no one objects and I get an ack from the relevant
> > maintainers {hint...}
>
> I think it is better if it goes thru BT tree. I have another driver
> converted that is dependent on this series. There's a couple other
> serdev changes on the list too, but this shouldn't depend on them.
I believe BT tree makes sense. Still it would be nice to get Greg's
ACK ...?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [PATCH 4/4] arm64: dts: hikey: add WL1835 Bluetooth device node
From: Rob Herring @ 2017-04-05 18:30 UTC (permalink / raw)
To: Marcel Holtmann, linux-bluetooth
Cc: linux-arm-kernel, Gustavo Padovan, Johan Hedberg, Mark Rutland,
Wei Xu, Eyal Reizer, Satish Patel, netdev, devicetree
In-Reply-To: <20170405183005.20570-1-robh@kernel.org>
This adds the serial slave device for the WL1835 Bluetooth interface.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Wei Xu <xuwei5@hisilicon.com>
Cc: Mark Rutland <mark.rutland@arm.com>
---
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index dba3c131c62c..9b4ba7169210 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -98,6 +98,11 @@
assigned-clocks = <&sys_ctrl HI6220_UART1_SRC>;
assigned-clock-rates = <150000000>;
status = "ok";
+
+ bluetooth {
+ compatible = "ti,wl1835-st";
+ enable-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
+ };
};
uart2: uart@f7112000 {
--
2.10.1
^ permalink raw reply related
* [PATCH 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
From: Rob Herring @ 2017-04-05 18:30 UTC (permalink / raw)
To: Marcel Holtmann, linux-bluetooth
Cc: linux-arm-kernel, Gustavo Padovan, Johan Hedberg, Mark Rutland,
Wei Xu, Eyal Reizer, Satish Patel, netdev, devicetree
In-Reply-To: <20170405183005.20570-1-robh@kernel.org>
Turns out that the LL protocol and the TI-ST are the same thing AFAICT.
The TI-ST adds firmware loading, GPIO control, and shared access for
NFC, FM radio, etc. For now, we're only implementing what is needed for
BT. This mirrors other drivers like BCM and Intel, but uses the new
serdev bus.
The firmware loading is greatly simplified by using existing
infrastructure to send commands. It may be a bit slower than the
original code using synchronous functions, but the real bottleneck is
likely doing firmware load at 115.2kbps.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: linux-bluetooth@vger.kernel.org
---
drivers/bluetooth/hci_ll.c | 261 ++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 260 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
index 02692fe30279..9b2054f5502d 100644
--- a/drivers/bluetooth/hci_ll.c
+++ b/drivers/bluetooth/hci_ll.c
@@ -34,20 +34,23 @@
#include <linux/sched.h>
#include <linux/types.h>
#include <linux/fcntl.h>
+#include <linux/firmware.h>
#include <linux/interrupt.h>
#include <linux/ptrace.h>
#include <linux/poll.h>
#include <linux/slab.h>
-#include <linux/tty.h>
#include <linux/errno.h>
#include <linux/string.h>
#include <linux/signal.h>
#include <linux/ioctl.h>
+#include <linux/serdev.h>
#include <linux/skbuff.h>
+#include <linux/ti_wilink_st.h>
#include <net/bluetooth/bluetooth.h>
#include <net/bluetooth/hci_core.h>
+#include <linux/gpio/consumer.h>
#include "hci_uart.h"
@@ -76,6 +79,12 @@ struct hcill_cmd {
u8 cmd;
} __packed;
+struct ll_device {
+ struct hci_uart hu;
+ struct serdev_device *serdev;
+ struct gpio_desc *enable_gpio;
+};
+
struct ll_struct {
unsigned long rx_state;
unsigned long rx_count;
@@ -136,6 +145,9 @@ static int ll_open(struct hci_uart *hu)
hu->priv = ll;
+ if (hu->serdev)
+ serdev_device_open(hu->serdev);
+
return 0;
}
@@ -164,6 +176,13 @@ static int ll_close(struct hci_uart *hu)
kfree_skb(ll->rx_skb);
+ if (hu->serdev) {
+ struct ll_device *lldev = serdev_device_get_drvdata(hu->serdev);
+ gpiod_set_value_cansleep(lldev->enable_gpio, 0);
+
+ serdev_device_close(hu->serdev);
+ }
+
hu->priv = NULL;
kfree(ll);
@@ -505,9 +524,245 @@ static struct sk_buff *ll_dequeue(struct hci_uart *hu)
return skb_dequeue(&ll->txq);
}
+#ifdef CONFIG_SERIAL_DEV_BUS
+static int read_local_version(struct hci_dev *hdev)
+{
+ int err = 0;
+ unsigned short version = 0;
+ struct sk_buff *skb;
+ struct hci_rp_read_local_version *ver;
+
+ skb = __hci_cmd_sync(hdev, HCI_OP_READ_LOCAL_VERSION, 0, NULL, HCI_INIT_TIMEOUT);
+ if (IS_ERR(skb)) {
+ bt_dev_err(hdev, "Reading TI version information failed (%ld)",
+ PTR_ERR(skb));
+ err = PTR_ERR(skb);
+ goto out;
+ }
+ if (skb->len != sizeof(*ver)) {
+ err = -EILSEQ;
+ goto out;
+ }
+
+ ver = (struct hci_rp_read_local_version *)skb->data;
+ if (le16_to_cpu(ver->manufacturer) != 13) {
+ err = -ENODEV;
+ goto out;
+ }
+
+ version = le16_to_cpu(ver->lmp_subver);
+
+out:
+ if (err) bt_dev_err(hdev, "Failed to read TI version info: %d", err);
+ kfree_skb(skb);
+ return err ? err : version;
+}
+
+/**
+ * download_firmware -
+ * internal function which parses through the .bts firmware
+ * script file intreprets SEND, DELAY actions only as of now
+ */
+static int download_firmware(struct ll_device *lldev)
+{
+ unsigned short chip, min_ver, maj_ver;
+ int version, err, len;
+ unsigned char *ptr, *action_ptr;
+ unsigned char bts_scr_name[40]; /* 40 char long bts scr name? */
+ const struct firmware *fw;
+ struct sk_buff *skb;
+ struct hci_command *cmd;
+
+ version = read_local_version(lldev->hu.hdev);
+ if (version < 0)
+ return version;
+
+ chip = (version & 0x7C00) >> 10;
+ min_ver = (version & 0x007F);
+ maj_ver = (version & 0x0380) >> 7;
+ if (version & 0x8000)
+ maj_ver |= 0x0008;
+
+ snprintf(bts_scr_name, sizeof(bts_scr_name),
+ "ti-connectivity/TIInit_%d.%d.%d.bts",
+ chip, maj_ver, min_ver);
+
+ err = request_firmware(&fw, bts_scr_name, &lldev->serdev->dev);
+ if (err || !fw->data || !fw->size) {
+ bt_dev_err(lldev->hu.hdev, "request_firmware failed(errno %d) for %s",
+ err, bts_scr_name);
+ return -EINVAL;
+ }
+ ptr = (void *)fw->data;
+ len = fw->size;
+ /* bts_header to remove out magic number and
+ * version
+ */
+ ptr += sizeof(struct bts_header);
+ len -= sizeof(struct bts_header);
+
+ while (len > 0 && ptr) {
+ bt_dev_dbg(lldev->hu.hdev, " action size %d, type %d ",
+ ((struct bts_action *)ptr)->size,
+ ((struct bts_action *)ptr)->type);
+
+ action_ptr = &(((struct bts_action *)ptr)->data[0]);
+
+ switch (((struct bts_action *)ptr)->type) {
+ case ACTION_SEND_COMMAND: /* action send */
+ bt_dev_dbg(lldev->hu.hdev, "S");
+ cmd = (struct hci_command *)action_ptr;
+ if (cmd->opcode == 0xff36) {
+ /* ignore remote change
+ * baud rate HCI VS command */
+ bt_dev_warn(lldev->hu.hdev, "change remote baud rate command in firmware");
+ break;
+ }
+ if (cmd->prefix != 1)
+ bt_dev_dbg(lldev->hu.hdev, "command type %d\n", cmd->prefix);
+
+ skb = __hci_cmd_sync(lldev->hu.hdev, cmd->opcode, cmd->plen, &cmd->speed, HCI_INIT_TIMEOUT);
+ if (IS_ERR(skb)) {
+ bt_dev_err(lldev->hu.hdev, "send command failed\n");
+ goto out_rel_fw;
+ }
+ kfree_skb(skb);
+ break;
+ case ACTION_WAIT_EVENT: /* wait */
+ /* no need to wait as command was synchronous */
+ bt_dev_dbg(lldev->hu.hdev, "W");
+ break;
+ case ACTION_DELAY: /* sleep */
+ bt_dev_info(lldev->hu.hdev, "sleep command in scr");
+ mdelay(((struct bts_action_delay *)action_ptr)->msec);
+ break;
+ }
+ len -= (sizeof(struct bts_action) +
+ ((struct bts_action *)ptr)->size);
+ ptr += sizeof(struct bts_action) +
+ ((struct bts_action *)ptr)->size;
+ }
+
+out_rel_fw:
+ /* fw download complete */
+ release_firmware(fw);
+ return err;
+}
+
+static int ll_setup(struct hci_uart *hu)
+{
+ int err, retry = 3;
+ struct ll_device *lldev;
+ struct serdev_device *serdev = hu->serdev;
+ u32 speed;
+
+ if (!serdev)
+ return 0;
+
+ lldev = serdev_device_get_drvdata(serdev);
+
+ serdev_device_set_flow_control(serdev, true);
+
+ do {
+ /* Configure BT_EN to HIGH state */
+ gpiod_set_value_cansleep(lldev->enable_gpio, 0);
+ msleep(5);
+ gpiod_set_value_cansleep(lldev->enable_gpio, 1);
+ msleep(100);
+
+ err = download_firmware(lldev);
+ if (!err)
+ break;
+
+ /* Toggle BT_EN and retry */
+ bt_dev_err(hu->hdev, "download firmware failed, retrying...");
+ } while (retry--);
+
+ if (err)
+ return err;
+
+ /* Operational speed if any */
+ if (hu->oper_speed)
+ speed = hu->oper_speed;
+ else if (hu->proto->oper_speed)
+ speed = hu->proto->oper_speed;
+ else
+ speed = 0;
+
+ if (speed) {
+ struct sk_buff *skb = __hci_cmd_sync(hu->hdev, 0xff36, sizeof(speed), &speed, HCI_INIT_TIMEOUT);
+ if (!IS_ERR(skb)) {
+ kfree_skb(skb);
+ serdev_device_set_baudrate(serdev, speed);
+ }
+ }
+
+ return 0;
+}
+
+static const struct hci_uart_proto llp;
+
+static int hci_ti_probe(struct serdev_device *serdev)
+{
+ struct hci_uart *hu;
+ struct ll_device *lldev;
+ u32 max_speed = 3000000;
+
+ lldev = devm_kzalloc(&serdev->dev, sizeof(struct ll_device), GFP_KERNEL);
+ if (!lldev)
+ return -ENOMEM;
+ hu = &lldev->hu;
+
+ serdev_device_set_drvdata(serdev, lldev);
+ lldev->serdev = hu->serdev = serdev;
+
+ lldev->enable_gpio = devm_gpiod_get_optional(&serdev->dev, "enable", GPIOD_OUT_LOW);
+ if (IS_ERR(lldev->enable_gpio))
+ return PTR_ERR(lldev->enable_gpio);
+
+ of_property_read_u32(serdev->dev.of_node, "max-speed", &max_speed);
+ hci_uart_set_speeds(hu, 115200, max_speed);
+
+ return hci_uart_register_device(hu, &llp);
+}
+
+static void hci_ti_remove(struct serdev_device *serdev)
+{
+ struct ll_device *lldev = serdev_device_get_drvdata(serdev);
+ struct hci_uart *hu = &lldev->hu;
+ struct hci_dev *hdev = hu->hdev;
+
+ cancel_work_sync(&hu->write_work);
+
+ hci_unregister_dev(hdev);
+ hci_free_dev(hdev);
+ hu->proto->close(hu);
+}
+
+static const struct of_device_id hci_ti_of_match[] = {
+ { .compatible = "ti,wl1831-st" },
+ { .compatible = "ti,wl1835-st" },
+ { .compatible = "ti,wl1837-st" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, hci_ti_of_match);
+
+static struct serdev_device_driver hci_ti_drv = {
+ .driver = {
+ .name = "hci-ti",
+ .of_match_table = of_match_ptr(hci_ti_of_match),
+ },
+ .probe = hci_ti_probe,
+ .remove = hci_ti_remove,
+};
+#else
+#define ll_setup NULL
+#endif
+
static const struct hci_uart_proto llp = {
.id = HCI_UART_LL,
.name = "LL",
+ .setup = ll_setup,
.open = ll_open,
.close = ll_close,
.recv = ll_recv,
@@ -518,10 +773,14 @@ static const struct hci_uart_proto llp = {
int __init ll_init(void)
{
+ serdev_device_driver_register(&hci_ti_drv);
+
return hci_uart_register_proto(&llp);
}
int __exit ll_deinit(void)
{
+ serdev_device_driver_unregister(&hci_ti_drv);
+
return hci_uart_unregister_proto(&llp);
}
--
2.10.1
^ permalink raw reply related
* [PATCH 2/4] bluetooth: hci_uart: remove unused hci_uart_init_tty
From: Rob Herring @ 2017-04-05 18:30 UTC (permalink / raw)
To: Marcel Holtmann, linux-bluetooth
Cc: linux-arm-kernel, Gustavo Padovan, Johan Hedberg, Mark Rutland,
Wei Xu, Eyal Reizer, Satish Patel, netdev, devicetree
In-Reply-To: <20170405183005.20570-1-robh@kernel.org>
There are no users of hci_uart_init_tty, so remove it.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: linux-bluetooth@vger.kernel.org
---
drivers/bluetooth/hci_ldisc.c | 19 -------------------
drivers/bluetooth/hci_uart.h | 1 -
2 files changed, 20 deletions(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 17bcbc13623f..cec4438ede01 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -319,25 +319,6 @@ void hci_uart_set_speeds(struct hci_uart *hu, unsigned int init_speed,
hu->oper_speed = oper_speed;
}
-void hci_uart_init_tty(struct hci_uart *hu)
-{
- struct tty_struct *tty = hu->tty;
- struct ktermios ktermios;
-
- /* Bring the UART into a known 8 bits no parity hw fc state */
- ktermios = tty->termios;
- ktermios.c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP |
- INLCR | IGNCR | ICRNL | IXON);
- ktermios.c_oflag &= ~OPOST;
- ktermios.c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN);
- ktermios.c_cflag &= ~(CSIZE | PARENB);
- ktermios.c_cflag |= CS8;
- ktermios.c_cflag |= CRTSCTS;
-
- /* tty_set_termios() return not checked as it is always 0 */
- tty_set_termios(tty, &ktermios);
-}
-
void hci_uart_set_baudrate(struct hci_uart *hu, unsigned int speed)
{
struct tty_struct *tty = hu->tty;
diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
index 1b41c661bbb8..2b05e557fad0 100644
--- a/drivers/bluetooth/hci_uart.h
+++ b/drivers/bluetooth/hci_uart.h
@@ -114,7 +114,6 @@ int hci_uart_register_device(struct hci_uart *hu, const struct hci_uart_proto *p
int hci_uart_tx_wakeup(struct hci_uart *hu);
int hci_uart_init_ready(struct hci_uart *hu);
-void hci_uart_init_tty(struct hci_uart *hu);
void hci_uart_set_baudrate(struct hci_uart *hu, unsigned int speed);
void hci_uart_set_flow_control(struct hci_uart *hu, bool enable);
void hci_uart_set_speeds(struct hci_uart *hu, unsigned int init_speed,
--
2.10.1
^ permalink raw reply related
* [PATCH 1/4] dt-bindings: net: Add TI WiLink shared transport binding
From: Rob Herring @ 2017-04-05 18:30 UTC (permalink / raw)
To: Marcel Holtmann, linux-bluetooth
Cc: linux-arm-kernel, Gustavo Padovan, Johan Hedberg, Mark Rutland,
Wei Xu, Eyal Reizer, Satish Patel, netdev, devicetree
In-Reply-To: <20170405183005.20570-1-robh@kernel.org>
Add serial slave device binding for the TI WiLink series of Bluetooth/FM/GPS
devices.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: netdev@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
.../devicetree/bindings/net/ti,wilink-st.txt | 35 ++++++++++++++++++++++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/ti,wilink-st.txt
diff --git a/Documentation/devicetree/bindings/net/ti,wilink-st.txt b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
new file mode 100644
index 000000000000..cbad73a84ac4
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
@@ -0,0 +1,35 @@
+TI WiLink 7/8 (wl12xx/wl18xx) Shared Transport BT/FM/GPS devices
+
+TI WiLink devices have a UART interface for providing Bluetooth, FM radio,
+and GPS over what's called "shared transport". The shared transport is
+standard BT HCI protocol with additional channels for the other functions.
+
+These devices also have a separate WiFi interface as described in
+wireless/ti,wlcore.txt.
+
+This bindings follows the UART slave device binding in
+../serial/slave-device.txt.
+
+Required properties:
+ - compatible: should be one of the following:
+ "ti,wl1271-st"
+ "ti,wl1273-st"
+ "ti,wl1831-st"
+ "ti,wl1835-st"
+ "ti,wl1837-st"
+
+Optional properties:
+ - enable-gpios : GPIO signal controlling enabling of BT. Active high.
+ - vio-supply : Vio input supply (1.8V)
+ - vbat-supply : Vbat input supply (2.9-4.8V)
+
+Example:
+
+&serial0 {
+ compatible = "ns16550a";
+ ...
+ bluetooth {
+ compatible = "ti,wl1835-st";
+ enable-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
+ };
+};
--
2.10.1
^ permalink raw reply related
* [PATCH 0/4] TI Bluetooth serdev support
From: Rob Herring @ 2017-04-05 18:30 UTC (permalink / raw)
To: Marcel Holtmann, linux-bluetooth
Cc: linux-arm-kernel, Gustavo Padovan, Johan Hedberg, Mark Rutland,
Wei Xu, Eyal Reizer, Satish Patel, netdev, devicetree
This series adds serdev support to the HCI LL protocol used on TI BT
modules and enables support on HiKey board with with the WL1835 module.
With this the custom TI UIM daemon and btattach are no longer needed.
The series is available on this git branch[1]. Patch 2 is just clean-up
and can be applied independently. Patch 3 is dependent on the series
"Nokia H4+ support". I'd suggest both series are merged thru the BT tree.
Rob
[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git ti-bluetooth
Rob Herring (4):
dt-bindings: net: Add TI WiLink shared transport binding
bluetooth: hci_uart: remove unused hci_uart_init_tty
bluetooth: hci_uart: add LL protocol serdev driver support
arm64: dts: hikey: add WL1835 Bluetooth device node
.../devicetree/bindings/net/ti,wilink-st.txt | 35 +++
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 5 +
drivers/bluetooth/hci_ldisc.c | 19 --
drivers/bluetooth/hci_ll.c | 261 ++++++++++++++++++++-
drivers/bluetooth/hci_uart.h | 1 -
5 files changed, 300 insertions(+), 21 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/ti,wilink-st.txt
--
2.10.1
^ permalink raw reply
* Re: [PATCHv3 00/10] Nokia H4+ support
From: Rob Herring @ 2017-04-05 18:16 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Marcel Holtmann, Sebastian Reichel, Gustavo F. Padovan,
Johan Hedberg, Samuel Thibault, Pavel Machek, Tony Lindgren,
Jiri Slaby, Mark Rutland, open list:BLUETOOTH DRIVERS,
linux-serial@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, David S. Miller
In-Reply-To: <20170331133353.GA32267@kroah.com>
On Fri, Mar 31, 2017 at 8:33 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Wed, Mar 29, 2017 at 11:33:26PM +0200, Marcel Holtmann wrote:
>> Hi Rob,
>>
>> >> Here is PATCHv3 for the Nokia bluetooth patchset. I addressed all comments from
>> >> Rob and Pavel regarding the serdev patches and dropped the *.dts patches, since
>> >> they were queued by Tony. I also changed the patch order, so that the serdev
>> >> patches come first. All of them have Acked-by from Rob, so I think it makes
>> >> sense to merge them to serdev subsystem (now) and provide an immutable branch
>> >> for the bluetooth subsystem.
>> >
>> > Greg doesn't read cover letters generally and since the serdev patches
>> > are Cc rather than To him, he's probably not planning to pick them up.
>>
>> I wonder actually if we should merge all of these via bluetooth-next
>> tree with proper Ack from Greg. However it would be good to also get
>> buy in from Dave for merging this ultimately through net-next.
>
> I don't really care where it goes. I can take the whole thing in my
> tty/serial tree now if no one objects and I get an ack from the relevant
> maintainers {hint...}
I think it is better if it goes thru BT tree. I have another driver
converted that is dependent on this series. There's a couple other
serdev changes on the list too, but this shouldn't depend on them.
Rob
^ permalink raw reply
* Re: [RFC V1 00/16] hci_ldisc hci_uart_tty_close() fixes
From: Dean Jenkins @ 2017-04-05 15:28 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Gustavo F. Padovan, Johan Hedberg, linux-bluetooth
In-Reply-To: <3662704c-dfd4-67db-a2f9-45c949c45c6c@mentor.com>
[-- Attachment #1: Type: text/plain, Size: 7367 bytes --]
Hi Marcel,
On 04/04/17 21:36, Dean Jenkins wrote:
>
>
> On 03/04/17 16:51, Marcel Holtmann wrote:
>>
>> If this is an issue in 4.10, then lets get this fixed / hardened.
>>
>
> If I manage to produce some more useful results then I will post them.
>
I have now managed to crash the h4 Data Link protocol layer via
hci_uart_tty_close().
This confirms that there is a design flaw in hci_uart_tty_close() which
is independent of the Bluetooth Data Link protocol layers.
I don't have a Bluetooth Radio Module that uses h4 protocol so I used my
BCSP enabled Bluetooth Radio Module that has a USB to serial interface.
I realise that this is a weird setup but it is OK for this testcase
because we need the h4 protocol to be timing out for transmissions. Also
the BCSP Bluetooth Radio Module may send BCSP frames which will exercise
the h4 receive path although rejection of the frames should occur which
is as expected.
Please see the attached tarball v4.10.5.h4_crash.tgz, the contents are:
v4.10.5.h4_crash/
v4.10.5.h4_crash/0001-btattach-Add-option-r-for-sending-HCI-RESET-on-close.patch
v4.10.5.h4_crash/0002-btattach-Fix-raw_device-flag-usage.patch
v4.10.5.h4_crash/0001-Bluetooth-Debug-shows-how-hci_uart_tty_close-is-call.patch
v4.10.5.h4_crash/enable_hci_bt_logging.sh
v4.10.5.h4_crash/btattach_loop_h4.sh
v4.10.5.h4_crash/bt_hci_uart_ldisc_h4_crash_snippet_log.txt
0001-btattach-Add-option-r-for-sending-HCI-RESET-on-close.patch
0002-btattach-Fix-raw_device-flag-usage.patch
These btattach patches add a command line option -r to override
HCI_UART_RESET_ON_INIT so that the kernel HCI UART LDISC component can
use the quirk HCI_QUIRK_RESET_ON_CLOSE. This means hci_uart_tty_close()
is allowed to a send a HCI RESET command during closure of the HCI UART
LDISC which increases the probability of a kernel crash occurring due to
the design flaw in hci_uart_tty_close().
0001-Bluetooth-Debug-shows-how-hci_uart_tty_close-is-call.patch
is a kernel patch for v4.10.5 to add some debug to show when
hci_uart_tty_close() gets called.
enable_hci_bt_logging.sh
Enabled dynamic debug of some Bluetooth files to allow dmesg to show
when the Bluetooth functions run. However, this seems unreliable and the
script needs to be run multiple times to get all the files to log properly.
btattach_loop_h4.sh
is a simple test script, and the content is:
#!/bin/bash
let i=1
while [ true ]
do
echo "loop $i"
./btattach -A /dev/ttyUSB0 -P h4 -r &
sleep 5
echo "now killing..."
killall btattach
i=$(($i + 1))
done
Note that I used my -r option. I suspect I should of used -B option, sigh.
Here is the kernel crash backtrace from
bt_hci_uart_ldisc_h4_crash_snippet_log.txt, it seems easy to reproduce:
[ 563.702430] BUG: unable to handle kernel NULL pointer dereference at
000000000000001c
[ 563.702491] IP: _raw_spin_lock_irqsave+0x22/0x40
[ 563.702520] PGD 13230e067
[ 563.702521] PUD 1238d6067
[ 563.702540] PMD 0
[ 563.704521] Oops: 0002 [#1] SMP
[ 563.706215] Modules linked in: hci_uart btqca nf_log_ipv6
ip6table_nat nf_nat_ipv6 ip6t_REJECT nf_reject_ipv6 ip6table_mangle
xt_set ip_set_hash_ip ip_set nf_log_ipv4 nf_log_common xt_LOG xt_recent
iptable_nat nf_nat_ipv4 xt_comment ipt_REJECT nf_reject_ipv4 xt_addrtype
bridge stp llc xt_mark iptable_mangle xt_tcpudp iptable_raw
nf_conntrack_ipv4 nf_defrag_ipv4 xt_CT nf_nat_tftp nf_nat_snmp_basic
nf_conntrack_snmp ip6table_raw nf_nat_sip xt_multiport nf_nat_pptp
nf_nat_proto_gre nf_nat_irc nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_h323
nf_nat_ftp xt_conntrack nf_nat_amanda nf_nat nf_conntrack_tftp
nf_conntrack_sip nf_conntrack_sane nf_conntrack_pptp
nf_conntrack_proto_gre nf_conntrack_netlink nfnetlink
nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc
nf_conntrack_h323 nf_conntrack_ftp
[ 563.715634] ts_kmp nf_conntrack_amanda nf_conntrack iptable_filter
ip_tables ip6table_filter ip6_tables x_tables lockd grace ctr ccm
af_packet bnep msr arc4 brcmsmac uvcvideo cordic brcmutil ftdi_sio
videobuf2_vmalloc usbserial intel_powerclamp mac80211 videobuf2_memops
btusb videobuf2_v4l2 btrtl coretemp snd_hda_codec_hdmi btbcm
videobuf2_core btintel kvm_intel snd_hda_codec_realtek bluetooth kvm
videodev joydev cfg80211 snd_hda_codec_generic media snd_hda_intel
snd_hda_codec psmouse snd_hda_core irqbypass e1000e snd_hwdep input_leds
snd_pcm iTCO_wdt iTCO_vendor_support serio_raw crc32c_intel toshiba_acpi
snd_timer ptp mei_me fjes bcma snd mei thermal sparse_keymap
toshiba_haps industrialio lpc_ich soundcore battery ac pps_core shpchp
intel_ips toshiba_bluetooth wmi rfkill tpm_tis tpm_tis_core
[ 563.726159] tpm cpufreq_ondemand cpufreq_conservative
cpufreq_powersave acpi_cpufreq evdev nvram sunrpc sch_fq_codel ipv6
crc_ccitt autofs4 hid_generic usbhid hid sdhci_pci mmc_block sdhci
sr_mod ehci_pci ehci_hcd mmc_core usbcore usb_common i915 video button
i2c_algo_bit drm_kms_helper drm
[ 563.730623] CPU: 0 PID: 29 Comm: kworker/0:1 Not tainted
4.10.54.10.5_debug+ #13
[ 563.732862] Hardware name: TOSHIBA Satellite R630/Portable PC, BIOS
Version 1.40 07/20/2010
[ 563.735127] Workqueue: events hci_uart_write_work [hci_uart]
[ 563.737376] task: ffffa03f32951b00 task.stack: ffffbc4ec0768000
[ 563.739620] RIP: 0010:_raw_spin_lock_irqsave+0x22/0x40
[ 563.741839] RSP: 0018:ffffbc4ec076bdd8 EFLAGS: 00010046
[ 563.744059] RAX: 0000000000000000 RBX: 0000000000000202 RCX:
ffffa03f37c1cd60
[ 563.746286] RDX: 0000000000000001 RSI: ffffa03f37c18ae0 RDI:
000000000000001c
[ 563.748493] RBP: ffffbc4ec076bde0 R08: ffffa03f32332380 R09:
0000000000000001
[ 563.750690] R10: ffffe9de427ce800 R11: ffffa03f33498600 R12:
0000000000000008
[ 563.752884] R13: 000000000000001c R14: ffffa03e79b1ad38 R15:
ffffa03e79b1a240
[ 563.755075] FS: 0000000000000000(0000) GS:ffffa03f37c00000(0000)
knlGS:0000000000000000
[ 563.757260] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 563.759426] CR2: 000000000000001c CR3: 000000011d7a3000 CR4:
00000000000006f0
[ 563.761610] Call Trace:
[ 563.763798] skb_dequeue+0x1d/0x70
[ 563.765975] h4_dequeue+0x16/0x20 [hci_uart]
[ 563.768128] hci_uart_write_work+0xc4/0x100 [hci_uart]
[ 563.770262] process_one_work+0x151/0x410
[ 563.772368] worker_thread+0x69/0x4b0
[ 563.774466] kthread+0x114/0x150
[ 563.776519] ? rescuer_thread+0x340/0x340
[ 563.778546] ? kthread_park+0x90/0x90
[ 563.780566] ret_from_fork+0x2c/0x40
[ 563.782559] Code: 89 e5 e8 82 96 98 ff 5d c3 66 66 66 66 90 55 48 89
e5 53 9c 58 66 66 90 66 90 48 89 c3 fa 66 66 90 66 66 90 31 c0 ba 01 00
00 00 <f0> 0f b1 17 85 c0 75 06 48 89 d8 5b 5d c3 89 c6 e8 29 83 98 ff
[ 563.786800] RIP: _raw_spin_lock_irqsave+0x22/0x40 RSP: ffffbc4ec076bdd8
[ 563.788940] CR2: 000000000000001c
[ 563.798389] ---[ end trace 326429e7baa9f359 ]---
Please see my analysis in bt_hci_uart_ldisc_h4_crash_snippet_log.txt
With my patchset applied, this crash does not occur because locking is
present which inhibits the Data Link protocol layer's dequeue function
from running when the Data Link protocol layer is about to be closed down.
I will try to provide some "good" logs of my patchset with btattach
using BCSP.
Thanks,
Best regards,
Dean
--
Dean Jenkins
Embedded Software Engineer
Linux Transportation Solutions
Mentor Embedded Software Division
Mentor Graphics (UK) Ltd.
[-- Attachment #2: v4.10.5.h4_crash.tgz --]
[-- Type: application/x-compressed-tar, Size: 7866 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] Bluetooth: 6lowpan: Remove unnecessary peer lookup
From: Marcel Holtmann @ 2017-04-05 13:47 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Linux Bluetooth, Alexander Aring, Jukka Rissanen, linux-wpan
In-Reply-To: <20170403144857.4661-1-luiz.dentz@gmail.com>
Hi Luiz,
> During chan_recv_cb there is already a peer lookup which can be passed
> to recv_pkt directly instead of the channel.
>
> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> ---
> net/bluetooth/6lowpan.c | 15 ++++-----------
> 1 file changed, 4 insertions(+), 11 deletions(-)
all 3 patches have been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 3/3] Bluetooth: L2CAP: Don't return -EAGAIN if out of credits
From: Jukka Rissanen @ 2017-04-05 12:24 UTC (permalink / raw)
To: Luiz Augusto von Dentz, linux-bluetooth; +Cc: aar, linux-wpan
In-Reply-To: <20170403144857.4661-3-luiz.dentz@gmail.com>
Hi Luiz,
On Mon, 2017-04-03 at 17:48 +0300, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>
> Just keep queueing them into TX queue since the caller might just
> have
> to do the same and there is no impact in adding another packet to the
> TX queue even if there aren't any credits to transmit them.
>
> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> ---
> net/bluetooth/l2cap_core.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index fc7f321..3a202b0 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -2458,9 +2458,6 @@ int l2cap_chan_send(struct l2cap_chan *chan,
> struct msghdr *msg, size_t len)
> if (len > chan->omtu)
> return -EMSGSIZE;
>
> - if (!chan->tx_credits)
> - return -EAGAIN;
> -
> __skb_queue_head_init(&seg_queue);
>
> err = l2cap_segment_le_sdu(chan, &seg_queue, msg,
> len);
Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Cheers,
Jukka
^ permalink raw reply
* Re: [PATCH 2/3] Bluetooth: 6lowpan: Print errors during recv_pkt
From: Jukka Rissanen @ 2017-04-05 12:23 UTC (permalink / raw)
To: Luiz Augusto von Dentz, linux-bluetooth; +Cc: aar, linux-wpan
In-Reply-To: <20170403144857.4661-2-luiz.dentz@gmail.com>
Hi Luiz,
On Mon, 2017-04-03 at 17:48 +0300, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>
> This makes should make it more clear why a packet is being dropped.
>
> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> ---
> net/bluetooth/6lowpan.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
> index 2063e96..5b91e85 100644
> --- a/net/bluetooth/6lowpan.c
> +++ b/net/bluetooth/6lowpan.c
> @@ -337,6 +337,7 @@ static int recv_pkt(struct sk_buff *skb, struct
> net_device *dev,
>
> ret = iphc_decompress(local_skb, dev, peer);
> if (ret < 0) {
> + BT_DBG("iphc_decompress failed: %d", ret);
> kfree_skb(local_skb);
> goto drop;
> }
> @@ -356,6 +357,7 @@ static int recv_pkt(struct sk_buff *skb, struct
> net_device *dev,
> consume_skb(local_skb);
> consume_skb(skb);
> } else {
> + BT_DBG("unknown packet type");
> goto drop;
> }
>
Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Cheers,
Jukka
^ permalink raw reply
* Re: [PATCH 1/3] Bluetooth: 6lowpan: Remove unnecessary peer lookup
From: Jukka Rissanen @ 2017-04-05 12:23 UTC (permalink / raw)
To: Luiz Augusto von Dentz, linux-bluetooth; +Cc: aar, linux-wpan
In-Reply-To: <20170403144857.4661-1-luiz.dentz@gmail.com>
Hi Luiz,
On Mon, 2017-04-03 at 17:48 +0300, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>
> During chan_recv_cb there is already a peer lookup which can be
> passed
> to recv_pkt directly instead of the channel.
>
> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> ---
> net/bluetooth/6lowpan.c | 15 ++++-----------
> 1 file changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
> index b39da8d..2063e96 100644
> --- a/net/bluetooth/6lowpan.c
> +++ b/net/bluetooth/6lowpan.c
> @@ -269,27 +269,20 @@ static int give_skb_to_upper(struct sk_buff
> *skb, struct net_device *dev)
> }
>
> static int iphc_decompress(struct sk_buff *skb, struct net_device
> *netdev,
> - struct l2cap_chan *chan)
> + struct lowpan_peer *peer)
> {
> const u8 *saddr;
> struct lowpan_btle_dev *dev;
> - struct lowpan_peer *peer;
>
> dev = lowpan_btle_dev(netdev);
>
> - rcu_read_lock();
> - peer = __peer_lookup_chan(dev, chan);
> - rcu_read_unlock();
> - if (!peer)
> - return -EINVAL;
> -
> saddr = peer->lladdr;
>
> return lowpan_header_decompress(skb, netdev, netdev-
> >dev_addr, saddr);
> }
>
> static int recv_pkt(struct sk_buff *skb, struct net_device *dev,
> - struct l2cap_chan *chan)
> + struct lowpan_peer *peer)
> {
> struct sk_buff *local_skb;
> int ret;
> @@ -342,7 +335,7 @@ static int recv_pkt(struct sk_buff *skb, struct
> net_device *dev,
>
> local_skb->dev = dev;
>
> - ret = iphc_decompress(local_skb, dev, chan);
> + ret = iphc_decompress(local_skb, dev, peer);
> if (ret < 0) {
> kfree_skb(local_skb);
> goto drop;
> @@ -388,7 +381,7 @@ static int chan_recv_cb(struct l2cap_chan *chan,
> struct sk_buff *skb)
> if (!dev || !dev->netdev)
> return -ENOENT;
>
> - err = recv_pkt(skb, dev->netdev, chan);
> + err = recv_pkt(skb, dev->netdev, peer);
> if (err) {
> BT_DBG("recv pkt %d", err);
> err = -EAGAIN;
Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Cheers,
Jukka
^ permalink raw reply
* Re: Re-connect to BLE device in response to ADV_DIRECT_IND
From: sudeepta bhuyan @ 2017-04-05 11:25 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Marcel Holtmann, linux-bluetooth@vger.kernel.org
In-Reply-To: <CABBYNZ+pj_rpchfYs37Sj0Goddi1CL6VMU=C9wuh7=QxTHFnJA@mail.gmail.com>
Thanks Marcel and Luiz
My application was always in active discovery mode. After disabling
active discovery, auto connect started to work. I have read that this
is an issue with linux kernel version < 3.17.
Sudeepta
On Wed, Apr 5, 2017 at 4:46 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Sudeepta,
>
> On Wed, Apr 5, 2017 at 4:14 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
>> Hi Sudeepta,
>>
>>> I'm a BlueZ newbie and wanted your help regarding a problem that I'm
>>> facing with a BLE project.
>>>
>>> I'm running BlueZ 5.42 in my linux machine and have written a
>>> bluetooth application which communicates with a BLE device.
>>> The application uses bluez dbus APIs for pairing and connecting to the
>>> BLE device (device-api.txt and adapter-api.txt).
>>> The BLE device is programmed to disconnect if left idle and send
>>> ADV_DIRECT_IND if woken up.
>>>
>>> Using hcidump tool, I see that bluetoothd on my machine indeed
>>> receives the ADV_DIRECT_IND message from the BLE device. However I'm
>>> not able to figure out how my application can be made aware that such
>>> an advertisement has been received and it should now reconnect to the
>>> BLE device.
>>>
>>> I do not see any dbus API or signal using which the application can be
>>> made aware of this event.
>>>
>>> Could you suggest me a solution to this? Are there any low level
>>> settings/configuration which would make bluetoothd automatically
>>> reconnect to the BLE device if it receives an ADV_DIRECT_IND?
>>
>> the kernel will auto-connect that device if it is in its auto-connect list. I think there are options via D-Bus to enable the auto-connect feature for certain devices.
>
> The applications needs to register itself with RegisterApplication and
> have a matching GattProfile in order for bluetoothd to add a device to
> the auto-connect list:
>
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/gatt-api.txt
>
> Note, if device.Disconnect is called it will remove the device from
> the auto-connect list, in that case device.Connect has to be called
> manually in order to add the device back.
>
>
>
> --
> Luiz Augusto von Dentz
^ permalink raw reply
* Re: Re-connect to BLE device in response to ADV_DIRECT_IND
From: Luiz Augusto von Dentz @ 2017-04-05 11:16 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: sudeepta bhuyan, linux-bluetooth@vger.kernel.org
In-Reply-To: <5A0CB2AD-B99B-4929-A641-423CF8C7799C@holtmann.org>
Hi Sudeepta,
On Wed, Apr 5, 2017 at 4:14 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Sudeepta,
>
>> I'm a BlueZ newbie and wanted your help regarding a problem that I'm
>> facing with a BLE project.
>>
>> I'm running BlueZ 5.42 in my linux machine and have written a
>> bluetooth application which communicates with a BLE device.
>> The application uses bluez dbus APIs for pairing and connecting to the
>> BLE device (device-api.txt and adapter-api.txt).
>> The BLE device is programmed to disconnect if left idle and send
>> ADV_DIRECT_IND if woken up.
>>
>> Using hcidump tool, I see that bluetoothd on my machine indeed
>> receives the ADV_DIRECT_IND message from the BLE device. However I'm
>> not able to figure out how my application can be made aware that such
>> an advertisement has been received and it should now reconnect to the
>> BLE device.
>>
>> I do not see any dbus API or signal using which the application can be
>> made aware of this event.
>>
>> Could you suggest me a solution to this? Are there any low level
>> settings/configuration which would make bluetoothd automatically
>> reconnect to the BLE device if it receives an ADV_DIRECT_IND?
>
> the kernel will auto-connect that device if it is in its auto-connect list. I think there are options via D-Bus to enable the auto-connect feature for certain devices.
The applications needs to register itself with RegisterApplication and
have a matching GattProfile in order for bluetoothd to add a device to
the auto-connect list:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/gatt-api.txt
Note, if device.Disconnect is called it will remove the device from
the auto-connect list, in that case device.Connect has to be called
manually in order to add the device back.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: Re-connect to BLE device in response to ADV_DIRECT_IND
From: Marcel Holtmann @ 2017-04-05 1:14 UTC (permalink / raw)
To: sudeepta bhuyan; +Cc: linux-bluetooth
In-Reply-To: <CA+TC0NoAX-B362BS=s-kk3bhi4k75ygYV_Lix6F9vDoJsTMS-w@mail.gmail.com>
Hi Sudeepta,
> I'm a BlueZ newbie and wanted your help regarding a problem that I'm
> facing with a BLE project.
>
> I'm running BlueZ 5.42 in my linux machine and have written a
> bluetooth application which communicates with a BLE device.
> The application uses bluez dbus APIs for pairing and connecting to the
> BLE device (device-api.txt and adapter-api.txt).
> The BLE device is programmed to disconnect if left idle and send
> ADV_DIRECT_IND if woken up.
>
> Using hcidump tool, I see that bluetoothd on my machine indeed
> receives the ADV_DIRECT_IND message from the BLE device. However I'm
> not able to figure out how my application can be made aware that such
> an advertisement has been received and it should now reconnect to the
> BLE device.
>
> I do not see any dbus API or signal using which the application can be
> made aware of this event.
>
> Could you suggest me a solution to this? Are there any low level
> settings/configuration which would make bluetoothd automatically
> reconnect to the BLE device if it receives an ADV_DIRECT_IND?
the kernel will auto-connect that device if it is in its auto-connect list. I think there are options via D-Bus to enable the auto-connect feature for certain devices.
Regards
Marcel
^ permalink raw reply
* Re: [RFC V1 00/16] hci_ldisc hci_uart_tty_close() fixes
From: Dean Jenkins @ 2017-04-04 20:36 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Gustavo F. Padovan, Johan Hedberg, linux-bluetooth
In-Reply-To: <119BB9FC-C735-405B-9A77-E9F102393B7D@holtmann.org>
[-- Attachment #1: Type: text/plain, Size: 7084 bytes --]
Hi Marcel,
On 03/04/17 16:51, Marcel Holtmann wrote:
>
> If this is an issue in 4.10, then lets get this fixed / hardened.
>
I have created a simple test script that leads to a kernel crash in HCI
UART LDISC. Please note that this is a different scenario to the one
documented in my previous E-mails but the resulting crash is similar.
I am using a BCSP supported Bluetooth Radio Module connected via a USB
to serial interface to a 64-bit x86 Linux laptop.
I built kernel v4.10.5 although I messed up the .config settings so
uname -r gave a strange string of4.10.54.10.5_debug+, sigh
Please note that "btattach" fails to establish a BCSP connection with
the Bluetooth Radio Module but that is advantageous in exposing a fatal
race condition in hci_uart_tty_close(). In this case, the BCSP Data Link
protocol layer attempts to retransmit every 250ms and the BCSP layer
gets closed down whilst still attempting to retransmit which causes a
kernel crash.
My proposed patchset fixes this race condition plus some other issues.
Please refer to my attached tarball v4.10.5_bt_crash_info.tgz, the
contents are:
v4.10.5_pure_testing/
v4.10.5_pure_testing/0001-Bluetooth-Debug-shows-how-hci_uart_tty_close-is-call.patch
v4.10.5_pure_testing/v4.10.5_pure_testing/btattach_loop.sh
v4.10.5_pure_testing/enable_hci_bt_logging.sh
v4.10.5_pure_testing/bt_hci_uart_ldisc_crash_snippet_log.txt
The patch file
0001-Bluetooth-Debug-shows-how-hci_uart_tty_close-is-call.patch
is just adding debug so you can see that killing "btattach" causes
do_group_exit() to run in the kernel which cleans-up by using
tty_ldisc_kill() which calls tty_ldisc_close() which causes
hci_uart_tty_close() to run.
enable_hci_bt_logging.sh
enables dynamic debug for dmesg although dynamic debug seems unreliable
these days at least for me and I have to run enable_hci_bt_logging.sh
multiple times to get all the files logging properly.
bt_hci_uart_ldisc_crash_snippet_log.txt
This shows my analysis of 2 example NULL pointer dereference kernel
crashes which are easy to reproduce using my test script.
v4.10.5_pure_testing/btattach_loop.sh
This is the simple test script which causes a kernel crash within 10
minutes of running, it is easily repeatable with my equipment. I think
the kernel crash occurs before the loop counter reaches 100.
The contents of the script is:
#!/bin/bash
let i=1
while [ true ]
do
echo "loop $i"
./btattach -A /dev/ttyUSB0 -P bcsp &
sleep 5
echo "now killing..."
killall btattach
i=$(($i + 1))
done
Example kernel crash backtrace:
[ 1561.709737] BUG: unable to handle kernel NULL pointer dereference at
0000000000000044
[ 1561.709829] IP: _raw_spin_lock_irqsave+0x22/0x40
[ 1561.709862] PGD 0
[ 1561.709889] Oops: 0002 [#1] SMP
[ 1561.709911] Modules linked in: ftdi_sio rfcomm hci_uart btqca xt_set
ip_set_hash_ip nf_log_ipv6 ip_set nf_log_ipv4 nf_log_common xt_LOG
ip6table_nat nf_nat_ipv6 xt_recent iptable_nat nf_nat_ipv4 ipt_REJECT
nf_reject_ipv4 iptable_mangle iptable_raw nf_conntrack_ipv4
nf_defrag_ipv4 xt_comment ip6t_REJECT nf_reject_ipv6 xt_addrtype bridge
stp llc xt_mark ip6table_mangle nf_nat_tftp nf_nat_snmp_basic
nf_conntrack_snmp xt_tcpudp nf_nat_sip xt_CT nf_nat_pptp
nf_nat_proto_gre nf_nat_irc ip6table_raw nf_nat_h323 xt_multiport
nf_nat_ftp nf_nat_amanda nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack
nf_nat nf_conntrack_tftp nf_conntrack_sip nf_conntrack_sane
nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nfnetlink
nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc
nf_conntrack_h323
[ 1561.710172] nf_conntrack_ftp ts_kmp nf_conntrack_amanda nf_conntrack
iptable_filter ip_tables ip6table_filter ip6_tables x_tables lockd grace
ctr ccm af_packet bnep msr usbserial uvcvideo btusb btrtl arc4 brcmsmac
btbcm videobuf2_vmalloc btintel cordic videobuf2_memops bluetooth
intel_powerclamp brcmutil videobuf2_v4l2 videobuf2_core mac80211
videodev coretemp kvm_intel kvm joydev media cfg80211 iTCO_wdt
iTCO_vendor_support snd_hda_codec_hdmi snd_hda_codec_realtek psmouse
snd_hda_codec_generic toshiba_acpi input_leds bcma snd_hda_intel
irqbypass snd_hda_codec toshiba_bluetooth cpufreq_ondemand sparse_keymap
crc32c_intel cpufreq_conservative industrialio snd_hda_core serio_raw
wmi rfkill thermal cpufreq_powersave battery ac snd_hwdep snd_pcm
acpi_cpufreq snd_timer snd toshiba_haps mei_me mei e1000e
[ 1561.718028] fjes soundcore evdev ptp lpc_ich shpchp pps_core
intel_ips tpm_tis tpm_tis_core nvram tpm sch_fq_codel sunrpc ipv6
crc_ccitt autofs4 hid_generic usbhid hid sdhci_pci mmc_block sdhci
sr_mod ehci_pci ehci_hcd mmc_core usbcore usb_common i915 video button
i2c_algo_bit drm_kms_helper drm [last unloaded: ftdi_sio]
[ 1561.721317] CPU: 1 PID: 4473 Comm: kworker/1:0 Not tainted
4.10.54.10.5_debug+ #12
[ 1561.722981] Hardware name: TOSHIBA Satellite R630/Portable PC, BIOS
Version 1.40 07/20/2010
[ 1561.724660] Workqueue: events hci_uart_write_work [hci_uart]
[ 1561.726377] task: ffff98d9b4f15100 task.stack: ffffa868c1178000
[ 1561.728568] RIP: 0010:_raw_spin_lock_irqsave+0x22/0x40
[ 1561.730355] RSP: 0000:ffffa868c117bda8 EFLAGS: 00010046
[ 1561.731993] RAX: 0000000000000000 RBX: 0000000000000296 RCX:
0000000000079ad6
[ 1561.733646] RDX: 0000000000000001 RSI: ffff98da77c5c580 RDI:
0000000000000044
[ 1561.735314] RBP: ffffa868c117bdb0 R08: 000000000001c5a0 R09:
ffffffff9965a54a
[ 1561.736991] R10: fffff48441dc9a80 R11: ffff98da73403700 R12:
0000000000000030
[ 1561.738641] R13: 0000000000000044 R14: 0000000000000030 R15:
ffff98d9b4e50000
[ 1561.740288] FS: 0000000000000000(0000) GS:ffff98da77c40000(0000)
knlGS:0000000000000000
[ 1561.741940] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1561.743585] CR2: 0000000000000044 CR3: 0000000128d1a000 CR4:
00000000000006e0
[ 1561.745238] Call Trace:
[ 1561.746882] skb_dequeue+0x1d/0x70
[ 1561.748512] bcsp_dequeue+0x27/0x180 [hci_uart]
[ 1561.750130] ? kfree_skbmem+0x5a/0x60
[ 1561.751742] hci_uart_write_work+0xc4/0x100 [hci_uart]
[ 1561.753356] process_one_work+0x151/0x410
[ 1561.754930] worker_thread+0x69/0x4b0
[ 1561.756507] kthread+0x114/0x150
[ 1561.758076] ? rescuer_thread+0x340/0x340
[ 1561.759636] ? kthread_park+0x90/0x90
[ 1561.761191] ret_from_fork+0x2c/0x40
[ 1561.762693] Code: 89 e5 e8 82 96 98 ff 5d c3 66 66 66 66 90 55 48 89
e5 53 9c 58 66 66 90 66 90 48 89 c3 fa 66 66 90 66 66 90 31 c0 ba 01 00
00 00 <f0> 0f b1 17 85 c0 75 06 48 89 d8 5b 5d c3 89 c6 e8 29 83 98 ff
[ 1561.766034] RIP: _raw_spin_lock_irqsave+0x22/0x40 RSP: ffffa868c117bda8
[ 1561.768033] CR2: 0000000000000044
[ 1561.774555] ---[ end trace 51cc1d3575c0e559 ]---
Please see my analysis in bt_hci_uart_ldisc_crash_snippet_log.txt
With my patchset applied, this crash appears to no longer occur.
If I manage to produce some more useful results then I will post them.
Thanks,
Best regards,
Dean
--
Dean Jenkins
Embedded Software Engineer
Linux Transportation Solutions
Mentor Embedded Software Division
Mentor Graphics (UK) Ltd.
[-- Attachment #2: v4.10.5_bt_crash_info.tgz --]
[-- Type: application/x-compressed-tar, Size: 8119 bytes --]
^ permalink raw reply
* Re-connect to BLE device in response to ADV_DIRECT_IND
From: sudeepta bhuyan @ 2017-04-04 13:29 UTC (permalink / raw)
To: linux-bluetooth
Hello all,
I'm a BlueZ newbie and wanted your help regarding a problem that I'm
facing with a BLE project.
I'm running BlueZ 5.42 in my linux machine and have written a
bluetooth application which communicates with a BLE device.
The application uses bluez dbus APIs for pairing and connecting to the
BLE device (device-api.txt and adapter-api.txt).
The BLE device is programmed to disconnect if left idle and send
ADV_DIRECT_IND if woken up.
Using hcidump tool, I see that bluetoothd on my machine indeed
receives the ADV_DIRECT_IND message from the BLE device. However I'm
not able to figure out how my application can be made aware that such
an advertisement has been received and it should now reconnect to the
BLE device.
I do not see any dbus API or signal using which the application can be
made aware of this event.
Could you suggest me a solution to this? Are there any low level
settings/configuration which would make bluetoothd automatically
reconnect to the BLE device if it receives an ADV_DIRECT_IND?
Appreciate your help.
Thanks,
Sudeepta
^ permalink raw reply
* Re: Bluetooth PAN Connection - NAP and GN
From: Luiz Augusto von Dentz @ 2017-04-04 9:34 UTC (permalink / raw)
To: Wong, Joshua Weng Onn; +Cc: Bluez mailing list
In-Reply-To: <E3B98393E6037849B63EA428240A65136126D7@PGSMSX103.gar.corp.intel.com>
Hi Joshua,
On Tue, Apr 4, 2017 at 10:51 AM, Wong, Joshua Weng Onn
<joshua.weng.onn.wong@intel.com> wrote:
> I would like to follow up with this issue. I am also testing the Group Network (GN) with PANU using the following steps:
>
> Master side:
> 1. ./test-gn (registers the UUID service 0x1117 for GN)
> 2. Perform pairing between the master and slave device via bluetoothctl
>
> Slave side:
> 1. Accept the pairing via bluetoothctl
> 2. ./test-network <MASTER_BT_MAC> gn
>
> On btmon, I observe an output which says "Connection refused - security block" which is the same message encountered by Jon.
>
>> ACL Data RX: Handle 1 flags 0x02 dlen 16 [hci0] 6608.309405
> L2CAP: Connection Response (0x03) ident 3 len 8
> Destination CID: 64
> Source CID: 64
> Result: Connection pending (0x0001)
> Status: Authorization pending (0x0002)
>> ACL Data RX: Handle 1 flags 0x02 dlen 16 [hci0] 6608.364566
> L2CAP: Connection Response (0x03) ident 3 len 8
> Destination CID: 64
> Source CID: 64
> Result: Connection refused - security block (0x0003)
> Status: No further information available (0x0000)
> < HCI Command: Disconnect (0x01|0x0006) plen 3 [hci0] 6610.367786
> Handle: 1
> Reason: Remote User Terminated Connection (0x13)
>> HCI Event: Command Status (0x0f) plen 4 [hci0] 6610.368878
> Disconnect (0x01|0x0006) ncmd 1
> Status: Success (0x00)
>> HCI Event: Disconnect Complete (0x05) plen 4 [hci0] 6610.420389
> Status: Success (0x00)
> Handle: 1
> Reason: Connection Terminated By Local Host (0x16)
> @ Device Disconnected: 74:C6:3B:AB:68:E0 (0) reason 2
>
> I have added the Network1 and NetworkServer1 interfaces in my dbus configuration file in /etc/dbus-1/system.d/bluetooth.conf on both the master and slave device but am still facing the message.
> I have also trusted each device via bluetoothctl on the master and slave.
>
> Has anyone successfully tested out this PAN scenario involving GN and PANU connection? What additional settings should we change to create this connection?
I guess you forgot to check if there where any fixes pushed upstream:
commit 49707d7a508fb01760713b7265a15886977b096f
Author: Maxime Chevallier <maxime.chevallier@smile.fr>
Date: Tue Oct 25 16:25:14 2016 +0200
profiles/network: Check for any server when accepting connections
When asking confirmation to accept an incoming connection,
we now only check for any network_server to be registered to
the adapter.
This fixes GN Master role, that wouldn't accept any connection
before.
--
Luiz Augusto von Dentz
^ permalink raw reply
* RE: Bluetooth PAN Connection - NAP and GN
From: Wong, Joshua Weng Onn @ 2017-04-04 7:51 UTC (permalink / raw)
To: Bluez mailing list
Hi,
> > > > On Tuesday 09 February 2016 13:17:56 Jon Hoffman wrote:
> > > > > Hello,
> > > > > I am hoping that someone on this list can tell me what I am
> > > > > doing wrong or at least point me in the right direction.
> > > > >
> > > > > As part of a number of proof-of-concepts, I am trying to setup a
> > > > > PAN between two devices. For this particular proof-of-concepts
> > > > > I am trying to setup a Bluetooth Legacy connection. I have
> > > > > successfully setup this connection using the NAP scenario
> > > > > however we are not looking to route anything outside of
> > > > > connection. Since we do not want to route (security also says
> > > > > we need to disable
> > > > > routing) we would prefer to use either a GN (Group Ad-Hoc
> > > > > Network) or a PANU-PANU connection however I have been unable to
> > > get
> > > > > this to work.
> > > > >
> > > > > My slave device (where the server is being setup at) is running
> > > > > the Linux kernel 4.4 (also tried it on a 4.1.13 kernel) with
> > > > > Bluez
> > > > > 5.35 (tried it with 5.23 on the 4.1.13 kernel). I have tried
> > > > > three master devices (device making the connection) and have the
> > > > > same issue with all
> > > > three. They are:
> > > > > -Linux kernel 4.1.13 with bluez 5.23 using blueman as the UI
> > > > > -Windows 10
> > > > > -iOS 9.2.1
> > > > >
> > > > > I have run hcidump to see what is going on during the
> > > > > pairing/connection of the NAP connection and also the GN
> > > > > connection to
> > > > see what is different.
> > > > > Below are sniplets of what I am seeing. For the NAP connection
> > > > > I am seeing
> > > > > this:
> > > > >
> > > > > information about the NAP from the hcidump
> > > > > record #6
> > > > > aid 0x0000 (SrvRecHndl)
> > > > > uint 0x10007
> > > > > aid 0x0001 (SrvClassIDList)
> > > > > < uuid-16 0x1116 (NAP) >
> > > > > aid 0x0004 (ProtocolDescList)
> > > > > < < uuid-16 0x0100 (L2CAP) uint 0xf > <
> > > > > uuid-16 0x000f (BNEP) uint 0x100 < uint 0x800
> > > > > uint
> > > > > 0x806 >
> > > > > > > aid 0x0005 (BrwGrpList)
> > > > > < uuid-16 0x1002 (PubBrwsGrp) >
> > > > > aid 0x0006 (LangBaseAttrIDList)
> > > > > < uint 0x656e uint 0x6a uint 0x100 >
> > > > > aid 0x0009 (BTProfileDescList)
> > > > > < < uuid-16 0x1116 (NAP) uint 0x100 > >
> > > > > aid 0x0100 (SrvName)
> > > > > str "Network service"
> > > > > aid 0x0101 (SrvDesc)
> > > > > str "Network service"
> > > > > aid 0x030a (SecurityDescription)
> > > > > uint 0x1
> > > > > aid 0x030b (NetAccessType)
> > > > > uint 0xfffe
> > > > > aid 0x030c (MaxNetAccessRate)
> > > > > uint 0x0
> > > > >
> > > > > Then for the actual connection attempt I see this:
> > > > > > ACL data: handle 11 flags 0x02 dlen 12
> > > > >
> > > > > L2CAP(s): Connect req: psm 15 scid 0x0041 < ACL data: handle
> > > > > 11 flags 0x00 dlen 16
> > > > > L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0041 result 1 statu=
s 2
> > > > > Connection pending - Authorization pending < ACL data:
> > > > > handle
> > > > > 11 flags 0x00 dlen 16
> > > > > L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0041 result 0 statu=
s 0
> > > > > Connection successful
> > > > >
> > > > > And after this my connection is established and all is well.
> > > > > For the GN network this is what I am seeing beginning with the
> > > > > information about the GN.
> > > > >
> > > > > record #6
> > > > > aid 0x0000 (SrvRecHndl)
> > > > > uint 0x10007
> > > > > aid 0x0001 (SrvClassIDList)
> > > > > < uuid-16 0x1117 (GN) >
> > > > > aid 0x0004 (ProtocolDescList)
> > > > > < < uuid-16 0x0100 (L2CAP) uint 0xf > <
> > > > > uuid-16 0x000f (BNEP) uint 0x100 < uint 0x800
> > > > > uint
> > > > > 0x806 >
> > > > > > > aid 0x0005 (BrwGrpList)
> > > > > < uuid-16 0x1002 (PubBrwsGrp) >
> > > > > aid 0x0006 (LangBaseAttrIDList)
> > > > > < uint 0x656e uint 0x6a uint 0x100 >
> > > > > aid 0x0009 (BTProfileDescList)
> > > > > < < uuid-16 0x1117 (GN) uint 0x100 > >
> > > > > aid 0x0100 (SrvName)
> > > > > str "Network service"
> > > > > aid 0x0101 (SrvDesc)
> > > > > str "Network service"
> > > > > aid 0x030a (SecurityDescription)
> > > > > uint 0x1
> > > > >
> > > > > and when the connection is made I see this:
> > > > > > ACL data: handle 11 flags 0x02 dlen 12
> > > > >
> > > > > L2CAP(s): Connect req: psm 15 scid 0x0041 < ACL data: handle
> > > > > 11 flags 0x00 dlen 16
> > > > > L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0041 result 1 statu=
s 2
> > > > > Connection pending - Authorization pending < ACL data:
> > > > > handle
> > > > > 11 flags 0x00 dlen 16
> > > > > L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0041 result 3 statu=
s 0
> > > > > Connection refused - security block
> > > >
> > > > This looks like connection was rejected due to missing authorizatio=
n.
> > > > Are you sure you have default agent registered in your system?
> > > >
> > > > Providing also 'bluetoothd -n -d' logs would put some light on thi=
s issue.
> > > >
> > > > --
> > > > pozdrawiam
> > > > Szymon Janc
> > >
> > >
> > > Hello,
> > > Thank you for the reply. Sorry for my inexperience but I believe I
> > > have the default agent registered because the NAP service works
> > > perfectly. It is only the GN that does not work. Would the agent
> > > be different and if so how would I verify? I was elected to develop
> > > various proof of concepts for PAN over Bluetooth and Bluetooth Smart
> > > more for my networking/Sys- Admin/development background and not
> > > really for any Bluetooth experience.
> > > This is what is outputted from the 'bluetooth -n -d' when I register
> > > the GN
> > > service:
> > >
> > >
> > > bluetoothd[3307]: src/adapter.c:adapter_service_add() /org/bluez=
/hci0
> > > bluetoothd[3307]: src/sdpd-service.c:add_record_to_server()
> > > Adding record with handle 0x10009
> > > bluetoothd[3307]: src/sdpd-service.c:add_record_to_server()
> > > Record pattern UUID 0000000f-0000-1000-8000-00805f9
> > > bluetoothd[3307]: src/sdpd-service.c:add_record_to_server()
> > > Record pattern UUID 00000100-0000-1000-8000-00805f9
> > > bluetoothd[3307]: src/sdpd-service.c:add_record_to_server()
> > > Record pattern UUID 00001002-0000-1000-8000-00805f9
> > > bluetoothd[3307]: src/sdpd-service.c:add_record_to_server()
> > > Record pattern UUID 00001117-0000-1000-8000-00805f9
> > > bluetoothd[3307]: src/adapter.c:adapter_service_insert()
> > /org/bluez/hci0
> > > bluetoothd[3307]: src/adapter.c:add_uuid() sending add uuid
> > > command for index 0
> > > bluetoothd[3307]:
> > > profiles/network/server.c:register_server_record() got record id 0x10=
009
> > > bluetoothd[3307]: src/adapter.c:dev_class_changed_callback() Cla=
ss:
> > > 0x2e0000
> > >
> > > This is what I see when I attempt to connect to the service:
> > >
> > > bluetoothd[3307]: src/adapter.c:connected_callback() hci0
> > > device 5C:F3:70:XX:XX:XX connected eir_len 13
> > > bluetoothd[3307]: src/adapter.c:new_link_key_callback() hci0
> > > new key for 5C:F3:70:XX:XX:XX type 4 pin_len 0 store_hint 1
> > > bluetoothd[3307]: src/device.c:device_set_bonded()
> > > bluetoothd[3307]: src/device.c:device_bonding_complete()
> > > bonding
> > > (nil) status 0x00
> > > bluetoothd[3307]: src/adapter.c:resume_discovery()
> > > bluetoothd[3307]: src/adapter.c:dev_disconnected() Device
> > > 5C:F3:70:XX:XX:XX disconnected, reason 3
> > > bluetoothd[3307]: src/adapter.c:adapter_remove_connection()
> > > bluetoothd[3307]: plugins/policy.c:disconnect_cb() reason 3
> > > bluetoothd[3307]: src/adapter.c:bonding_attempt_complete() hci0
> > > bdaddr 5C:F3:70:XX:XX:XX type 0 status 0xe
> > > bluetoothd[3307]: src/device.c:device_bonding_complete()
> > > bonding
> > > (nil) status 0x0e
> > > bluetoothd[3307]: src/device.c:device_bonding_failed() status 14
> > > bluetoothd[3307]: src/adapter.c:resume_discovery()
> > > bluetoothd[3307]: src/adapter.c:connected_callback() hci0
> > > device 5C:F3:70:XX:XX:XX connected eir_len 13
> > > bluetoothd[3307]: profiles/network/server.c:confirm_event() BNEP=
:
> > > incoming connect from 5C:F3:70:XX:XX:XX
> > > bluetoothd[3307]: src/adapter.c:dev_disconnected() Device
> > > 5C:F3:70:XX:XX:XX disconnected, reason 3
> > > bluetoothd[3307]: src/adapter.c:adapter_remove_connection()
> > > bluetoothd[3307]: plugins/policy.c:disconnect_cb() reason 3
> > > bluetoothd[3307]: src/adapter.c:bonding_attempt_complete() hci0
> > > bdaddr 5C:F3:70:XX:XX:XX type 0 status 0xe
> > > bluetoothd[3307]: src/device.c:device_bonding_complete()
> > > bonding
> > > (nil) status 0x0e
> > > bluetoothd[3307]: src/device.c:device_bonding_failed() status 14
> > > bluetoothd[3307]: src/adapter.c:resume_discovery()
> > >
> > > On the fourth line it looks like the bonding is coming back as nil
> > > which can't be good. Is that the issue and what would cause that
> > > (sorry for the very basic questions)?
> > >
> > > Thanks for the help,
> > >
> > > Jon
> >
> > This morning I decided to run the bluetoothd in debug mode as Szymon
> > recommended and analyze output for the both the NAP (service that
> > works) and GN (service that does not work) services. I also decided
> > that I would break it down into three parts: Setting up the service,
> > Pairing and Connecting to the service. Here are my results:
> >
> > Setting up the services:
> > The output from setting up the services are almost identical.
> > The only difference is these lines:
> > NAP service
> > bluetoothd[1964]: src/sdpd-service.c:add_record_to_server()
> > Record pattern UUID 00001116-0000-1000-8000-00805f9
> > GN service
> > bluetoothd[1981]: src/sdpd-service.c:add_record_to_server()
> > Record pattern UUID 00001117-0000-1000-8000-00805f9
> >
> > Here are the full results:
> > NAP service
> > bluetoothd[1964]: src/adapter.c:adapter_service_add() /org/bl=
uez/hci0
> > bluetoothd[1964]: src/sdpd-service.c:add_record_to_server()
> > Adding record with handle 0x10009
> > bluetoothd[1964]: src/sdpd-service.c:add_record_to_server()
> > Record pattern UUID 0000000f-0000-1000-8000-00805f9
> > bluetoothd[1964]: src/sdpd-service.c:add_record_to_server()
> > Record pattern UUID 00000100-0000-1000-8000-00805f9
> > bluetoothd[1964]: src/sdpd-service.c:add_record_to_server()
> > Record pattern UUID 00001002-0000-1000-8000-00805f9
> > bluetoothd[1964]: src/sdpd-service.c:add_record_to_server()
> > Record pattern UUID 00001116-0000-1000-8000-00805f9
> > bluetoothd[1964]: src/adapter.c:adapter_service_insert()
> > /org/bluez/hci0
> > bluetoothd[1964]: src/adapter.c:add_uuid() sending add uuid
> > command for index 0
> > bluetoothd[1964]:
> > profiles/network/server.c:register_server_record()
> > got record id 0x10009
> > bluetoothd[1964]: src/adapter.c:dev_class_changed_callback() =
Class:
> > 0x2e0000
> >
> > GN service
> > bluetoothd[1981]: src/adapter.c:adapter_service_add() /org/bl=
uez/hci0
> > bluetoothd[1981]: src/sdpd-service.c:add_record_to_server()
> > Adding record with handle 0x10009
> > bluetoothd[1981]: src/sdpd-service.c:add_record_to_server()
> > Record pattern UUID 0000000f-0000-1000-8000-00805f9
> > bluetoothd[1981]: src/sdpd-service.c:add_record_to_server()
> > Record pattern UUID 00000100-0000-1000-8000-00805f9
> > bluetoothd[1981]: src/sdpd-service.c:add_record_to_server()
> > Record pattern UUID 00001002-0000-1000-8000-00805f9
> > bluetoothd[1981]: src/sdpd-service.c:add_record_to_server()
> > Record pattern UUID 00001117-0000-1000-8000-00805f9
> > bluetoothd[1981]: src/adapter.c:adapter_service_insert()
> > /org/bluez/hci0
> > bluetoothd[1981]: src/adapter.c:add_uuid() sending add uuid
> > command for index 0
> > bluetoothd[1981]:
> > profiles/network/server.c:register_server_record()
> > got record id 0x10009
> > bluetoothd[1981]: src/adapter.c:dev_class_changed_callback() =
Class:
> > 0x2e0000
> >
> >
> > Pairing:
> > These output from the pairing request, as expected is exactly the =
same.
> > Here is the full output:
> > NAP service:
> > bluetoothd[1964]: src/adapter.c:connected_callback() hci0
> > device
> > 5C:F3:70:66:43:58 connected eir_len 13
> > bluetoothd[1964]: src/adapter.c:new_link_key_callback() hci0
> > new key for 5C:F3:70:66:43:58 type 4 pin_len 0 store_hint 1
> > bluetoothd[1964]: src/device.c:device_set_bonded()
> > bluetoothd[1964]: src/device.c:device_bonding_complete()
> > bonding
> > (nil) status 0x00
> > bluetoothd[1964]: src/adapter.c:resume_discovery()
> > bluetoothd[1964]: src/adapter.c:dev_disconnected() Device
> > 5C:F3:70:66:43:58 disconnected, reason 3
> > bluetoothd[1964]: src/adapter.c:adapter_remove_connection()
> > bluetoothd[1964]: plugins/policy.c:disconnect_cb() reason 3
> > bluetoothd[1964]: src/adapter.c:bonding_attempt_complete()
> > hci0 bdaddr 5C:F3:70:66:43:58 type 0 status 0xe
> > bluetoothd[1964]: src/device.c:device_bonding_complete()
> > bonding
> > (nil) status 0x0e
> > bluetoothd[1964]: src/device.c:device_bonding_failed() status=
14
> > bluetoothd[1964]: src/adapter.c:resume_discovery()
> >
> >
> > GN service:
> > bluetoothd[1981]: src/adapter.c:connected_callback() hci0
> > device
> > 5C:F3:70:66:43:58 connected eir_len 13
> > bluetoothd[1981]: src/adapter.c:new_link_key_callback() hci0
> > new key for 5C:F3:70:66:43:58 type 4 pin_len 0 store_hint 1
> > bluetoothd[1981]: src/device.c:device_set_bonded()
> > bluetoothd[1981]: src/device.c:device_bonding_complete()
> > bonding
> > (nil) status 0x00
> > bluetoothd[1981]: src/adapter.c:resume_discovery()
> > bluetoothd[1981]: src/adapter.c:dev_disconnected() Device
> > 5C:F3:70:66:43:58 disconnected, reason 3
> > bluetoothd[1981]: src/adapter.c:adapter_remove_connection()
> > bluetoothd[1981]: plugins/policy.c:disconnect_cb() reason 3
> > bluetoothd[1981]: src/adapter.c:bonding_attempt_complete()
> > hci0 bdaddr 5C:F3:70:66:43:58 type 0 status 0xe
> > bluetoothd[1981]: src/device.c:device_bonding_complete()
> > bonding
> > (nil) status 0x0e
> > bluetoothd[1981]: src/device.c:device_bonding_failed() status=
14
> > bluetoothd[1981]: src/adapter.c:resume_discovery()
> >
> > Connecting:
> > The output from the connecting request, also as expected, is
> > quite a bit different. The first two lines are the same but then they
> > differ. The output from the NAP service indicates that the service is
> > supported within Bluez
> > (profiles/network/bnep.c:bnep_getsuppfeat() supported features: 0x1)
> > while the GN service receives a disconnect
> > (src/adapter.c:dev_disconnected() Device 5C:F3:70:66:43:58
> > disconnected, reason 3). Here is the full output:
> > NAP service:
> > bluetoothd[1964]: src/adapter.c:connected_callback() hci0
> > device
> > 5C:F3:70:66:43:58 connected eir_len 13
> > bluetoothd[1964]: profiles/network/server.c:confirm_event() B=
NEP:
> > incoming connect from 5C:F3:70:66:43:58
> > bluetoothd[1964]: profiles/network/bnep.c:bnep_getsuppfeat()
> > supported features: 0x1
> > bluetoothd[1964]: bnep: bridge pan0: interface
> > enx5cf37066433d added
> >
> > GN service:
> > bluetoothd[1981]: src/adapter.c:connected_callback() hci0
> > device
> > 5C:F3:70:66:43:58 connected eir_len 13
> > bluetoothd[1981]: profiles/network/server.c:confirm_event() B=
NEP:
> > incoming connect from 5C:F3:70:66:43:58
> > bluetoothd[1981]: src/adapter.c:dev_disconnected() Device
> > 5C:F3:70:66:43:58 disconnected, reason 3
> > bluetoothd[1981]: src/adapter.c:adapter_remove_connection()
> > bluetoothd[1981]: plugins/policy.c:disconnect_cb() reason 3
> > bluetoothd[1981]: src/adapter.c:bonding_attempt_complete()
> > hci0 bdaddr 5C:F3:70:66:43:58 type 0 status 0xe
> > bluetoothd[1981]: src/device.c:device_bonding_complete()
> > bonding
> > (nil) status 0x0e
> > bluetoothd[1981]: src/device.c:device_bonding_failed() status=
14
> > bluetoothd[1981]: src/adapter.c:resume_discovery()
> >
> >
> > Looking at this output it appears to me, please correct me if I am
> > wrong, that Bluez 5.35 does not support the Group Network (GN)
> > scenario within the PAN profile. I came to that conclusion because
> > within the NAP scenario it reaches the bnep_getsuppfeat() method which
> > I assume is the get supported feature while within the GN scenario it
> > does not. If that is the case, should I file a bug? However if I am
> > wrong, can someone tell me what is going wrong.
> > Thanks for the help and any advice would be appreciated.
>=20
> Can someone tell me the proper channel to report a bug for the issue I am
> having? I have confirmed that the same issue happens with the broadcomm
> BCM20702,
> Realtek RTL8723 and a Cambridge Silicon Radio Bluetooth dongle. Setting =
up a
> NAP works on all three devices while the GN gives the error that I docume=
nted in
> this e-mail thread. I have also verified that the error occurs on the 4.=
4 and 4.2
> kernel. The bluez versions that I am using is the 5.35 and 5.23.
>=20
> Thanks,
I would like to follow up with this issue. I am also testing the Group Netw=
ork (GN) with PANU using the following steps:
Master side:
1. ./test-gn (registers the UUID service 0x1117 for GN)
2. Perform pairing between the master and slave device via bluetoothctl
Slave side:
1. Accept the pairing via bluetoothctl
2. ./test-network <MASTER_BT_MAC> gn
On btmon, I observe an output which says "Connection refused - security blo=
ck" which is the same message encountered by Jon.
> ACL Data RX: Handle 1 flags 0x02 dlen 16 [=
hci0] 6608.309405
L2CAP: Connection Response (0x03) ident 3 len 8
Destination CID: 64
Source CID: 64
Result: Connection pending (0x0001)
Status: Authorization pending (0x0002)
> ACL Data RX: Handle 1 flags 0x02 dlen 16 [=
hci0] 6608.364566
L2CAP: Connection Response (0x03) ident 3 len 8
Destination CID: 64
Source CID: 64
Result: Connection refused - security block (0x0003)
Status: No further information available (0x0000)
< HCI Command: Disconnect (0x01|0x0006) plen 3 [=
hci0] 6610.367786
Handle: 1
Reason: Remote User Terminated Connection (0x13)
> HCI Event: Command Status (0x0f) plen 4 [=
hci0] 6610.368878
Disconnect (0x01|0x0006) ncmd 1
Status: Success (0x00)
> HCI Event: Disconnect Complete (0x05) plen 4 [=
hci0] 6610.420389
Status: Success (0x00)
Handle: 1
Reason: Connection Terminated By Local Host (0x16)
@ Device Disconnected: 74:C6:3B:AB:68:E0 (0) reason 2
I have added the Network1 and NetworkServer1 interfaces in my dbus configur=
ation file in /etc/dbus-1/system.d/bluetooth.conf on both the master and sl=
ave device but am still facing the message.
I have also trusted each device via bluetoothctl on the master and slave.
Has anyone successfully tested out this PAN scenario involving GN and PANU =
connection? What additional settings should we change to create this connec=
tion?
Thank you.
~Joshua
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox