Bastien Nocera:
On Thu, 2024-07-04 at 16:30 +0200, usul@xxxxxx wrote:
Am 4. Juli 2024 16:17:32 MESZ schrieb Luiz Augusto von Dentz
<luiz.dentz@xxxxxxxxx>:
Hi Bastien,
On Thu, Jul 4, 2024 at 4:20 AM Bastien Nocera <hadess@xxxxxxxxxx>
wrote:
On Wed, 2024-07-03 at 13:31 -0400, Luiz Augusto von Dentz wrote:
<snip>
@Bastien Nocera do you happen to know why gnome not register a
pairing
agent? Ive seem quite a few reports of things not working after
rebooting lately which hints to No-bonding pairing happening or
perhaps fedora uses main.conf:AlwaysPairable?
There hasn't been a pairing agent in GNOME outside the Bluetooth
Settings panel for more than 10 years.
I've never seen this being a problem before.
Fedora uses the main.conf shipped by bluez with no changes
(except
AutoEnable to true, which does nothing as it's already the
default):
https://src.fedoraproject.org/rpms/bluez/blob/rawhide/f/bluez.spec#_196
Hmm, so if you got a incoming pairing request there is nothing to
respond to authentication? Well even in that case it doesn't
explain
why there was no agent while setting up a new device, or perhaps
that
is not how setting up new devices works nowadays? Jonas, did you
use
the gnome setting panel to set it up or did you use something else?
When initial pairing was done with the gnome settings, I would not be
able to reconnect after reboot. Now that I did the pairing with
bluetoothctl, it survives a reboot.
Sorry to report back a week later, I just had time do run a few more tests.
First result: The pairing now works as expected both when done via the GNOME UI and when done with bluetoothctl. I have no idea what happened, none of the kernel, bluez or gnome-bluetooth packages have been updated.
I have no idea what the difference could be between pairing with GNOME,
or pairing with bluetoothctl, there really shouldn't be any difference.
There is one difference though: in /var/lib/bluetooth/<controller>/<device>/info I find "Trusted=true" when connecting with GNOME UI and "Trusted=false" when connecting with bluetoothctl. Not sure if that means anything and of course I could set it to trusted from bluetoothctl as well.
Would be good to capture both cases to see whether there's any
difference, checking the /var/lib/bluetooth files after pairing in each
case might also show some differences.
The logs for this are huge (i.e. especially as I'm working in public spaces and many devices are around. I have no idea what specifically to look for, and as both ways seem to work now, I think it does not matter anymore.
The device looks like it supports pairing to multiple computers (look
at the channel display at the bottom:
https://www.cherry-world.com/gentix-bt
Maybe that's part of the problem?
The device has a button to change between 3 different "channels". What it actually does is that each "channel" is assigned a different device ID. When pushing the pairing button on a certain channel, a new - apparently random - ID gets assigned to the selected "channel". Of course I took care not to accidentally change the active "channel" during my earlier tests. When it did not work earlier, I know it was available with the same device ID, but would not allow the encrypted connection to set up after a restart. Let's see if it happens again.
Cheers
The connection still breaks once in a while (about 5x per day) and
then needs a few seconds to repair itself. But that might be a
different problem. I'll try to capture a log of this as well.
(Sorry, re-sending because my mobile phone didn't accept answer-to-
all)
This still happens once in a while. I'm not sure if some disconnects (like once every 2 hours) are to be expected on a bluetooth connection? They are still very annoying, especially when I'm doing thing like moving items around with the mouse (design/layout work) and then suddenly the connection is lost.
Thanks again for your help. I will make a new report once I have captured a suitable log of the latter problem.
Cheers
Jonas
