PineTime repeatedly displays passcode when out of range #10

Closed
opened 11 months ago by brennana · 6 comments

Built itd-git from AUR (2f14e70721) on Pinephone Pro w/ Manjaro/KDE.

I first started itd with my watch already paired, and the daemon was working just fine. However, upon walking some distance away from my phone, this exact issue (unending successive BLE pair-codes appearing on watch) occurs.

Restarting the daemon only causes it to crash with a single error: FTL Error connecting to InfiniTime error="Authentication Failed". Performing a full re-pair in bluetoothctl fixes this problem (until again walking too far away from the phone, and the process must be repeated).

So long as a close distance to the phone is maintained, this doesn't seem to be an issue.

Originally posted by @brennana in #8

Built itd-git from AUR (2f14e70721) on Pinephone Pro w/ Manjaro/KDE. I first started `itd` with my watch already paired, and the daemon was working just fine. However, upon walking some distance away from my phone, this exact issue (unending successive BLE pair-codes appearing on watch) occurs. Restarting the daemon only causes it to crash with a single error: `FTL Error connecting to InfiniTime error="Authentication Failed"`. Performing a full re-pair in `bluetoothctl` fixes this problem (until again walking too far away from the phone, and the process must be repeated). So long as a close distance to the phone is maintained, this doesn't seem to be an issue. _Originally posted by @brennana in https://gitea.arsenm.dev/Arsen6331/itd/issues/8#issuecomment-92_
Owner

I believe this is a different issue. I completely rewrote the pairing and reconnect code. I think what's happening is that the companion tries to pair but disconnects immediately, prompting it to try reconnecting. When 5 disconnects occur too fast, the PineTime gets removed (because at that point I assume something is wrong) from Bluetooth and has to be paired again. Then, the code is displayed constantly because you are too far and the pairing code keeps trying to reconnect.

To fix this, I need to think of what to do when too many disconnects happen that doesn't involve removing the device.

I originally did this because of issues in Bluetooth that caused my PineTime to constantly disconnect after reboot. That issue seems to be fixed in InfiniTime's develop branch, so I will try to remove it when they release 1.9.0

I believe this is a different issue. I completely rewrote the pairing and reconnect code. I think what's happening is that the companion tries to pair but disconnects immediately, prompting it to try reconnecting. When 5 disconnects occur too fast, the PineTime gets removed (because at that point I assume something is wrong) from Bluetooth and has to be paired again. Then, the code is displayed constantly because you are too far and the pairing code keeps trying to reconnect. To fix this, I need to think of what to do when too many disconnects happen that doesn't involve removing the device. I originally did this because of issues in Bluetooth that caused my PineTime to constantly disconnect after reboot. That issue seems to be fixed in InfiniTime's develop branch, so I will try to remove it when they release 1.9.0
Arsen6331 changed title from Pinetime constantly displays passcode (part 2) to PineTime repeatedly displays passcode when out of range 11 months ago
Arsen6331 added the Waiting Bug labels 11 months ago

To fix this, I need to think of what to do when too many disconnects happen that doesn't involve removing the device.

Maybe just wait longer before retrying.

(as a side-note, it's kind of strange for a daemon to prompt for the passcode, I would expect the daemon to run in the background, maybe pairing could be done with itctl if not already done by the OS).

> To fix this, I need to think of what to do when too many disconnects happen that doesn't involve removing the device. Maybe just wait longer before retrying. (as a side-note, it's kind of strange for a daemon to prompt for the passcode, I would expect the daemon to run in the background, maybe pairing could be done with itctl if not already done by the OS).
Owner

To fix this, I need to think of what to do when too many disconnects happen that doesn't involve removing the device.

Maybe just wait longer before retrying.

(as a side-note, it's kind of strange for a daemon to prompt for the passcode, I would expect the daemon to run in the background, maybe pairing could be done with itctl if not already done by the OS).

Unfortunately, while the OS is supposed to do the prompting, it's very inconsistent in terms of different desktop environments. Works well in GNOME/Phosh, but not in KDE and many others. I have it set up to ask in the terminal if it's running there or display a GUI dialog if it's in the background (via systemd or otherwise).

> > To fix this, I need to think of what to do when too many disconnects happen that doesn't involve removing the device. > > > Maybe just wait longer before retrying. > > (as a side-note, it's kind of strange for a daemon to prompt for the passcode, I would expect the daemon to run in the background, maybe pairing could be done with itctl if not already done by the OS). Unfortunately, while the OS is supposed to do the prompting, it's very inconsistent in terms of different desktop environments. Works well in GNOME/Phosh, but not in KDE and many others. I have it set up to ask in the terminal if it's running there or display a GUI dialog if it's in the background (via systemd or otherwise).
Owner

Maybe just wait longer before retrying.

That's not really the issue. The problem is that sometimes, the bond stops working and the watch refuses to connect. This means the watch has to be removed and re-paired.

> Maybe just wait longer before retrying. That's not really the issue. The problem is that sometimes, the bond stops working and the watch refuses to connect. This means the watch has to be removed and re-paired.
Arsen6331 added this to the 0.0.5 milestone 10 months ago

Maybe just wait longer before retrying.

That's not really the issue. The problem is that sometimes, the bond stops working and the watch refuses to connect. This means the watch has to be removed and re-paired.

From my testing, it seems like this only happens after the watch is flashed with a new firmware. (I've been running itd with infinitime library patched with the defaultAdapter.RemoveDevice(dev.Path()) lines commented out these last two weeks.)

(In my other script where I sent notifications, I run bluetoothctl --timeout 5 connect XX:XX:XX:XX:XX:XX to reconnect when the connection is lost because of range)

So I think something in flashing the firmware broke the bluetooth pairing?

(I had been running InfiniTime 1.8.0, but briefly upgraded to 1.9.0, then reverted since I thought something had gone wrong).

If this theory is correct, we could check itctl firmware version before deciding to remove a device (but this might be inconvenient for people who develop firmware and flash often).

> > Maybe just wait longer before retrying. > > That's not really the issue. The problem is that sometimes, the bond stops working and the watch refuses to connect. This means the watch has to be removed and re-paired. From my testing, it seems like this only happens after the watch is flashed with a new firmware. (I've been running itd with infinitime library patched with the `defaultAdapter.RemoveDevice(dev.Path())` lines commented out these last two weeks.) (In my other script where I sent notifications, I run `bluetoothctl --timeout 5 connect XX:XX:XX:XX:XX:XX` to reconnect when the connection is lost because of range) So I think something in flashing the firmware broke the bluetooth pairing? (I had been running InfiniTime 1.8.0, but briefly upgraded to 1.9.0, then reverted since I thought something had gone wrong). If this theory is correct, we could check `itctl firmware version` before deciding to remove a device (but this might be inconvenient for people who develop firmware and flash often).

Unfortunately, while the OS is supposed to do the prompting, it's very inconsistent in terms of different desktop environments. Works well in GNOME/Phosh, but not in KDE and many others. I have it set up to ask in the terminal if it's running there or display a GUI dialog if it's in the background (via systemd or otherwise).

I just needed to have zenity in my path and it worked great! Thanks! (I'm running itd through superd, launched by sway). (KDE users should install qarma to make it work?)

> Unfortunately, while the OS is supposed to do the prompting, it's very inconsistent in terms of different desktop environments. Works well in GNOME/Phosh, but not in KDE and many others. I have it set up to ask in the terminal if it's running there or display a GUI dialog if it's in the background (via systemd or otherwise). I just needed to [have zenity in my path](https://github.com/gen2brain/dlgs/blob/master/dlgs_linux.go) and it worked great! Thanks! (I'm running itd through [superd](https://sr.ht/~craftyguy/superd), launched by sway). (KDE users should install qarma to make it work?)
Arsen6331 closed this issue 10 months ago
Sign in to join this conversation.
Loading…
There is no content yet.