Connections issues - none of my device will go 2-way

[baldyman01]

I have 1.82 installed on a Samsung S20, a Samsung Galaxy tab 5e, two older Sony Xperia tablets, and my Linux Mint desktop. Things generally detect other things although this is not 100%, but nothing will go 2 way with anything else. I just end up with explanation marks. I've restarted everything and as it stands the S20 will go 2-way with the Desktop, one of the Sony's says it's 2 way with the Tab 5e but the other one won't and the Tab 5e just gives me explanation marks.

I can't seem to find any logic as to what will connect to what when. How do I go about diagnosing this mess?

Suffering from the same issue.. This so called program had been patched to oblivion but to no avail, it's just another FOSS mess. My PC (Linux Mint) and Android (Samsung Galaxy A52s 5G) keeps getting disconnected / unpaired on their own, sometimes in the middle of a transfer, while my phone's screen is not even locked, I also made sure to put this app on the whitelist so it won't get auto suspended on the phone, but to no avail, the app just kees acting as an old man with dementia, and sometimes even forcing pair with QR code solves the issue for a handful of 1minute, then it just unpairs again...

I'm using LocalSend in the meantime, at least that one works (however that's slow as a slug, but still, works), but Warpinator would be the best because of the great speed it has.

[TwistedC0de]

I think it would be helpful if you guys can provide logs of your issues.

[baldyman01]

Yep LocalSend seems to be the answer. I have old and new android all interoperating correctly with my Linux desktop.

I'll have another go with Warpinator to see if I can get any logs out of it, but the difference with LocalSend is night and day.

[TwistedC0de]

Initially I was using sftp to transfer files from my PC to phone. Which was kind of slow and LocalSend was only slightly faster.
I think KDE Connect is the next fastest option.
But Warpinator is the fastest (if you can get it to work 😄) so far I have tired.

[slowscript]

@vajdao Your unpairing issue could be caused by the system clocks running slightly out of sync and triggering a race condition in the connection keep-alive mechanism of gRPC. I have tweaked the keep-alive values in version 1.8.3, which should fix the problem if my guess is correct (I cannot know without a log).

@baldyman01 I would really need to see the logs of both sides that are having issues. There are instructions on how to get the logs in the recently updated troubleshooting tips.

[toofyspooder]

I have v1.8.6 installed on PopOS and v1.8.3 on my S24U. The desktop will show up on Android but it says the desktop didnt connect back and fails the connection. My android never shows up on the desktop at all.

If I do a manual connection it works fine, but having them see each other automatically would be preferable.

Firewall is turned off for troubleshooting and same issue.

@vajdao Your unpairing issue could be caused by the system clocks running slightly out of sync and triggering a race condition in the connection keep-alive mechanism of gRPC. I have tweaked the keep-alive values in version 1.8.3, which should fix the problem if my guess is correct (I cannot know without a log).

All my systems are hooked up with ntp timeserver including my phone, they are ticking on the same time, with absolute accuracy, like a metronome. The logs ain't generate in any way which is odd (I cannot provide one without generating itself)

1.8.3 have slightly better stability in terms of maintained connection, but still not as perfect as KDE Connect which stays connected with my PC - no matter what. I think it would be wise to look into their code for some inpspiration.

[alek3y]

Kind of having the same issue on 1.8.3.
I collected logs for two devices: maple (Android 15) and tea (Android 14), both of which are on the same network as navi (Linux desktop).

What happened during the capture was that navi only connected to maple, tea failed to connect to both and maple connected (two arrows icon) to navi and tea.

maple.log
tea.log

P.S.: It also feels like opening the app at the same time causes both phones to almost always fail connection with the desktop app. Excluding the desktop from the network doesn't improve connection between the two phones either.

[slowscript]

Thanks @alek3y, this is what I need. I have now released an update which could help with a part of your issue (navi -> tea). It seems to be something I suspected a while back.

In the log I see that tea connected to navi, although the log seems cut off, so I might not have the same time frame as you are talking about and there might be another problem... This prompted me to discover an issue with the "Save log" option, which was also fixed and should now always export the whole log from the time the app starts to the time of saving (plus the toggle in the settings is no longer necessary, maybe except for diagnosing crashes).

Let me know if v1.8.4 fixed (at least some part of) your issue. If not, please be so kind and try to get another log. Thanks again!

[alek3y]

Unfortunately the situation doesn't seem to have improved. Similarly to last time, neither connected to navi, tea connected to maple but not viceversa. The logs contain multiple attempts so I'd look at them starting from the bottom, as this situation happened at around 11:24.

Last time I copied latest.log (after closing the app) instead of using the "Save log" button, but it still seems to be cut off on 1.8.4. To make sure everything is included though, I'm sending the one exported with the button.

maple.log
tea.log

At the end of the logs for tea there should also be a situation where the device would only list maple and not navi, despite maple being able to see it.

[slowscript]

Thanks @alek3y, the new logs are complete. The "Save log" button is now the preferred method to get logs when possible (except in case of a crash).

In the previous logs I just saw a no duplex issue but interpreted it the wrong way, but now I might be getting somewhere. I went through the logs much more thoroughly and I got a couple of things.

First, the phones are connecting to each other via API v1, because the service is first discovered without the API version information. This is likely caused by the service announcement being split into two packets for some reason, which does not happen on my devices. This has now been fixed.

Second, the connection between phones succeeds 2 out of 5 times, once there is one-way connection tea->maple, and 2 times it fails entirely. Due to using API v1 the connection process just hangs (there is no timeout) without providing info on why it is not connecting. One time there is a mention of connection reset, which might mean an issue on a lower level during TCP handshake or something like that, not sure what would be causing that.

Third, the connection of the phones to navi fails because navi cannot connect to the main service on port 42000 of the phones. It does however successfully get their certificates from the registration service (port 42001), so likely not a network issue.

It would be nice to see a log from navi. The Linux version uses a different gRPC implementation that might give more details for why it's not connecting. Unfortunately in order to get any message more descriptive than "timeout", you need to disable the line future.result(timeout=4) in file /usr/libexec/warpinator/remote.py by putting a # symbol at the beginning, like so:

#future.result(timeout=4)

It should be around line 231. Then move the following line channel.subscribe(channel_state_changed) below duplex.result(timeout=10) (previously line 238). After this change you can start Warpinator by running warpinator -d 2>&1 | tee log.txt which will enable logging and save the log to a file (or you can copy what was printed into the terminal). If you're having trouble modifying the file, the logs could be useful even without the change.

Tea not seeing navi at the end is likely due to packet loss. In the log I see that it did detect the service on navi but did not receive the IP address nor the service details. A rescan (in the 3-dot menu) would probably fix that.

Here is a debug (non-minified) build with the API v1 issue fixed: warpinator-debug.zip. It should be possible to install as an update to a release build (without uninstalling original) as it is signed with the same key. It also probably won't fix your issue yet, but the logs might have more useful information.

Thanks again for providing the logs. It seems that this issue is quite common and you are the only person giving useful feedback, which is much appreciated!

Edit: here is a newer debug build with additional gRPC logging enabled: warpinator-debug.zip

[alek3y]

I think your latest debug build may have solved the problem, because I can't seem to reproduce it anymore.

I did however notice a weird behaviour similar to what you hypothesized was due to packet loss, which unfortunately did not seem resolve using the rescan button. In two instances (hopefully within the logs) tea would: 1. not see anyone and 2. only see maple.
What I think causes this is to have Warpinator open on all devices and then closing and reopening the app on one of the two. This was so rare however, that I can't really confirm nor reproduce reliably.

In any case I gathered the logs for all three devices, which I hope can at least confirm that the original problem is fixed, since I tried a bunch of times and all devices always connected successfully (when they appeared on each other's list).

maple.log
tea.log
navi.log

About the connection reset: I'm not sure but I suspect it happens because I close and reopen the app from the recents screen when trying again (and not with the 'Stop service' or 'Quit' buttons).

I couldn't patch remote.py on the desktop app because elsewhere a ValueError would be thrown and kill the service:

Stack trace

Traceback (most recent call last):
  File "/usr/lib/python3.13/threading.py", line 1043, in _bootstrap_inner
    self.run()
    ~~~~~~~~^^
  File "/usr/lib/python3.13/threading.py", line 994, in run
    self._target(*self._args, **self._kwargs)
    ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/warpinator/util.py", line 122, in _transfer_thread_func
    opinfo[0](*opinfo[1], **opinfo[2])
    ~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/warpinator/remote.py", line 391, in update_remote_machine_avatar
    for info in iterator:
                ^^^^^^^^
  File "/usr/lib/python3.13/site-packages/grpc/_interceptor.py", line 193, in __next__
    raise self._exception
  File "/usr/lib/python3.13/site-packages/grpc/_interceptor.py", line 448, in __call__
    return self._interceptor.intercept_unary_stream(
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
        continuation, client_call_details, request
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/usr/lib/warpinator/interceptors.py", line 45, in intercept_unary_stream
    return continuation(client_call_details, request)
  File "/usr/lib/python3.13/site-packages/grpc/_interceptor.py", line 438, in continuation
    return self._thunk(new_method)(
           ~~~~~~~~~~~~~~~~~~~~~~~^
        request,
        ^^^^^^^^
    ...<4 lines>...
        compression=new_compression,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/usr/lib/python3.13/site-packages/grpc/_channel.py", line 1408, in __call__
    call = self._managed_call(
        cygrpc.PropagationConstants.GRPC_PROPAGATE_DEFAULTS,
    ...<8 lines>...
        self._registered_call_handle,
    )
  File "/usr/lib/python3.13/site-packages/grpc/_channel.py", line 1796, in create
    call = state.channel.integrated_call(
        flags,
    ...<7 lines>...
        _registered_call_handle,
    )
  File "src/python/grpcio/grpc/_cython/_cygrpc/channel.pyx.pxi", line 525, in grpc._cython.cygrpc.Channel.integrated_call
  File "src/python/grpcio/grpc/_cython/_cygrpc/channel.pyx.pxi", line 344, in grpc._cython.cygrpc._integrated_call
  File "src/python/grpcio/grpc/_cython/_cygrpc/channel.pyx.pxi", line 262, in grpc._cython.cygrpc._call
  File "src/python/grpcio/grpc/_cython/_cygrpc/channel.pyx.pxi", line 310, in grpc._cython.cygrpc._call
ValueError: Cannot invoke RPC: Channel closed!

To make sure it wouldn't timeout with an exception I added a print statement before and after the line you asked me to comment, and I didn't see anything suspicious (it's in the logs though).

I'm glad to be of help, and thank you for the work you've put in the app :)

[slowscript]

Thanks for the good news, it sounds great but it's also strange 😅 I don't think I've changed anything that would fix such an issue. One possibility is that it's because it's a debug build. A release build has minification turned on, which removes what it thinks is unused code, but sometimes it removes too much and it crashes on some code paths. Here is a release build with the same changes: warpinator-release.zip. The same changes (except logging) are now also pushed to master. If it still works, you don't need to send logs again.

As for discovery, I know it has some reliability issues. I will look into that next.

Removing the app from recents does the same as 'Quit' (unless you turn off 'Stop service after leaving app'), you can see 'Server stopped' right after 'Task removed' in the log. I think the connection reset is what was happening when navi was attempting to connect, but back then we did not have more detailed logs turned on, so who knows what is the cause. In the new logs it only appears when the other is not running, which is expected.

The ValueError happens because it needs one more change I originally forgot to mention (moving the channel.subscribe() line) and only edited it into the comment shortly before your reply. But since it seems to work now, this is does not matter.

Edit: Ok, so the recent changes have not fixed anything. I finally managed to reproduce the issue on a borrowed Android 5 tablet I have not tested since early 2024. Hopefully I will be able to figure out what is wrong. Stay tuned.