Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot pair with GSConnect #52

Open
jameswestman opened this issue Jul 16, 2020 · 2 comments
Open

Cannot pair with GSConnect #52

jameswestman opened this issue Jul 16, 2020 · 2 comments

Comments

@jameswestman
Copy link

I'm attempting to pair a device running mconnect with a separate device running GSConnect. I solved my first problem in #51. After that, the first time I pair the device (using mconnectctl) it works correctly. However, if I restart the mconnect daemon, it gets stuck in a loop of sending and receiving pair packets:

** (mconnect:414689): DEBUG: 04:29:25.394: devicechannel.vala:283: check for IO, conditions: 0x1
(mconnect:414689): GLib-Net-DEBUG: 04:29:25.394: SERVER[0xaaaae4ba0410]: starting to read data from TLS connection
(mconnect:414689): GLib-Net-DEBUG: 04:29:25.395: SERVER[0xaaaae4ba0410]: claiming operation OP_READ
(mconnect:414689): GLib-Net-DEBUG: 04:29:25.395: SERVER[0xaaaae4ba0410]: claiming operation OP_READ succeeded
(mconnect:414689): GLib-Net-DEBUG: 04:29:25.395: SERVER[0xaaaae4ba0410]: yielding operation OP_READ
(mconnect:414689): GLib-Net-DEBUG: 04:29:25.395: SERVER[0xaaaae4ba0410]: successfully read 67 bytes from TLS connection
** (mconnect:414689): DEBUG: 04:29:25.395: received line: {"id":1594873765372,"type":"kdeconnect.pair","body":{"pair":true}}
** (mconnect:414689): DEBUG: 04:29:25.395: packet type: kdeconnect.pair
** (mconnect:414689): DEBUG: 04:29:25.395: got packet
** (mconnect:414689): DEBUG: 04:29:25.395: device.vala:418: pair in progress: false is paired: true pair: true
** (mconnect:414689): DEBUG: 04:29:25.396: device.vala:433: unsolicited pair change from device, pair status: true
** (mconnect:414689): DEBUG: 04:29:25.396: device.vala:275: start pairing
** (mconnect:414689): DEBUG: 04:29:25.396: devicechannel.vala:229: send data: {"type":"kdeconnect.pair","id":1594873765396,"body":{"pair":true}}

(mconnect:414689): GLib-Net-DEBUG: 04:29:25.396: SERVER[0xaaaae4ba0410]: starting to write 67 bytes to TLS connection
(mconnect:414689): GLib-Net-DEBUG: 04:29:25.396: SERVER[0xaaaae4ba0410]: claiming operation OP_WRITE
(mconnect:414689): GLib-Net-DEBUG: 04:29:25.396: SERVER[0xaaaae4ba0410]: claiming operation OP_WRITE succeeded
(mconnect:414689): GLib-Net-DEBUG: 04:29:25.396: SERVER[0xaaaae4ba0410]: yielding operation OP_WRITE
(mconnect:414689): GLib-Net-DEBUG: 04:29:25.396: SERVER[0xaaaae4ba0410]: successfully write 67 bytes to TLS connection
** INFO: 04:29:25.396: devicemanager.vala:190: device 4ca325d8-9f98-40c6-bb36-0ca26e2c6510-jamesdesktop-desktop-7 pair status change: true
** (mconnect:414689): DEBUG: 04:29:25.397: cache file: /home/mobian/.cache/mconnect/devices
@jameswestman
Copy link
Author

If I comment out src/mconnect/device.vala:311, it seems to work. I'm not quite sure this is the right solution, though, since I'm not too familiar with KDE Connect or this codebase. It does make sense that if we start a connection and we're already paired, we shouldn't attempt to pair again.

@andyholmes
Copy link
Contributor

I think you are right.

A client should never request a pair when it already thinks it's paired. This is because the local device can request a pair if it mistakenly thinks it's unpaired, since the remote device should automatically respond as though it has accepted the request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants