PineTime repeatedly displays passcode when out of range #10

New Issue

brennana · 2022-03-03T22:39:52Z

brennana commented

2022-03-03 22:39:52 +00:00

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

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_

Elara6331 commented

2022-03-04 00:04:49 +00:00

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

Elara6331 changed title from ~~Pinetime constantly displays passcode (part 2)~~ to PineTime repeatedly displays passcode when out of range

2022-03-04 00:05:29 +00:00

Elara6331 added the

Waiting

Bug

labels 2022-03-04 00:05:44 +00:00

earboxer commented

2022-03-21 23:14:44 +00:00

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).

Elara6331 commented

2022-03-26 00:19:18 +00:00

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).

Elara6331 commented

2022-03-26 00:20:32 +00:00

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.

Elara6331 added this to the 0.0.5 milestone 2022-04-02 20:02:02 +00:00

earboxer commented

2022-04-05 17:47:08 +00:00

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).

earboxer commented

2022-04-05 19:43:49 +00:00

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?)

Elara6331 referenced this issue from a commit

2022-04-16 11:25:11 +00:00

Log when too many disconnects occur rather than removing the device (Arsen6331/itd#10)

Elara6331 referenced this issue from a commit

2022-04-16 11:29:02 +00:00

Use new changes in infinitime library to stop removing InfiniTime devices (Fixes #10)

Elara6331 closed this issue

2022-04-16 11:29:02 +00:00

Elara6331 referenced this issue from a commit

2023-04-21 02:08:29 +00:00

Use new changes in infinitime library to stop removing InfiniTime devices (Fixes #10)

Sign in to join this conversation.