mooltipass
Linux: bluez/bluetoothd segfault when pairing the minible
Failure to pair minible on Linux
Edit: This issue should be solved with bluez 5.55. Read on for details.
Description
Pairing on linux using bluez 5.54 (and probably earlier as well) leads to the bluez daemon segfaulting, bluetoothd. The segfaults are related to the minible having two HID-over-GATT devices.
Workaround
This is fixed on current bluez master (2020-05-19). Pairing works on current bluez master, and moolticute should be able to detect the minible properly as well (given you have the correct udev rules loaded).
NOTE Expect some weirdness where front-ends to bluez (GUI, bluetoothctl etc) don't prompt for the passcode when pairing. This weirdness can usually be avoided by making sure both the minible and bluez have completely unpaired from each other first (issue the remove <BT ADDRESS> command in bluetoothctl), and then first pairing (pair command), then connecting (connect command) in bluetoothctl (or possibly your GUI of choice if it supports this granularity).
If you want to try to build bluez master yourself, here's a quick guide for what I needed to do on debian unstable. Depending on your distro, you might need to install the build requirements differently, or manually figure out what you need (the bootstrap-configure script should tell you either way). Read the HACKING document in the bluez repository for more tips and details.
Fetching and building:
sudo apt build-dep bluez # installs build requirements for your current bluez version
# clone bluez
git clone https://git.kernel.org/pub/scm/bluetooth/bluez.git
# clone libell. needs to be run in the same directory where you ran the command to clone bluez
git clone https://git.kernel.org/pub/scm/libs/ell/ell.git
cd bluez
./bootstrap-configure # this should complain if you're missing requirements
make -j6 # or however many cores you have/want to use
Running the daemon
# start the bluetoothd daemon in the foreground, with debug logging
sudo ./src/bluetoothd -n -d --noplugin=hostname
In another terminal, pair and connect using the bluetoothctl command line front-end (see here for a crash intro):
./client/bluetoothctl
# you now get a prompt for commands. example for connecting to the minible (note the prompt for the passkey):
[bluetooth]# scan off
Discovery stopped
[CHG] Controller 00:18:91:6C:BA:8A Discovering: no
[CHG] Device D9:FF:38:66:3C:A9 RSSI is nil
[CHG] Device A8:7D:12:04:66:93 TxPower is nil
[CHG] Device A8:7D:12:04:66:93 RSSI is nil
(ins)[bluetooth]# pair D9:FF:38:66:3C:A9
Attempting to pair with D9:FF:38:66:3C:A9
[CHG] Device D9:FF:38:66:3C:A9 Connected: yes
[agent] Passkey: 634428
[NEW] Primary Service (Handle 0x61cd)
/org/bluez/hci0/dev_D9_FF_38_66_3C_B9/service0008
00001801-0000-1000-8000-00805f9b34fb
Generic Attribute Profile
[NEW] Characteristic (Handle 0x61cd)
/org/bluez/hci0/dev_D9_FF_38_66_3C_B9/service0008/char0009
00002a05-0000-1000-8000-00805f9b34fb
Service Changed
[NEW] Descriptor (Handle 0x06c4)
/org/bluez/hci0/dev_D9_FF_38_66_3C_B9/service0008/char0009/desc000b
00002902-0000-1000-8000-00805f9b34fb
Client Characteristic Configuration
[NEW] Primary Service (Handle 0x61cd)
/org/bluez/hci0/dev_D9_FF_38_66_3C_B9/service0030
0000180a-0000-1000-8000-00805f9b34fb
Device Information
[NEW] Characteristic (Handle 0x61cd)
/org/bluez/hci0/dev_D9_FF_38_66_3C_B9/service0030/char0031
00002a29-0000-1000-8000-00805f9b34fb
Manufacturer Name String
[NEW] Characteristic (Handle 0x61cd)
/org/bluez/hci0/dev_D9_FF_38_66_3C_B9/service0030/char0033
00002a24-0000-1000-8000-00805f9b34fb
Model Number String
[NEW] Characteristic (Handle 0x61cd)
/org/bluez/hci0/dev_D9_FF_38_66_3C_B9/service0030/char0035
00002a25-0000-1000-8000-00805f9b34fb
Serial Number String
[NEW] Characteristic (Handle 0x61cd)
/org/bluez/hci0/dev_D9_FF_38_66_3C_B9/service0030/char0037
00002a27-0000-1000-8000-00805f9b34fb
Hardware Revision String
[NEW] Characteristic (Handle 0x61cd)
/org/bluez/hci0/dev_D9_FF_38_66_3C_B9/service0030/char0039
00002a26-0000-1000-8000-00805f9b34fb
Firmware Revision String
[NEW] Characteristic (Handle 0x61cd)
/org/bluez/hci0/dev_D9_FF_38_66_3C_B9/service0030/char003b
00002a28-0000-1000-8000-00805f9b34fb
Software Revision String
[NEW] Characteristic (Handle 0x61cd)
/org/bluez/hci0/dev_D9_FF_38_66_3C_B9/service0030/char003d
00002a23-0000-1000-8000-00805f9b34fb
System ID
[NEW] Characteristic (Handle 0x61cd)
/org/bluez/hci0/dev_D9_FF_38_66_3C_B9/service0030/char003f
00002a50-0000-1000-8000-00805f9b34fb
PnP ID
[CHG] Device D9:FF:38:66:3C:A9 UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Device D9:FF:38:66:3C:A9 UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[CHG] Device D9:FF:38:66:3C:A9 UUIDs: 0000180a-0000-1000-8000-00805f9b34fb
[CHG] Device D9:FF:38:66:3C:A9 UUIDs: 0000180f-0000-1000-8000-00805f9b34fb
[CHG] Device D9:FF:38:66:3C:A9 UUIDs: 00001812-0000-1000-8000-00805f9b34fb
[CHG] Device D9:FF:38:66:3C:A9 ServicesResolved: yes
[CHG] Device D9:FF:38:66:3C:A9 Paired: yes
Pairing successful
[CHG] Device D9:FF:38:66:3C:A9 Appearance: 0x00c1
[CHG] Device D9:FF:38:66:3C:A9 Modalias: bluetooth:v1209p4321d0001
[CHG] Device D9:FF:38:66:3C:A9 ServicesResolved: no
[CHG] Device D9:FF:38:66:3C:A9 Connected: no
[CHG] Controller 00:18:91:6C:BA:8A Powered: no
[CHG] Controller 00:18:91:6C:BA:8A Discovering: no
[CHG] Controller 00:18:91:6C:BA:8A Class: 0x00000000
For reference, below are/were the stacktraces for both pairing and disconnecting/unpairing:
Pairing stacktrace
#0 0x000055555563ab4f in queue_push_head (queue=0x31, data=0x5555556f6cf0) at src/shared/queue.c:119
#1 0x00005555555ceac8 in g_attrib_send (attrib=0x5555556f6b00, id=0, pdu=0x5555556f6a60 "\022'", len=5, func=0x5555555b272c <report_ccc_written_cb>, user_data=0x5555556f9da0, notify=0x0) at attrib/gattrib.c:327
#2 0x00005555555cd884 in gatt_write_char (attrib=0x5555556f6b00, handle=39, value=0x7fffffffe09e "\001", vlen=2, func=0x5555555b272c <report_ccc_written_cb>, user_data=0x5555556f9da0) at attrib/gatt.c:967
#3 0x00005555555b21b4 in write_char (hog=0x5555556f6a90, attrib=0x5555556f6b00, handle=39, value=0x7fffffffe09e "\001", vlen=2, func=0x5555555b272c <report_ccc_written_cb>, user_data=0x5555556ed080) at profiles/input/hog-lib.c:175
#4 0x00005555555b285e in write_ccc (hog=0x5555556f6a90, attrib=0x5555556f6b00, handle=39, user_data=0x5555556ed080) at profiles/input/hog-lib.c:361
#5 0x00005555555b28f0 in ccc_read_cb (status=0 '\000', pdu=0x5555556e5fa0 "\v", len=3, user_data=0x5555556f8f60) at profiles/input/hog-lib.c:378
#6 0x00005555555cd48c in read_char_helper (status=0 '\000', rpdu=0x5555556e5fa0 "\v", rlen=3, user_data=0x5555556f6e10) at attrib/gatt.c:841
#7 0x00005555555ce8ba in attrib_callback_result (opcode=11 '\v', pdu=0x5555556fb711, length=2, user_data=0x5555556f8480) at attrib/gattrib.c:273
#8 0x0000555555641b0b in handle_rsp (chan=0x5555556d74d0, opcode=11 '\v', pdu=0x5555556fb711 "", pdu_len=2) at src/shared/att.c:820
#9 0x0000555555642082 in can_read_data (io=0x5555556dad90, user_data=0x5555556d74d0) at src/shared/att.c:1018
#10 0x000055555565233a in watch_callback (channel=0x5555556fc4f0, cond=G_IO_IN, user_data=0x5555556f7130) at src/shared/io-glib.c:170
#11 0x00007ffff7e5b4de in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007ffff7e5b890 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007ffff7e5bb63 in g_main_loop_run () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x0000555555652891 in mainloop_run () at src/shared/mainloop-glib.c:79
#15 0x0000555555652dc3 in mainloop_run_with_signal (func=0x5555555d6654 <signal_callback>, user_data=0x0) at src/shared/mainloop-notify.c:201
#16 0x00005555555d6bdb in main (argc=1, argv=0x7fffffffe518) at src/main.c:770
Unpairing stacktrace
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff7b1c55b in __GI_abort () at abort.c:79
#2 0x00007ffff7b75008 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7c81f3e "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3 0x00007ffff7b7c3aa in malloc_printerr (str=str@entry=0x7ffff7c83c30 "double free or corruption (out)") at malloc.c:5339
#4 0x00007ffff7b7e220 in _int_free (av=0x7ffff7cb3b80 <main_arena>, p=0x5555556eecc0, have_lock=<optimized out>) at malloc.c:4314
#5 0x00005555555b476e in report_free (data=0x5555556e5c20) at profiles/input/hog-lib.c:1172
#6 0x00007ffff7e7a998 in g_slist_foreach () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#7 0x00007ffff7e7a9bb in g_slist_free_full () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#8 0x00005555555b4853 in hog_free (data=0x5555556f0460) at profiles/input/hog-lib.c:1194
#9 0x00007ffff7e7a998 in g_slist_foreach () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007ffff7e7a9bb in g_slist_free_full () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x00005555555b480c in hog_free (data=0x5555556eeef0) at profiles/input/hog-lib.c:1189
#12 0x00005555555b5147 in bt_hog_unref (hog=0x5555556eeef0) at profiles/input/hog-lib.c:1445
#13 0x00005555555b1f52 in hog_disconnect (service=0x5555556d0f30) at profiles/input/hog.c:206
#14 0x000055555560bc41 in btd_service_disconnect (service=0x5555556d0f30) at src/service.c:293
#15 0x000055555561aeb2 in disconnect_gatt_service (data=0x5555556d0f30, user_data=0x0) at src/device.c:4824
#16 0x00007ffff7e7a998 in g_slist_foreach () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x000055555561af76 in att_disconnected_cb (err=103, user_data=0x5555556e4e50) at src/device.c:4838
#18 0x0000555555641453 in disconn_handler (data=0x5555556c8ca0, user_data=0x67) at src/shared/att.c:590
#19 0x000055555563add2 in queue_foreach (queue=0x5555556d39d0, function=0x555555641401 <disconn_handler>, user_data=0x67) at src/shared/queue.c:220
#20 0x00005555556416ee in disconnect_cb (io=0x5555556dcd70, user_data=0x5555556dbae0) at src/shared/att.c:657
#21 0x000055555565233a in watch_callback (channel=0x5555556f0cf0, cond=(G_IO_ERR | G_IO_HUP), user_data=0x5555556cfb50) at src/shared/io-glib.c:170
#22 0x00007ffff7e5b4de in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#23 0x00007ffff7e5b890 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#24 0x00007ffff7e5bb63 in g_main_loop_run () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#25 0x0000555555652891 in mainloop_run () at src/shared/mainloop-glib.c:79
#26 0x0000555555652dc3 in mainloop_run_with_signal (func=0x5555555d6654 <signal_callback>, user_data=0x0) at src/shared/mainloop-notify.c:201
#27 0x00005555555d6bdb in main (argc=1, argv=0x7fffffffe518) at src/main.c:770
@haadr do we know if your patch as been released? :) what bluez version should we be looking for? :)
Looks like there's still no new release containing the fix on bluez master, so I guess the release to look/wait for is going to have to be 5.55 (current latest is still 5.54), unfortunately. 5.54 was released in march, so hopefully the next release will be soon.
i was afraid of that... I'm encountering what seems to be bluez crashes on a chromebook, which has 5.54.... how come it takes so long? :/
No idea, looking at it from the outside it feels pretty long :D I'll ask on their IRC channel, maybe someone can tell us something.
Even with a release however, I imagine there's going to be some lag time for how quickly distros are going to bump their versions. It might help if we could compile a list of instructions for various distros for how to compile/update it yourself, if we have users using those distros who are willing to help with that.
General Note I'm not sure if this deserves a new thread, but:
If you get weird connect/disconnect loops, where the minible seemingly connects and disconnects repeatedly, this seems to be caused by the computer (bluez) still being paired to the minible, but the minible no longer being paired to the computer (for instance by having cleared all pairings on the minible). This can be solved by unpairing on the computer/bluez and then re-pairing.
If you for some reason fail to pair (wrong pin entered), sometimes just trying to pair again seems to fail. There seem to be some bugs still in bluez related to cleaning up a device for which the pairing has failed. What has helped me in those cases is disabling and enabling bluetooth on the minible and/or restarting the bluez daemon, bluetoothd.
Interesting... I was indeed encountering this issue....
On Sat, Sep 5, 2020, 10:39 Haakon Drews [email protected] wrote:
General Note I'm not sure if this deserves a new thread, but:
If you get weird connect/disconnect loops, where the minible seemingly connects and disconnects repeatedly, this seems to be caused by the computer (bluez) still being paired to the minible, but the minible no longer being paired to the computer (for instance by having cleared all pairings on the minible). This can be solved by unpairing on the computer/bluez and then re-pairing.
If you for reason fail to pair (wrong pin entered), sometimes just trying to pair again seems to fail. There seem to be some bugs still in bluez related to cleaning up a device for which the pairing has failed. What has helped me in those cases is disabling and enabling the bluetooth on the minible and/or restarting the bluez daemon, bluetoothd.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mooltipass/moolticute/issues/671#issuecomment-687572837, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPCNMYZU7KKYI26D6OA67TSEH2KLANCNFSM4NFIMOOQ .
It seems bluez 55 has started rolling out/being tested. I can't find any release notes on bluez.org, but debian sid is now on bluez 55. I've installed from that source and pairing seems to work fine.
I'd say this bug is resolved, and the only reason for keeping it open is to make it easier for users to find. Even once bluez 55 is released "properly", we'll still have to reference this issue somewhere easy to find for users with older distros.
@haadr I encountered a new bug which seems to be bluez related... would you mind having a look at it?
https://github.com/mooltipass/minible/issues/205