I am using Syncthing on my other Android devices connected to my desktop (running Linux) no problem. I followed the same setup process on GrapheneOS, and it doesn’t seem to be able to connect. I tried the usual method of reading the QR from my desktop on the phone - the connection appears to be set up, but it doesn’t give the notification on the desktop about trying to connect, and remains disconnected. I don’t see anything in the desktop server logs about this particular device. I haven’t changed any of the settings in Syncthing. I was able to connect to an SMB share on my desktop using Material Files from this phone. Any ideas about what I can try next?
Please use the left slide-out menu to open the Web GUI in the Android app, then take a screenshot of it and upload it here. Please pay attention to what the situation is in Listeners and Discovery. You can click them to view the details too.
Everything looks normal to me. Can you post similar screenshots from the Linux desktop side too?
I did change some of the settings on the Linux side, I attempted to reset them, let me know if there are any I should check specifically.
It looks normal. The important thing is not to disable global discovery on either side, because Android needs it due to local discovery being broken there (unless you hard-code the IP addresses). It seems to be enabled and working on your devices though.
Another problem here is that you’re using an outdated Syncthing version on the Linux side. While theoretically it should still work and be compatible with the current one, I think it’d be a good idea to try to update it and see whether there’s any difference. The OS seems to be Debian/Ubuntu-based, so please follow https://apt.syncthing.net if you decide to do it.
Of course, there’s a possibility that the problem is unrelated and will still persist even after updating Syncthing, but no-one here is probably going to spend time trying to debug the 1.5-year-old version.
I updated the desktop version to v1.20.4 from the syncthing apt, it’s still apparently failing in the same way.
Please try to add the Android device manually on the Linux side, and if it still fails to connect, please try to hard-code the IP address (e.g. tcp://192.168.0.2, dynamic) and see what happens then.
If that doesn’t work either, next you should probably check the logs for connectivity-related errors. One way to grab full logs without setting Syncthing to save them to the disk beforehand is to
- Go to Actions → Advanced Configuration → GUI.
- Enable Debugging.
- Go to Actions → Support Bundle.
- A zip file with various files will be downloaded, with a logfile among them.
The above can be done both on desktop and on Android as well.
It’s working now, thanks. Adding manually on the desktop didn’t work, but also setting a hardcoded IP address did it. Any ideas why the usual connection method didn’t work? Hopefully it will stay stable or I can adjust it to be stable.
Thanks for all your help!
Not really sure, but GrapheneOS is supposedly “privacy and security focused”, so my guess would be that some networking functionality that Syncthing needs may be restricted on it.
One problem with hard-coding IP addresses like that, especially on mobile devices, is the fact that you won’t be able to connect from outside of the local network.
I agree, the “extra secure” GrapheneOS networking settings seems like the only plausible explanation. I’ll try to find some time to play with the settings and check out the logs you mentioned to see if I can find a clue about a setting to change on GrapheneOS or a question to ask the GrapheneOS people.
The syncthing docs lists this:
Do you know if all three of these are required for the regular discovery to work?
I don’t sync outside of my local network, so the address issue should be fine for the time being.
First two aren’t for discovery, but the actual connection establishment. They need to be accessible at least on one side of a connection, better on both (in case discovery works in just one direction, and the wrong one). The third is the prt used for discovery as the description states.
You can also use both dynamic and your address, i.e. <ip>,dynamic. Just in case the IP does change and discovery might at some point.
So do you think it seems like there’s an issue with GrapheneOS sending or receiving broadcast UDP on 21027? If I add the desktop device ID to the phone by scanning the desktop id QR on the phone, this means that the phone will send the broadcast? Would it also listen for a broadcast in this case to find the desktop?
Scanning the QR code is to add a device. That has nothing to do with sending broad-/multicast, but obviously is a requirement to getting a connection (it doesn’t connect to random devices). Sure, many “security” solutions block UDP because “dangerous”, so it is possible - whether it’s likely I can’t say I don’t know GrapheneOS. It’s also possible that the desktop is on a different subnet if it is on LAN, and many routers by default don’t relay broad/multicasts between different subnets. If you have global discovery, it should however still be able to discover local addresses through that.
What you have never shown is the expanded remote device of the device in question. There the discovered addresses will be shown. Actually there’s one screenshot where all the devices show as up to date, i.e. connected. So it actually looks like there isn’t any problem.
I tried to reproduce by reinstalling from scratch, and it doesn’t need the hardcoded ip anymore, seems to be working fine, thanks. If it does reproduce again, I will check the debug logs and the info you mention.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.