Yes, I’ve also noticed that with Schannel ignoring TLS certificate errors as long as the certificate matches the known/specified self-signed certificate is broken. Likely the Schannel backend does not propagate the error information sufficiently. (It works when the certificate is normally recognized by the system which I only tested at the beginning.)
I improved the error handling of TLS errors so one gets a decent error message and not just “handshake failed”. It turns out that the Schannel backend uses slightly different error types. The next version of Syncthing Tray should be able to cope with that.
The only disadvantage of the Schannel backend I’ve noticed so far is that certificates cannot be displayed nicely (e.g. for the purpose of showing an error message). But I think we can live with that.
I’ve got just a quick question. Is there any way to hide these exclamation marks?
The thing is that there are some files being used by running software, and until the said software is closed, Syncthing cannot access them. This results in SyncthingTray being stuck in the “out of sync” state, but I’m actually well aware of it, and I don’t really care either, so I’d like to hide the warnings, if possible.
Currently it is not possible. However, the “Select what information should be considered to compute the overall status:” setting could be easily extended.
These are errors, right? Are all errors grouped together? For instance, I don’t care for some files being unable to sync due to being locked by other programs, but I would still like to know if a whole folder was missing or something else similarly serious was going on.
Filtering only specific errors would be harder to do because it would require more advanced settings and UI. Maybe it would be possible to distinguish at least errors for the whole folder from errors for particular items but out of my head I’m currently not sure how/whether Syncthing’s API makes that distinction.
Can someone point to a setup guide? I can’t find one and can’t figure out how to set it up. Thanks
Just browse through the README. It explains how Syncthing Tray can integrate with your existing Syncthing setup and has a list of download options. Otherwise there’s not much to setup. I nevertheless recommend browsing through the settings because there are lots of optional tweaks.
By the way, a wizard to guide one through the first-time configuration is on my list of ideas for improvement but I have never had the time to implement it so far.
I just downloaded the 1.1.12 Version for Windows from Github. My TrendMicro Virus Scanner flaged the program as HEU_AEGISCS941 during realtime scan. I guess this happend after I tried to activate the automatic system startup. Scanning the file itself leads to no detection.
30 minutes after downloading from the git-hub repository, the files where gone. Now another 30 min. later there are new files for version 1.1.12. These differ from the ones I first got.
Old: syncthingtray-1.1.12-i686-w64-mingw32.exe (SHA-256): 74257A87FC2B2E4C0C691F7D4DDDC5510E36E3A52892BEC1B037A36A34160CED
New: syncthingtray-1.1.12-i686-w64-mingw32.exe (SHA-256): 178FA25DB9B363BCD0C317C072AE59ABF6F5BF780CC5AF77FC24153DB6CA373B
I hope these are two seperated issues.
Martchus, thank you for your work. The short look I had, looked impressive.
It is correct that I’ve just updated assets on GitHub. After accidentally building against a wrong state (missing some of the most recent commits) I had to rebuild them again. I suppose simply exchanging the files is not the best practice but I didn’t want to make the matter more complicated than it needs to be. Nevertheless, thanks for letting me know.
I don’t know about that virus scanner but it must be a false alert.
Thanks for the quick reply. I’ve tested this now again. The TrendMicro Virus Scanner (https://www.trendmicro.com) is only triggered the moment I try to activate the automatic startup. I assume it dosen’t like programms to modify this region of the registry.
Yes, I assume it just doesn’t like it. (Applications which add themselves to the autostart without asking are actually quite annoying so this wouldn’t be completely unreasonable.)
I’ve got a problem with Syncthing Tray being unable to connect to two different Android devices.
To give some context, I use the program on a desktop PC to monitor Syncthing status on multiple remote devices on the same (W)LAN. Everything else is able to connect with no problems, but with these two, nothing happens when pressing the “Connect” button.
This is what the configuration looks like for one of them.
It follows the same pattern as the other devices (e.g. Windows) which connect with no issues. The certificates, API key, address, etc. all match, and I can access the Web GUI from the PC remotely too.
Have you got any idea what the culprit may be here? As already mentioned, there’s simply no reaction at all upon clicking the “Connect” button, so it’s difficult to guess what may be going on in the background. One common thing between the two devices is that both run Samsung Android, one being v7.1 and the other v11. There’s no firewall or anything like that installed on them, unless Samsung has something baked in that would block incoming connections.
You can try to run Syncthing Tray within a terminal. Maybe the log contains something useful. It would likely make sense to increase the log level (see GitHub - Martchus/syncthingtray: Tray application and Dolphin/Plasma integration for Syncthing).
If your credentials/key/cert would be missing or wrong you’d normally get an error message (and if not that’s a bug I haven’t seen so far). The same counts for other error cases. So it is likely stuck until a possibly long timeout is reached. (Not sure what the timeout is. Qt takes care of it and maybe it depends on some system configuration.)
Is logging supposed to work under Windows? I’ve tried setting the LIB_SYNCTHING_CONNECTOR_LOG_ALL variable, but there is no additional output in the console at all.
It should work under Windows. Note that graphical apps have by default no console under Windows so you also won’t see any output when simply invoking the app within cmd.exe. I recommended using Mintty instead. I suppose redirecting the output should also work.
If I remember correctly, then syncthingctl has a console so you could also use that for testing. It is using the same libraries under the hood so the behavior should be similar to the GUI.
(And btw, the simplest way to install Mintty would be installing MSYS2 which is in my opinion worthwhile anyways as it really makes Windows suck less.)
I’ve found out what the problem was about. In short, it was a user error. I mistakenly was trying to use cert.pem instead of https-cert.pem as the certificate file, hence the connection couldn’t work, obviously. Apologies for wasting your time on this. It’d still be nice if there was some kind of an error displayed on the screen though 
.
Just for the record, I haven’t tried using MSYS2, but I did experiment with both output redirection and also using bash.exe from Git for Windows, yet there was still nothing logged out there.
This is unrelated to Syncthing Tray itself, but I’d just like to mention that right now it seems impossible to extract https-cert.pem from the Syncthing Android app without root. The app’s internal backup doesn’t export it, and the app data is otherwise inaccessible to the user. On top of that, the app disallows ADB backup, so unless I’m missing something obvious, there really seems to be no way to obtain the cert file in this situation.
Definitely. Normally SSL errors should cause an error that is also not just visible in the logs but in form of a GUI notification. Note that errors are also accessible via the right-click menu in case you miss the notification. (The entry to show internal errors is only visible if there are any.) I’ve just tested it on GNU/Linux, also by swapping https-cert.pem with cert.pem and I’ve got an error notification.
Then you actually have some bits of MSYS2 installed because Git for Windows is using it under the hood. However, you have likely not used Mintty and I presume using bash.exe alone won’t help. Not sure why the redirection didn’t work.
Maybe it is worthwhile to add an option to allow any self-signed cert in Syncthing Tray. That would at least be helpful for quickly testing whether the connection works at all.