Johannesburg 24 DEC 15
Gentlemen,
since a couple of days, basically since last weekend - could be with version 0.12.9 but I am not sure about that - I am experiencing problems to connect via the Internet. It concerns connections from Africa to Middle America and Europe. Has there been a change of the structure to the relays or are relays down? All systems are using Version 0.12.9 Windows 32 and 64 bit and/or MAC OS.
Thanks for info
Andreas
Define “problems”. Also, how do you know if its related to relays?
Apart of PC’s that need to synchronize I have set up 4 PC’s that are online on a 24/7 basis. One of them near Frankfurt Germany, 3 at different locations (at least 2 with different internet access) near and around Johannesburg South-Africa.
I can check these PC’s to be available by:
Additionally a couple of collegues tried to synchronize from:
I had the same result with the set-up made with syncthing until the time I told intitilly.
The intereesting part is that on connection after the other failed - so not all of it at the same time.
I still get connections - however only on systems connected via the intranet. All systems attached via internet failed.
But for one PC that I can not acess via VPN I rebooted all - as well I made restarts of syncthing on the individual machines.
As there was noy joy - and the parallel set-up of BTSync is showing normal I suppose that the only possibility could be the relaying servers.
Interesting as is - I just rechecked - it is now 25DEC 2015 UTC - some of the connections show connected status again. First time since 2 days. Thsi must have happened whilst I was writing this reply.
So - the question still stands - was or is there any outage of the relays? Or - is there somthing else that I should get concerned with?
Greetings and thanks in advance
Andreas
I am sorry, but your explanation is very hard to follow, I have no clue whats happening. There has been less relays online during the festive period, but that shouldn’t mean you can’t get connected. You probably just pick a more distant relay.
Also, under ideal conditions you should setup port forwarding and not connect via a relay, as that will be more reliable.
Your answer is really quite hard to understand.
Also,
its Czech Republic. I realize that those words sounds similar but it whole give impression that reader should check in which republic are citizens of Ostrava living 
I do hope for you Václav that you never misspell or have misspelled anything! I am not so lucky!
To the kindly given “real” answers to my questions. There are a lot of factors that do not permit the specific set-up made to utilize Port-Forwarding. We have to keep it with dynamic access.
Again - at present we have around 14 bases around the globe and around 120 persons that need to synchronize basically from anywhere as they are not stationed at these bases. The synchronization dates are set by regulations. However, we can set a “stop press date” - meaning - we can set a time frame of some days for the synchronization to take place.
The personnel can-not be online all the time. They access the internet by different means - for example UMTS, G3, LTE, wired LAN, Hotspots wherever available etc. Satellite Data Link is out of the question due to pricing – and – due to the fact that every expensive equipment that is portable tends to get own (two) feet (is stolen).
We leave defined PC’s at main bases with stable internet connection on. This on a 24 hours, 7 days a week basis (abbreviated internationally as 24/7 basis - UN abbreviation to be exact). Oh yes - the main bases we could set up to interconnect utilizing Port Forwarding - the rest NOT. Here we trust in VPN IPSec connections.
And to our Bug Reporter - please note the difference between the word bases and basis (I hope not to have it misspelled anywhere in the text. As to Grammar etc, I refer to the Oxford - not the Cambridge, Queens or Webster or other Dictionary)
As to internet availability and stability - we are talking about countries like Central African Republic, Republic of Kongo, Mali, Nigeria, South Sudan etc. Cynically expressed - Internet access there is very very stable and it is available always and everywhere!!!
At present it is a test set-up - or - one could say a try. As to requirements we have to choose the system that offers the best stability.
We have to measure the stability because of regulatory requirements. These are contained in a lot of rules and documents about Electronic Libraries
I am sorry to have chosen words that obviously were not correctly understood. I will try not make that fault in future times.
Thanks for your understanding and for the true answers
Andreas
I too am having relay issues. I get this all the time in my logs when trying to reconnect (same version as when it was working a few days before):
2015/12/28 17:12:10 pool.go:35: Failed to join https://relays.syncthing.net/endpoint due to an internal server error: test failed
Last time I reported it on the IRC channel someone did something and it started working immediately… but after not running my relay for a while it comes back again. This is the third time I’ve noticed the symptoms I think.
That usually implies that the ports are not forwarded correctly, or that the relay is full.
“test failed” means the pool server tried to connect to you, and failed. Things like firewalls and bad port forwarding can cause this.
Ok well I just checked my firewall and nothing has changed. Also my internal IP’s and external ip has not changed.
Keep in mind this was working for me a few days ago and now isn’t with no apparent changes to my network. It’s not like it was never working on this client.
Maybe the relay is just full? You’re talking about the main relay that tracks all the other global relays?
Ok after spending WAY more time than I should have on this I can confirm that this file does NOT work on my Raspian RasbPi B+
http://build.syncthing.net/job/relaysrv/lastSuccessfulBuild/artifact/relaysrv-linux-arm.tar.gz
The moment I use said file (but amd64 not arm version) on a real or vm linux… boom, instantly working again. Have no idea why not working on RaspPi but the error msg isn’t really helpful and I really don’t have the time to figure it out right now.
All the Raspberry Pis before the Raspberry Pi 2 use an older version of the ARM architecute (armv6) that basically nothing else in the consumer market uses. All the other ARM boards on the market use armv7 except for a few newer ones that are armv8. This is why you can’t run normal Debian on it and have to use Raspbian.
I think that Syncthing itself is built with support for armv6 but perhaps relaysrv is not. Somebody who is more familiar with the Syncthing build infrastructure could answer that.
Also, you will get better help if you would share that “unhelpful” error message with us.
In the future, please start a new thread for your issue rather than piggy-backing on an unrelated topic.
Finally, it may not really be worth it to run a public relay on such low-powered hardware. I know the Pi’s network throughput is extremely limited.
The error message is already in my previous post several more up from my last one in the same thread. It’s the part in bold.
I’m sorry you thought I was piggybacking on an unrelated topic. I feel I was piggybacking on an ‘exactly’ related topic (STrelay problems since < some date >).
As for the rest of the info, thank you. I wasn’t aware of all the arm architecture info. I don’t have a problem with running the relay on low powered hardware, I don’t run it for long and it is capable of handling at least a few clients as long as it’s not running anything else. And I cant run a relay indefinitely since Comcast now limits my account to 300GB/month.
Ah, my mistake, I missed that part. I thought you were just asking about the issue running relaysrv on the Raspberry Pi.
Since Syncthing is somehow distributed for both armv6 and armv7 in a single binary, I suppose the same could be done for relaysrv.
I’m not sure it even needs that… just a general error message saying “hey dummy this doesn’t run on armv6”. So one doesn’t waste hours of their time.
Anyway… I’m at least hoping my message helps someone else not waste hours of time.
Well, I’m not sure if that’s the issue. But I wouldn’t be surprised. I’m waiting for someone more knowledgeable to chime in…
You could check if you get the ping message from 194.126.249.23. If yes, probably it’s because it takes an unreasonable amount of time (>2s) to connect due to the device having a weak CPU/other stuff running on it, if not, something is wrong with port forwards.
Could only test on 2 Devices
Ping for 194.126.249.23
Time between 221 and 226 ms TTL 237 from Johannesburg
Johannesburg one device out of five confirmed to be working by other programs shows Up to date – the other show – not connected
time between 50 and 53 ms , TTL 245 from Frankfurt Germany
No device out of five confirmed to be working by other programs shows Up to date – they all show – not connected
I was refering to @nrm21’s problem.
It’s still not obvious to me what your problem is, as your posts are so long and full of information that I can’t understand the issue.