BTSync blocked in China?

[Truth1ness]

Hey guys, so I was transferring a file to a person in China and it was not working as it was for you guys. He then put a file in the folder for a test and suddenly the syncing started to work. This happened again after restarting the program, transferring did not work and then I asked him to put another test file in his side of the folder and it worked again. If you're transferring to an actual person this might be a temporary solution. For the devs, maybe this'll give some insight into what the problem is and what a possible solution could be to "kickstart" syncs to china.

[jerryhou85]

Hey guys, so I was transferring a file to a person in China and it was not working as it was for you guys. He then put a file in the folder for a test and suddenly the syncing started to work. This happened again after restarting the program, transferring did not work and then I asked him to put another test file in his side of the folder and it worked again. If you're transferring to an actual person this might be a temporary solution. For the devs, maybe this'll give some insight into what the problem is and what a possible solution could be to "kickstart" syncs to china.

I think this is similar to Dropbox situation: in the China side, it will not sync with outside China if it's already running. You have to restart(reboot) the dropbox to kind of "force sync". Something like it has to detect a "change" so it can start to sync.

[Truth1ness]

in the btsync client, right click on the shared folder and select 'show folder properties'

 

click on the properties tab, then tick 'user predefined hosts'

 

then you need to add the other pcs ip address and port (port used for btsync)

 

you can use something like no-ip.org if you have a dynamic ip and not sure if its required, but  i also mapped the ports on my router to the pc.

 

i guess btsync is now an official threat to the safety and stability of the peoples republic of china 

 

I'm going to try this. Just to clarify, for port do I enter the number the other computer has in the "Listening Port" field in their BTSync and their outward facing IP address (ie what shows at whatismyip.com)? Should this be done on the computer inside or outside of china or both or does it not matter? 

 

I'm also curious, would checking "Search DHT Network" be helpful in this?

[shimsim]

I'm going to try this. Just to clarify, for port do I enter the number the other computer has in the "Listening Port" field in their BTSync and their outward facing IP address (ie what shows at whatismyip.com)? Should this be done on the computer inside or outside of china or both or does it not matter? 

 

I'm also curious, would checking "Search DHT Network" be helpful in this?

If you have for example PC1 and PC2, then enter the outward facing IP address and listening port of PC1 in the user predefined hosts setting of PC2 and vice versa. Unless you have a fixed IP, you should use something that will detect and update your real world IP address.

[RomanZ]

Hi dms2013,

 

I have set up at home now, a rasp pi, that syncs with 1 android (photo backup) and a pc, both pc and rasbpi got the RO key. When I look on the webinterface, the rasbpi only connects to my desktop. My desktop use predefined host to find the android inside my LAN. But shouldn't it tell the rasbpi about the android device?

 

Actually BTSync identifies other BTSync instances in local network over port 3838 using multicast requests. So devices in local network must be visible one to another even if tracker is inaccessible. Please make sure that the port is not blocked by local firewalls.

 

All people who can't sync in China over internet, please check that:

1) Your computers can resolve DNS names t.usyncapp.com (tracker server) and r.usyncapp.com (relay server). First would be enough for computers to "see" each other (displayed in devices tab). If they can't be resolved - you can try to put actual IPs in your hosts file, 54.225.92.50, 54.225.196.38, 54.225.100.8

2) if you can actually connect to the tracker server. To accomplish this test you'll need a binary file which represents a legitimate request to the tracker server, send it to tracker server and see if response comes back.

For Linux and Mac systems just get the file, put to some folder and run next command from command line:

"cat udp_req.bin | nc -u t.usyncapp.com 3000"

For Windows you'll need to download net cat utility first and run similar command:

"type udp_req.bin | nc -u t.usyncapp.com 3000"

If you can reach the tracker server, you are going to get response starting with "BSYNC..." like this

If you can't - you'll get just nothing after your command. 

 

For the people who can't sync in local network:

1) Please check your firewall settings, if it you are confident that nothing is blocked -

2) I would appreciate collecting full debug logs from 2 peers that can't connect. Please provide logs for analysis and we'll try to find out what's happening.

 

 

Looking forward for your test results.

[staalu]

It's work!

 

I'm in China

After I add "54.225.92.50 t.usyncapp.com" in hosts file

I can get response like "BSYNC..." from tracker

and my device can find other over internet!

thanks!!!!

 

it's DNS cache poisoning?

[dms2013]

 

Hi dms2013,

 

 

Actually BTSync identifies other BTSync instances in local network over port 3838 using multicast requests. So devices in local network must be visible one to another even if tracker is inaccessible. Please make sure that the port is not blocked by local firewalls.

 

All people who can't sync in China over internet, please check that:

1) Your computers can resolve DNS names t.usyncapp.com (tracker server) and r.usyncapp.com (relay server). First would be enough for computers to "see" each other (displayed in devices tab). If they can't be resolved - you can try to put actual IPs in your hosts file, 54.225.92.50, 54.225.196.38, 54.225.100.8

2) if you can actually connect to the tracker server. To accomplish this test you'll need a binary file which represents a legitimate request to the tracker server, send it to tracker server and see if response comes back.

For Linux and Mac systems just get the file, put to some folder and run next command from command line:

"cat udp_req.bin | nc -u t.usyncapp.com 3000"

For Windows you'll need to download net cat utility first and run similar command:

"type udp_req.bin | nc -u t.usyncapp.com 3000"

If you can reach the tracker server, you are going to get response starting with "BSYNC..." like this

If you can't - you'll get just nothing after your command. 

 

For the people who can't sync in local network:

1) Please check your firewall settings, if it you are confident that nothing is blocked -

2) I would appreciate collecting full debug logs from 2 peers that can't connect. Please provide logs for analysis and we'll try to find out what's happening.

 

 

Looking forward for your test results.

 

I resolv t.usyncapp.com to 37.61.54.158 and r.usyncapp.com to 67.215.231.242. (while using OpenDNS) it's different from the IPs you posted above. The same with Google DNS. GFW Is replacing the IPs in the DNS Query. However, I can ping all 3 of them (54.225.92.50, 54.225.196.38, 54.225.100.8) so adding the hosts would work.

 

on my L.A. based VPS I resolve t.usyncapp.com correctly.(obviously) 

 

For my home network. I got a simple D-Link router and I haven't really changed any setting (apart from wifi name/password and ISP credentials)

 

If I don't set the predefined host on my windows pc to connect to the android (would be nice to see the ip:port in the android app, instead of parsing logs), they don't sync. I don't have BTS on my rPi anymore.

Maybe it never gets executed because the t.usyncapp.com isn't responding. (and maybe it works if it is LAN only, and no internet, will try that out, turning off internet, and try to send files between 2 android phones) (just tried while the internet was on, does not work, it is just stuck at connecting, and the Androids are Nexus 4 with Kitkat and no firewall/virusscanner yadda installed.)

 

I am running Windows 8.1 on my PC. BTS can use any TCP or UDP port in the firewall rule that was added whem installing BTS. So that shouldn't be the issue.

 

it feels like it's just a simple bug that someone just overlooked.

 

So I will get BTS rPi running on my again and add ia share that's only on the phone and see if anything happens.

I will send that log your way later. 

[Truth1ness]

I followed shimsim's instructions of putting each PC's ip address and listening port on each others' predefined hosts list and it seems to have worked successfully. If it fails again I will give those usyncapp server ip addresses to the person at the other end to enter into their host list. 

[dms2013]

So the sync works in LAN with internet on now. That is great. I haven't changed any network setting since last time.

I added the hosts to my windows pc. And I will do the same for the androids, just to be on the safe side.

[RomanZ]

staalu,

 

No, it is not DNS cache poisoning. The poisoning technique implies that someone who has no admin access to the DNS server manages to change some DN-IP relation in DNS server cache. Either your ISP or some global country server has wrong address, most likely intentionally.

 

dms2013,

How your devices are connected to the DLink router? Wi-fi / LAN? How was RPi connected? I can suggest that DLink might NOT transfer Multicast packets between wi-fi and LAN, especially if they are configured as different subnets. Also, shutting down windows firewall is worth checking to find the root cause.

Looking forward for your RPi test.

[dms2013]

staalu,

 

No, it is not DNS cache poisoning. The poisoning technique implies that someone who has no admin access to the DNS server manages to change some DN-IP relation in DNS server cache. Either your ISP or some global country server has wrong address, most likely intentionally.

 

dms2013,

How your devices are connected to the DLink router? Wi-fi / LAN? How was RPi connected? I can suggest that DLink might NOT transfer Multicast packets between wi-fi and LAN, especially if they are configured as different subnets. Also, shutting down windows firewall is worth checking to find the root cause.

Looking forward for your RPi test.

I tried using OpenDNS 208.67.222.22  and Google DNS 8.8.8.8. Both show the wrong IP when queried without a VPN. I think GFW is very good at what it's doing. 

 

PC and RPi is connected via ethernet and Androids via WiFi. (all on the same subnet, 192.168.0.0/24)

I was unclear in my previous post. (I started writing, then I had to leave and continued when I got back home.)

The RPi could connect to the Android without having to use a VPN or changing the hosts file.

 

I didn't manage to share files between 2 androids, stuck at connecting. Now I am trying to scan the QR code from my windows desktop and receive the files in the Android. It's stuck on connecting. I will try the same on the RPi. And then disable windows firewall and try on the PC again.

My router is a D-Link 820L (or cloud 2000 something)

 

Now I tried the above...

 

So the Windows 8.1 firewall is the culprit. RPi and Windows with disabled firewall works fine to send files to the android.

 

But still android to android isn't working. 

[RomanZ]

dms2013,

 

Please make sure that your Android is indeed using local network. From the symptoms it looks like it tries to connect via mobile internet (and gets a wrong tracker IP).

 

Android clients also issue a Multicast packets to detect peers in local network. I especially did the test in a lab: a wi-fi network with no access to internet - Android devices manage to transfer data and generally "see" each other.

[rwxrwx]

Hello RomanZ

 

Thank you for your instruction about make btsync work in China. I modify the hosts in windows and my mobile phone over 3G network is able to recognize my windows box, but when I do the same to my fedora box, my mobile phone failed to recognize the fedora box, but if the fedora box and mobile phone are in the same local network, they can recognize each other, my fedora box is relatively vanilla one with little configuration after installation, I've checked sync.log and find 3 upnp device error, is that relevant? Is there any other possibility to make it works?

 

P.S the nslookup result of t.usyncapp.com seems not direct to the right IP, and the binary file test get no result, but I could ping t.usyncapp.com and these three IPs successfully.

[RomanZ]

rwxrwx,

The issue looks to be in your fedora box and its inability to access correct tracker server. The fact that you can ping the tracker server actually proves nothing: ping uses completely different protocol.

Do I understand correctly that after you put correct IPs in hosts file on Fedora box it contacts correct IP of a tracker server and tracker does not respond anything on your request with binary I supplied?

If yes, I have bad news for you: seems something on the way to tracker (your firewall, router, ISP or GFW) is blocking packets to tracker. In this case the only solution for you would be using predefined hosts.

[dms2013]

If t.usyncapp.com resolves to the wrong IP, it doesn't matter if you can ping it or not. But my experience with GFW is that IPs are blocked, either permanently or for a short time (like searching for aomething with a trigger on google)

[cz2000]

1.3 and 1.4 is not to be used in China, now 1.2 version can work in China, can you teach me new test method used to determine what is being blocked by GFW of China, thank you

[RomanZ]

@cz2000

What's wrong to 1.3 and 1.4? Could you please describe in details?

[cz2000]

@RomanZ All versions do not work after 1.2.92 in China. Currently 1.2.92 version + the correct hosts file are worked and fine in China. Use the same way to 1.3 and 1.4, do not work. Pls help... Thanks

@RomanZ I do not know what happened? Is the new version(1.3 or 1.4) uses new ip address or hostname outside 1.2.92?

[RomanZ]

@cz2000

 

There is an issue with resolving DNS names in China. It looks like DNS is intentionally resolved into wrong IP.

 

Starting from version 1.3 sync attempts to download file 

 

http://config.usyncapp.com/sync.conf

 

which contains IPs for tracker and relay server. Please try to adjust your hosts file to resolve config.usyncapp.com to correct IPs:

 

Non-authoritative answer:
Name: config.usyncapp.com
Address: 54.225.100.8
Name: config.usyncapp.com
Address: 54.225.92.50
Name: config.usyncapp.com
Address: 54.225.196.38

[cz2000]

@RomanZ  the following is my nslookup result:

 

Non-authoritative answer:

Name:    config.usyncapp.com

Addresses:  54.225.196.38

          54.225.100.8

          54.225.92.50

 

This result appears to be correct, however, 1.3.109 still does not work on my windows 7. 

 

BTW, I can use IE to download the file from  http://config.usyncapp.com/sync.conf on my disk(This indicates that this link is not blocked by GFW.)；In addition, I did icmp ping and tcp ping test for config.usyncapp.com, the result is ok. 

 

I really do not understand where is blocked, leading to not communicate in 1.3.109.

[ortreum]

Maybe there's a simple solution. First the port should be able to change randomly on each start or the program tells the other nodes what the next port will be. Misuse ordinary ports 21, 22, 25, 80, 443 and protocols tcp, udp. There are ways ... and they should be implemented as automatically running features.

To update the software every new version can get an unique key for downloading the program via the torrent network. So it only needs one person in da hood who already has it and all the chinese guys can get it.

 

Be more creative

[RomanZ]

@cz2000

Okay then. I suspected that you were experiencing same issue many people suffered in China (inability to reach tracker server), but seems that you have something different.

 

Could you please describe what exactly is not working? 

[colinabroad]

Hey All. I am another Brit in China - in Shunde, Guangdong region, so not far from most of you.  Not sure why you are having problems within or without China on this.  I have never needed to do anything with the port settings in the app - all devices have always been able to see each other within the two LANs I use (home and office)  and they are MOSTLY able to see each other from home to office - which is only about a third of a mile away, but I have both China Telecom and China Unicom ISPs, so they are not always with the same ISP at the same time - if fact my external IP address changes with the wind both at home and in the office.  Yes, sometimes they fail to spot each other, but it only needs one computer to have a vpn on and suddenly they all see each other and can connect directly across the internet without using the cloud.  I even have a folder shared with a Chinese computer in a Chinese home with no vpn and that is able to connect and keep up comms although sometimes it takes a while to find and get connected, once connected it it OK.  I am currently using a mix of 1.3.109 and 1.4.?? - but I am slowly moving back to 1.3.109 on all my machines as I am unable to get on with 1.4 and it is unable to fully sync.  Once we get a decent GUI and some correct error reporting in the 1.4 version I will probably switch back, but having tried it, it is going to take me a LOT of convincing to switch!   One thing that MAY be the reason for all your problems is DNS lookup.  I have ALL my computers (including androids and iPhones) in my family set to change DNS to either Google or Open DNS.  This is done at explorer level, so all comms to the outside world are automatically using proper DNS lookup, not our friendly filtered local ISPs!!