import/export pairs

[kabessao]

Describe your request

in my computer I have 2 users that I alternate when I'm working and when I'm not, and it would be nice to have my phone pair shared between those two users.

Proposed solution

It would be great if I could export all the info needed to connect to my phone so I can import it to the other user to have a seamless experience changing users.

Alternatives

An alternative would be an explanation on how to "clone" all the configs from one user to the other

GSConnect version

54

Installed from

Extension Manager

GNOME Shell version

43.2

Linux distribution/release

Nobara Linux (Fedora) 37

Additional context

I'm not sure if I can do that on KDE Connect, so I apologize in advance if my feature request is not possible.

[ferdnyc]

@kabessao

in my computer I have 2 users that I alternate when I'm working and when I'm not, and it would be nice to have my phone pair shared between those two users.

It would be great if I could export all the info needed to connect to my phone so I can import it to the other user to have a seamless experience changing users.

That won't work the way you'd want it to, I'm afraid.

If you could do what you're asking, you wouldn't actually need to. Both GSConnect and KDE Connect Android support multiple pairings, so if it were possible to use GSConnect from two different user accounts on the same machine, you could just set up two separate pairings and switch between them without issue. But the problem isn't the configuration.

When you switch users on a Linux machine, the first user account is still running in the background, which means that the GSConnect daemon for user1 is still active and still connected to that host's port 1716. When GSConnect tries to run for user2 on login, its connection attempt to port 1716 fails (it's already in use), so it can't communicate with your phone.

Having a shared config wouldn't change that. It's a fundamental design flaw in the KDE Connect protocol, that only one instance of KDE Connect can be running on a given host at any time, because it has to take exclusive control of port 1716 in order to be reachable.

There's unfortunately no way around the limitation, short of a new version of the protocol that provides for multiple listeners per host. (Which would then also have to be implemented for the Android app, and the Linux kdeconnectd, as well as GSConnect.)

Sorry! :disappointed:

[ferdnyc]

Prior discussion: #551

[kabessao]

Sorry for commenting on a closed issue, but I've noticed that in the recent version of Gnome that GSConnect is a toggle button, when I disable it does it liberates the port ? Because when I toggle it off I still can't pair it with my phone. Do I need to disable the extension first on the first user to pair it to the second user ?

[ferdnyc]

@kabessao No, no, that's quite alright. The whole reason we close issues, but don't lock them like some projects do, is that there's always room for followup and potentially even reopening an issue. The Closed state is no more final than any other.

when I disable it does it liberates the port ? Because when I toggle it off I still can't pair it with my phone. Do I need to disable the extension first on the first user to pair it to the second user ?

That... was an excellent question that I could not remember the answer to. So, I tested it.

A deactivated GSConnect (toggled off in the GNOME 43 User Menu) does indeed detach from port 1716. Which, in theory should allow you to pair from another GSConnect instance running as a different user.

If it doesn't, then I suspect the issue is on the Android side. Because the KDE Connect protocol wasn't designed to share hosts, the Android app may keep track of its pairings partly by IP address. (And by "may" I mean, I'm 90% sure it "does". For starters, paired devices are listed by the host's name, not the user on that host.) That would likely preclude multiple pairings from the same host.

(IOW, I may have been incorrect, when I said earlier that you "could" do that if not for the port contention. GSConnect should have no problem with it! In fact, I've had two different phones paired from the same IP address on my local network, because they both happened to get that same IP from the DHCP server. ...But GSConnect is only half the equation.)

Cloned configs

So, now that brings us back to the question of whether "cloning" your configs from one user to another would be useful. Provided you're willing to accept the limitation of needing to deactivate GSConnect before switching users, it might be a path to getting the Android app on board.

It's probably worth a try, at least! It wouldn't take much to achieve. Basically, you'd need to copy two... no, probably three things:

• The entire contents of $HOME/.config/gsconnect/
• The DConf settings tree for the GSConnect device to be cloned
• The DConf keys for GSConnect's id, which is the UUID it uses to identify itself to other devices, and its list of devices with configuration available.

The first could just be recursively directory-copied from ~user1/.config/gsconnect to ~user2/.config/gsconnect (with ownership/permissions updated accordingly).

The latter two, this is off the top of my head but should approximate the steps to copy the relevant data:

As user1

dconf read /org/gnome/shell/extensions/gsconnect/id
#   => A 'device-uuid-string' that can be stored somewhere for later use

dconf read /org/gnome/shell/extensions/gsconnect/devices
# => A list of device identifiers; if you only have one paired device,
#    it'll be the only thing on the list and that's easy. Otherwise,
#    you can check the identity of each device 'xxxxxdev' with:
dconf read /org/gnome/shell/extensions/gsconnect/device/xxxxxdev/name
# => The "pretty" device name that's shown by GSConnect

# Once you've found the correct device identifier, note that as well,
# and dump its settings tree to a file with,
dconf dump /org/gnome/shell/extensions/gsconnect/device/xxxxxdev/ > somefilename.conf

As user2

• Armed with the GSConnect ID, the device ID, and the .conf file for the device...

# Set GSConnect's ID the same as for user1
dconf write /org/gnome/shell/extensions/gsconnect/id 'device-uuid-string-from-before'

# Set the list of paired devices to match user1
dconf write /org/gnome/shell/extensions/gsconnect/devices "['xxxxxdev']"

# Import the exported device configs
dconf load /org/gnome/shell/extensions/gsconnect/device/xxxxxdev/ < somefilename.conf

DConf will automatically create the root node for the /org/gnome/shell/extensions/gsconnect/device/xxxxxdev/ tree, before populating it from the file. (In fact, you could change the device identifier to anything you wished, here, and it would load the configs into the location specified. But, the whole point here is to use the same identifier.)

Oh, and needless to say you'd want to do all of the user2 stuff with GSConnect... heck, probably uninstalled completely, at least while the DConf manipulations are underway. For sure not running at all, in that account. It's worth triple-checking that before you begin, just to be safe. (daemon.js can be sneaky!)

...If you decide you're interested in trying this silliness, definitely please do report back with results. Especially if it actually works! (But, even failures would be informative, and might lead to better solutions.)

I suppose it's not outside the realm of possibility that, if this kooky plan does actually work, it could be made a supported (and safer) Actual Feature™ of GSConnect.

(Assuming GNOME Shell provides some way for extensions to detect when the current account is being backgrounded by a user switch, since it doesn't seem worth it without the ability to automatically switch between instances. ...Experience tells me not to get my hopes up, when it comes to anything dependent on a particular Shell-provided feature. But, heck — a little optimism never hurt anyone, right?¹)

Notes

1. (I'm being told that's false, and foolish optimism has in fact done immense amounts of harm to many, many people.)

[ferdnyc]

Two things:

1. I realized, after writing all of that, that it's also possible I'm completely off base here. It could be that the real issue is something stupid, like GNOME Shell reactivating GSConnect for user1 when the switch to user2 happens,

   I don't think that's the case, but it's probably worth checking first, before going to all the trouble of fiddling with cloned settings. Especially since it's so easy to check:

   1. Deactivate GSConnect for user1
   2. Switch to user2
   3. (Make sure GSConnect is also deactivated, or better yet not installed, for user2.)
   4. You may need to sudo dnf install net-tools, to have the netstat command available.
   5. Run sudo netstat -tan |grep ':1716'

   If you get a line like this, then something is still bound to that port:

   tcp6       0      0 :::1716                 :::*                    LISTEN     
   

   If there's no output, then you're in the clear, port 1716 is free, and in theory, user2 should be able to activate GSConnect for their account.

2. I thought I should mention, the trailing slashes are crucial in those dconf {dump|load} /some/path/to/a/dconf/tree/ commands. Without the trailing slash, dconf will just complain instead of dumping/loading any configs. Because dconf is a pain in the ass.

[kabessao]

Thanks for the response, I'll gladly do the first test because I like to experiment on things, I just can't do it now because I'm at work at the moment, but as soon as I'm free I'll do it.

Now about the test you gave me for the port usage, I've toggled off GSConnect on user1 and went to user2, and indeed the port is not in use anymore, but before that I uninstalled GSConnect from the user2 just to make sure, and when I installed it again I was able to pair my phone with user2, but somehow it invalidated the pair in user1, so I tried and paired the user1 again and somehow now both of them work, of course provided I turn off GSConnect from the user I'm not using. Now it's worth noting that before I even wrote this issue I did the thing you mentioned about copying .config/gsconnect to user2 (I even copied .cache/gsconnect to make sure) to see if that would do the trick, so I don't know if that helped or not. All I know is that somehow it's working fine now.

[daniellandau]

I would sure hope that the IP address isn't used to identify pairs, as addresses change and everyone has 192.168.0.0/24 anyways (oversimplified). I don't know what went wrong with the copying configs around solution, but pairing separately seems to me a much safer approach.

[kabessao]

@daniellandau it seems it does, but it doesn't affect the pair. I was able to pair my phone on 2 different users, but it doesn't show as 2 different pc's on the android app, it identifies the pc as the last name connected. For example I have the user1 as "default" and user2 as "work". If I last connected to the user1 the computer's name will show as "default" on the app, and if I connect to the user2 the computer's name will show as "work". The configs seems to be the same on the app side as well, since if I change one config while connected to user1 it stays the same when connected to user2.

Edit: sorry, I misread what you wrote, I meant to say it uses the same identifier for the pc in both the users.