After daemon restart, previously added device won't reconnect. Reproducible: Always Steps to Reproduce: 1. Add a BT device (tested with Logitech M555b mouse via bluetoothctl pair-trust-connect) 2. Restart bluetoothd Actual Results: Added device won't reconnect Expected Results: Previously added device will restore connection The device key is present in '/var/lib/bluetooth/<adapter:addr>/<device:addr>/info' under [LinkKey]. When I restart bluetoothd (hibernate/thaw, manual daemon or system restart), running '/usr/libexec/bluetooth/bluetoothd -dn' will produce: > src/adapter.c:load_link_keys() hci0 keys 0 debug_keys 0 When I'll move the mouse I'll get these lines in syslog: > bluetoothd[1234]: Refusing input device connect: No such file or directory > (2) > bluetoothd[1234]: Refusing connection from xx:xx:xx:xx:xx:xx: unknown device Then '/var/lib/bluetooth/<adapter:addr>/<device:addr>/info' will be removed and recreated with an other key, if I'll add the mouse again.
Created attachment 142661 [details] changes to src/adapter.c If I change src/adapter.c like this, bluetoothd will read the stored key and connect to the device: > src/adapter.c:load_link_keys() hci0 keys 1 debug_keys 0
The DT_DIR check is supposed to ensure that '/var/lib/bluetooth/<adapter:addr>/<device:addr>/' is a directory. Your patch seems to change the code to skip any entries under '/var/lib/bluetooth/<adapter:addr>/' that are *not* directories. Can you explain why that fixes the issue for you? (since otherwise the patch looks wrong to me).
This could happen if filesystem doesn't support d_type. In such case d_type is DT_UNKNOWN and we shoud handle that. With attached patch bluetoothd will fallback to lstat(). Aleksei, could you test if this solves your problem?
Created attachment 142671 [details] fallback to lstat
Created attachment 142711 [details] Alternate patch DT_UNKNOWN could indeed be the cause of this, but I'd avoid modifying the already largish loop by having a helper function for the lstat call. Either way it'd be good to know if one of the patches fixes the issue. It'd also be good to know exactly what kind of setup you have (libc version, kernel version, filesystem type, etc). Some unrelated notes: PATH_MAX already contains the terminating null so +1 is unnecessary. Also, snprintf (unlike strncpy) guarantees a terminating null so no need to force that after the call. Both of these issues should probably be fixed in many places of the code base.
(In reply to Szymon Janc from comment #3) > This could happen if filesystem doesn't support d_type. Appears to be the case, my /var is on reiserfs. Didn't insist the patch is correct, it was merely RFC. Will check proposed patches shortly.
(In reply to Johan Hedberg from comment #5) > It'd also be > good to know exactly what kind of setup you have (libc version, kernel > version, filesystem type, etc). See here: https://516600.bugs.gentoo.org/attachment.cgi?id=380364
Both patches in attachment 142671 [details] and attachment 142711 [details] fix the issue
Fixed in BlueZ 5.22