Need a way for non-elevated user to restart daemon

[joedevsys]

CRITICAL: On a communication aid using Windows the end user cannot restart the service because that command needs to be elevated. Even if the logged in user has admin rights if a restart batch file is called from a communication aid grid cell it is not elevated. Several of the methods that could elevate the call trigger the UAC admin login dialog which is not accessible to people with complex access needs.

[willwade]

Ok. Just before I head off to this what situations do you need to restart it? (There we’re a couple like resetting the paired devices list but we’ve fixed that recently)

[joedevsys]

Where the dongle can't be left plugged in to a communication aid permanently then when you plug it in again the service needs to be restarted. (I suspect this is because the port has been closed and needs to be reopened by the service). User's personal assistant might be able to physically plug in on request but expecting them to perform elevated windows commands on the voca is a tall order. User can have an onscreen button that does the restart (much in the same way they have one to restart SMS connections to phones).
There are other circumstances such as a target device being reluctant to restore HID despite restortion of BT connection e.g. after loss of signal (sleep? separation? reboot?) unless you've fixed this.
Maybe daemon should monitor itself and reopen the port automatically (would need to keep retrying indefinitely until the dongle is plugged in, and without blocking the machine)?

[joedevsys]

After more testing (i13, Windows 10, Bluefruit friend, RelayKeys v1.7) it does seem to be only needed after removing and plugging the dongle back in. Loss of signal/reboot of either device seems to reconnect automatically.

[willwade]

Ok - I think we can fix that - In fact - I think we dont see the problem on a feather. No idea why.. But I'll check. (Im still waiting for that to get to you BTW - thank covid for the delay!)

[willwade]

Just to add to this for my notes Running this https://github.com/AceCentre/RelayKeys/blob/master/relaykeysd-service-restart.bat - doesn't work - has the following output. ie needs to be elevated

In here somewhere lies an answer https://stackoverflow.com/questions/15496893/start-a-windows-service-without-elevation - but nothing looks simple.

NB: Fixes would lie in https://github.com/AceCentre/RelayKeys/blob/master/relaykeysd-service.py and

RelayKeys/build-installer.nsi

Line 133 in 452f70d

; SimpleSC Plugin: https://nsis.sourceforge.io/NSIS_Simple_Service_Plugin

[willwade]

Now fixed under PR #96 TY @f1andrew :)
Now is a application relaykeysd-service-stop.exe in the install directory. Restarting using batch script should now work.
Might need some testing @joedevsys All released under https://github.com/AceCentre/RelayKeys/releases/tag/1.9

[joedevsys]

Doesn't work for me. Running relaykeysd-service-restart.bat results in this:
Traceback (most recent call last):
File "relaykeysd-service.py", line 39, in
pywintypes.error: (1063, 'StartServiceCtrlDispatcher', 'The service process could not connect to the service controller.')
[6556] Failed to execute script 'relaykeysd-service' due to unhandled exception!

Also fails the same way if run elevated.

[joedevsys]

I've created a pull request #98 as an alternative way of doing this, implementing a cli reconnection command.
Example usage;

• physically remove dongle and re-insert later
• daemon now fails to communicate properly with dongle as port is closed, dongle not initialised
• use cli command ble_cmd:reconnect
• port reopened, dongle re-initialised, communication with dongle now works

For debate whether this is the best command naming.

This needs more testing - it seems to reconnect to the dongle reliably and the remote computer seems to reconstruct the HID input routing, but I have yet to prove the latter is consistent.

[willwade]

Thanks Joe. For the record we rolled back our script..

And I'll quote Joe here as an idea for us to mull on:

"I wondered if the reconnect code can be called automatically after a fail and then the quoted command retried but have to avoid endless tries, and I think it would need a considerable delay as it takes the remote some time to accept the reconnection. So maybe best left to the user?? They'll know if the dongles been replugged."

@f1andrew - any thoughts?

[joedevsys]

After further testing I can report ble_cmd:reconnect does reliably recover the comms to the dongle after removal/re-insertion on both BLE Friend and an ItsyBitsy nrF against multiple targets. Easy to drive from a voca.

It would be ideal if this was automatic, but current implementation is ok.

Does ble_cmd:reconnect need adding to the ble loop for wireless mode? Might need slightly different actions?

[joedevsys]

Closing as ble_cmd:reconnect does the job. Automating it now moved to a feature request.