Sync works in China??

[Tim Radbourne]

I am trying to set a sync in China and once it is working, I want to sync to a folder on a computer in USA.

Presently in China between 2 computers I am not getting past the

Quote

 

Connecting....

 

 

 

 

dialog. 

These 2 computers are both windows 10.  Should that matter?

Edit: Seems to be working now, will test further...

Edited June 1, 2016 by Tim Radbourne
update

[RomanZ]

It might be due to blocked traffic. I suggest trying to manually forward ports on your router/NAT and set predefined hosts to public IPs.

[Tim Radbourne]

Is there any documentation for how to do this?  Will this also improve the transfer speed? 

I do  have it working now, but slowly.  USA <=> China

[RomanZ]

@Tim Radbourne Sure. Take a look here and here.

[Tim Radbourne]

I can report that Sync is proceeding slowly between USA and China.  The biggest issue seems to be that there is a double NAT in place due to CG-NAT (carrier grade network address translation) or Large Scale NAT.  This results in difficulty for software to get through the firewall.  Skype and Sync seem to use similar methods to break through.  The results are that it works, sort of.....   It appears that the only real solution is a directly accessible IP address on both ends of the transaction.  Today, only one end has this due to China running out of real IP addresses.  The solution is IPV6 which is being implemented slowly.

I wonder how badly Sync performs when both ends are behind CG-NAT

[RomanZ]

Tim,

2 things:

1. How slowly it proceeds? Is it 50Kb/sec? 500Kb/sec? 5Mb/sec?
2. Could you please check if connection goes directly or via relay?

There are couple more tricks we can try to improve speed, though we need to understand where do you stand.

[Tim Radbourne]

Thanks RomanZ for your help.  The speed fluctuates dramatically from sitting at 0 for a period of time then  jumping to a normal speed of 30-60kb/sec then without warning it will suddenly increase for a short period of time to an abnormal speed of 500kb/sec.  I have never seen it exceed 1000kb/sec.  Average sync speed seems to be in the 30-60 kb/sec into China and 60-120 kb/sec out of China.

How do I check if the connection is direct or via relay?

Under preferences, we have use relay server checked, use tracker server checked, search lan unchecked, and use predefined hosts checked on the China server.  The USA server is the same except that the predefined hosts is not checked as the CG-NAT in China keeps the China IP changing very often.  Dynamic DNS services don't work in China, otherwise I would set it up as predefined on both sides.

The connection is GF in KC to a China Telecommunications link in South China with a speed of 100mbit down and 2mbit up.  GF is gbit both ways with a dynamic dns and the link in S China is CG-NAT.  The router in china is using dd-wrt and shows an external ip of 100.64.160.xxx  This IP changes every 48 hours, but the real external IP as reported by http://ipecho.net/plain is more likely to be 219.130.73.xxx  Sync seems to be able to get through this double NAT, except when it can't.  Every few days, I see that sync has stopped and shows peers online "0 of 1"  This is the same at both ends as I can use teamviewer to access the other end as well.  Messing around and deleting the predefined hosts and recreating them sometimes will fix the connection.  Other times it requires a Docker restart or a complete reboot.

Since it has stopped again right now, I will not fool with it in case you want some diagnositics.  I would like to get this to a stable point where I can just let it go.... and it won't burp or throw up all over me...  Thanks

[RomanZ]

Hi Tim,

While the

Quote

The connection is GF in KC to a China Telecommunications link in South China with a speed of 100mbit down and 2mbit up.  GF is gbit both ways with a dynamic dns and the link in S China is CG-NAT.

part looks to be rather confusing for me. Though, here is what I understand from your setup:

1. The worst bandwidth on the path from your peer in China to US is 100Mbit down and 2Mbit up. This immediately caps us to maximum upload speed of ~240Kb/sec., while download speed should be fine.
2. You've got 2 NATs in China with dynamic IP which changes every 2 days, therefore direct connection from US to China is not possible: Sync can automatically penetrate only one NAT layer.
3. You've got 1 NAT which you control in US with static IP.
4. The connection as it is is not stable.

Some things that I need to get more info on:

A. Did you:
 - specify IP of your US NAT on China peer predefined hosts?
 - port forward the listening port of your US peer from USA NAT to actually peer?
This should give China peer an ability to connect directly to US peer. Having at least one direct connection will allow you to utilize bandwidth.

B. What are the versions of your clients? Must be 2.3.7 or later - there was a nasty connectivity issue in 2.3.6 and before, which only pop up in complex setups like yours.

C. Monitor if connection goes via relay. Here is the screenshot on how releayed connection looks like.

 

 

 

[Tim Radbourne]

 

8 hours ago, RomanZ said:

While the part looks to be rather confusing for me.

The China side is confusing because China Telecom is using IPV4 with CG-NAT.  CG-NAT is what creates the double NAT problem.  Skype, WhatsApp and Teamviewer seem to be able to penetrate this, as does your Sync with some success, but it is not good. IPV6 is not available at this location yet.  On the USA side we have Google Fiber.  I have another ISP I can try  on the USA side if needed.

8 hours ago, RomanZ said:

You've got 1 NAT which you control in US with static IP.

Did you:
 - specify IP of your US NAT on China peer predefined hosts?
 - port forward the listening port of your US peer from USA NAT to actually peer?

We control this via dynamic dns, but our GF ip seems to be static, so we could use our GF IP address instead.  The China Sync client has predefined hosts set up like:

• mydomain.duckdns.org:5555

On the GF network box (router) the port 5555 is port forwarded to the local ip of the Sync client for both UDP and TCP.  In China, the dd-wrt router also has port 5555 forwarded to the local ip of the sync client both UDP and TCP.  The China side has port 3838 forwarded, but I don't think this is needed.  Maybe I should delete this?

8 hours ago, RomanZ said:

What are the versions of your clients? Must be 2.3.7 or later

2.3.7 on both ends using Docker. 

8 hours ago, RomanZ said:

Monitor if connection goes via relay. Here is the screenshot on how relayed connection looks like

My screen on both ends just shows offline right now.  Once we reconnect, I can check this. 

This setup has moved 150 GB over the course of a month, about 1/2 USA->China, and about 1/2 China->USA.  I have had to struggle and get it reconnected several times.  Now it is disconnected again.  I would like fix it so it will stay connected, but I will not mess with anything until you get the chance to troubleshoot what you need.  I will try any suggestion you may have.

[RomanZ]

Tim,

Leave it disconnected for now and collect your debug logs. Please collect them from both your US and China peers. When sending to us, mention this forum topic. We'll see what happens inside.

After you send logs, try to upgrade Sync binary to 2.3.8. There is a nasty issue about connectivity fixed in 2.3.8 (Windows only) - this might be your case.

[Tim Radbourne]

Logs sent....

I am running Sync 2.3.7 Docker under Linux on both ends.  Upgrading to 2.3.8 is not yet flushing through to

http://lime-technology.com/forum/index.php?topic=40654.0

[Tim Radbourne]

I see sync is running again.  Did you poke it somehow?  Or did it fix itself?

[RomanZ]

@Tim Radbourne No way we can poke it somehow. We can't control the traffic / connections (it doesn't go via our server) and we can't identify anyone. So it's likely something has changed in the network that allowed direct connections. But, we've got your logs and will analyze shortly.

[Tim Radbourne]

Both ends are still logging, I have sent updated logs that should include the reconnect time period.

[Ronery]

Could you setup a dynamic hostname on one of these computers and set up predefined hosts on other computers?

Edited July 8, 2016 by Ronery

[Tim Radbourne]

I have not found a way to use one of the dynamic host services in China yet.   They are blocked.  Were you meaning like duckdns?

That is what the USA computer is using today, so we have predefined hosts on one side of the connection. 

[Tim Radbourne]

I have been using a test build (2.3.1049 - 57) of Sync for several days now, and so far I have not seen any disconnects.

[Tim Radbourne]

While I have had no disconnects, suddenly the peers online jumped to 2 of 2 (there is only one peer on either end and it always showed 1 of 1 before) and Sync stopped syncing for over a week.  There was 25G / 800 files to sync but it acted like it was fully synced.  Rebooting, stopping and restarting the Sync docker service did nothing to fix this.

Suddenly today, long after I had given up on getting this fixed, I had to rebooted the USA server for another reason.  Sync refused to connect until I stopped are restarted the Sync docker service in China.  Now suddenly it is showing 1 of 2 peers online, and it is syncing again.  Logs are available...

[RomanZ]

Hey Tim,

Please submit the logs to our helpcenter together with last description. As I remember, you have the ports forwarded in US and direct connection from China to US is possible, isn't it?

[Tim Radbourne]

Yes, correct, a direct connection to the USA is possible.  China IP keeps changing. 

 

Suddenly, It has lost connection again, so these logs should be useful.  Sending them now.  I have logs going back to 08/02 (500mb) on the China side, but only to 08/06 (800mb) on the USA side.  Sync seems to be cleaning up the logs when they get overly big. 

Your support page is having problems receiving the log files.  Sent 4 logs,

China / USA logs from today

China / USA logs from Aug 6, the oldest Sync log files that have not rotated.

[Enterprise]

I recently upgraded my broadband in China to 60Mb/20Mb (download/upload).  That is where my BitTorrent Sync server is located.  I run a client in another country in Asia and have been able to get approximately 2.5-3.0 MB (equivalent to 20-24 Mb) down at the client side.  BitTorrent Sync seems to be able to use my bandwidth fully.

If you are experiencing slow Sync speeds with a US peer from China, you may want to find out what throughput you can achieve outside of Sync.  I ran speediest from China to multiple locations in the US and the throughput was no where close to the throughput I got running speediest to countries in Asia.  Your problem may not be the Sync software.

[Tim Radbourne]

I have run some test versions of BT Sync docker software (2.3.10058)  that have managed to remain connected for weeks without issue.  I now declare it stable. 

Remaining issues are my 2/100 line speed in China and jumping the Great Firewall.

[YI WANG]

I got a VPS in US, a alicloud in China mainland, a laptop with Centos 7 and PC with windows 10, the last three clients all located within the China mainland. At least in my opinion, the 4 of all clients above are running good. As for the full usage of band of the internet, I think the right line you chose is maybe the problem. I use CHINA UNICOM for 200MB for the PC and laptop in my home. Though the IP is dynamics, but with the help of DNS's API, I ran a python script in my OPENWRT router to bind a domain name to the PC and laptop,and allocate the port of 8888 and 8899 for their Sync ports. And the speed for uploading and downloading of Sync between the US and China are almost around 20MB and 200MB separately.

So, in my thought the China Great Firewall is not blocking every port coming out or coming in the China mainland, not possible for large amount of corporations with goods export demand or the foreigners lived and working in China.

[Tim Radbourne]

I would agree that the GF is not blocking needed ports.  As long as you are syncing large files, the speed will approach wire line speed.  The overhead for processing files will slow small file transfers way down.

I blamed some of the issues on the GF, but in reality it was not the root cause.  Bugs in the Sync software resulting in it dropping the connection intermittently.  These appear to be fixed in the version of 2.3 that they created for me, and possibly these fixes are included in the newly released ver 2.4

[aviduser]

Reposted from the general suggestion forum.

I have done research work on this and hope the following information will be helpful to others.

The current GFW block on resilio and btsync:

1. GFW does not block the initial configuration load (to get a list of trackers for example). DNS resolution and download will all work.

2. GFW does block the subsequent connections to the trackers. This is done at IP packet inspection level. This blocking was initially started in some cities but eventually spread to all. Connections to the trackers are cut-off prematurely (EOF received).

The current workaround (See the limitations) that proven to be working.

1. You can setup predefined hosts in resilio for all shares. In BTSync, you can only setup predefined hosts for each share individually - which is a chore. This method works as the deep packet inspection currently only targets the trackers, not individual connections between btsync/resilio servers.

2. To be practical, you will need to setup a dynamic dns name (DDNS) for each btsync server and use a fixed port number (e.g. host1.blah.com:4444, host2.xyz.com:4444, host3.uvw.com:4444). Because servers are usually behind home routers, NAT is used. Your router must be able to turn on NAT-PMP so that the port 4444 will be opened on the router to your server. uPNP would also work though NAT-PMP is more secure.

Limitations:

1. If deep inspection targets server to server direct connections, the above workaround will likely to fail. The server-to-server protocol probably contains sufficient unique string for inspection and targeting.

2. Use the next alternative.

An alternative to BTsync/Resilio would work and resist deep packet inspections - syncthing. (Sorry, resilio)

Syncthing is an open source project and it was a little shaky a 2-3 years back but now it's quite stable and mature. Similar to BTSync/resilio, Syncthing also has global discovery servers for servers to discover each other. They are subject to the same blocking in the future. However, Syncthing also has predefined hosts method simliar to BTSync. This direct connection method is resistant to DPI.

Syncthing's protocol is strictly TLS 1.2 with no special customization identifiable before the TLS handshake completes. This makes it very resistant to future deep packet inspection. To be more specific, when 2 servers connect to each other, they will always complete the TLS handshake first. Before the handshake is complete, there is nothing identifiable in the communication than any regular HTTPS traffic. After the handshake completes, when communication is secure, the servers will check each other certificate to determine if they are configured to talk to each other. They drop if they are  not configured to trust each other.

For this reason, syncthing direct server connection will resist future DPI.

-

Good luck everyone!

P.S. I should add that using socks proxy is not a universal solution.  It's not only complicated to setup for a lay user, but the socks proxy itself needs to be in the region unblocked (such as overseas). It also must be a private socks proxy than a public one (or it will be blocked too).